Welcome to DevEx Unpacked. I'm Alan Carson, co-founder and chief strategy officer at Cloudsmith. We're solving the challenges of artefact management and are on the path to becoming the software supply chain itself. In this weekly podcast, we share knowledge from Cloudsmith employees, customers, and other great guests from the software industry. Along the way, we'll unpack topics like the cloud security supply chains, and of course the developer experience. Ronan, welcome to the podcast. It's great to have you here. I know you've had a really busy week and thank you for finding the time.

Great, absolute pleasure. Looking forward to it.

Obviously you have an experienced background in managing software teams. Maybe you could give us a quick overview before we sort of launch into the topic of the big topic of how do you build and maintain and run a great software engineering department.

Yeah, sure. I've been lucky enough to be building, running, overseeing leading product and engineering teams for several decades now, let's say. And that's most of my early career was in San Francisco, right at the heart of in Silicon Valley where everything was happening and that was just a superb learning experience for me. And since then I've led teams in the UK and Ireland and global teams across the world as well. So been fortunate enough to do something I'm passionate about for pretty much the whole of my career. Different companies, different sizes from teams of five to teams at 250 different industries as well, different customer segments. So yeah, I've had a wide and varied and very enjoyable career done what I love doing.

Amazing San Francisco. That must've been some adventure for a wee Irish LA to go to San Francisco.

It was,

What did you find in San Francisco in terms of the talent for the stage of the company that they were at?

So when I moved to San Francisco, I was working for an Irish company who had already iPod, a company called CBT Systems, ultimately became Smartforce and Skillsoft and I was a wide-eyed Dublin boy that landed into Netscape to do some work with. We were partners with Netscape and landed right into their engineering team and that was an incredible experience at that time. This is the kind of mid to late nineties, the whole IT world, the whole technology world and all innovation essentially was coming out of that part of the world. So to get, one of the things I found most surprising was the accessibility of people and how they collaborated together, how they shared and learned to build the industry that we now work in.
Initially, my roles was in research and partnering with companies that were building great technology. The video, something like this wasn't even really possible. Then we were working with Real networks and marimba and Macromedia, the early team at WebEx. So really brilliant place to be at a great time. There were ups and downs as well, but the people, the standard of people that you work with was unbelievable. Things have changed a lot since then. While that part of the world is still a really important hub and centre for innovation and technology, it's really a global industry now and people look as much to Europe as they do to Silicon Valley for evolution and thought leadership. And you can build a world-class company in any location worldwide. There's many, many examples of success in that regard too.

Yeah, I mean you and I are roughly the CMH and I remember some of those times I actually, I was sitting in the BBC in Belfast and we did our first test of trying to do video over the internet and I was in the room when they were doing it. It did not go well. We were just trying to, I think it might've been a OL that service and we were literally trying to find random people that would want to talk to us. We didn't have a counterpart over in the States and it was crazy and the bandwidth at that particular point in time just did not cover it. So that was a field attempt, but that was probably, that may have been 99 I think something around that time. So alluded to now things are kind of global and it wouldn't have been in 99 though, right? I mean when I graduated university there was not a lot of software companies in Belfast, and I assume Dublin would've been obviously better than Belfast. It was sort of a bigger centre, but it obviously would not have been the same.

Yeah, there were, so Microsoft and Lotus and IBM had established themselves in Dublin, so there were a small number of the really big tech companies. Sun Microsystems were there too. And that started to, as people moved on from those organisations, started to build an indigenous software industry in Dublin. But it was very small. It was very, very small. As I said, I worked with CBT systems who at the time were the poster child for Irish indigenous businesses. They had grown rapidly, they were serving a global customer base, fortune 100 and Fortune 500. They had gone public, they were from recollection the most successful IPO in 1995. So they were inspiration for lots of other companies to start to build. We can do it too, but it was slow. It was very, very small. Yeah, we've come a long way since.

Yeah, I mean these things tend to take a lot of time and I suppose that's sort of down to the talent base and the universities bringing people through in the industry and yeah, I do think you need wins. You need other companies to win in your market to give people the feeling that they can do it and repeat it. And I've always kind of been big on that, the sort of staff for different stages of businesses and if you don't have a big pool of people. So I would've say that that was maybe one of our challenges in Belfast at the beginning of Cloudsmith was it was hard to find people who had done it before that weren't already entrepreneurial and trying to do it themselves. So there was this sort of gap between the founder entrepreneur mindset and then the people who wanted to work for big corporate. And there's quite a lot of foreign direct investment in Belfast now. So there's a lot of big companies, there's gems out there and we have many of them at Cloudsmith, but that was kind of challenging in the early days. Have you seen that type of thing happen through your career?

Yeah, absolutely. And experience. And the losses are as nearly as important as the wins, but it ultimately boils down to experience. If there are people that have cracked the US market, if there are people that have grown and managed to evolve in a certain way, well then those people are generally pretty good with their time as well. So I find that innovation and collaboration that was there in San Francisco and in the mid nineties that percolated across. So having companies that and people that were accessible that you could speak to was important success factor of the growth experience of it not working out was also important too. And now we have a huge pool of talent in Ireland in general. It's then competitive to get the best people, but recruiting in the right kind of way, those people do exist. They're here already and just like at Cloudsmith, we've been able to attract them into a growing exciting business.
Yeah. So the talent is there, the talent is there. I felt interesting you say that those do well kind of moved into that entrepreneurial and started off their own thing. I never had that ambition. I never had the ambition to grow and start my own business. My ambition was always to take something and make it better scale it. That's what I enjoyed most. First of all, it's probably where my skills were best placed as well. I have huge admiration for founders and for innovators, but I'm best working with them and taking that maybe a product that established some product market fit and helping scale it and really succeed. That's what drives me and that's really what attracted me to Cloudsmith as well.

Yeah, funnily, neither did I emperor.
I remember there was a very poignant moment or important moment in my history where I was standing on the floor of Venture Gate where I worked for Wombat Financial Technologies and Danny Merr, who was the CEO, had stood up and it was 2008 and the crash had happened and he sort of gave this some passion speech, which was like, I know a lot of you're entrepreneurial and would want to go out and start something. And I remember standing there thinking, he's not talking about me. I'm not one of those people. And just to go to your scaling point, at that point I was maybe four years away from my exit from Wombat and sort of on the entrepreneurial journey. I loved the chaos. I mean I ran around in, I owned the place and the chaos of trying to get software out the door and it was a really good experience of just, that was the first time in some ways in my career that we were actually developing software that people used. Because before that I was in another startup where we didn't really sell anything. I mean there was a couple of businesses where we did, but we were shipping code every couple of days and a big industry, financial FinTech businesses were using it. And I really enjoyed that side of things. And I think that was kind of what gave me the feeling to leave and think I could do it better, which was a hard pill to swallow for the first couple of years. It turned out it's really difficult.
But yeah, after that I think, but scaling is hard. So I mean obviously we've been through the wars a little bit in terms of trying to scale Cloudsmith and like you said, a few failures, a few false starts and everything to try and get to where we've kind of got to today. So maybe you could tell us how you go about finding the talent that we've been talking about in terms of trying to hire them in and I guess the kind of culture and side of things and how you put all the pieces together in order to bring somebody good into the organisation.

Sure. Ultimately there needs to be an alignment between the motivation of the individual, a strong alignment, motivation, the individual and the path that the company is travelling. And the best engineers have options. So they need to be excited by the challenge. They need to see the opportunity for them to know that they can have a high impact. They know that they are not going to get held back by bureaucracy. One of the questions I ask of every candidate in the first round is what frustrates you? And I want to understand that how they think about those things. I ask them about what they know about Cloudsmith and I fill in the blanks and I want to know, I see that they're passionate about their craft that have a keen interest in what we're doing.
And I share with them what our culture is like. I want to understand what they're looking for in their next role. So I think just in general, having a well-structured listen to recruit great people that picks lots of things. You have to have a good employer brand when they go to look, learn about you. You need to be serving of information that's attractive. So your website matters. If you're working with a recruitment partner, that touchpoint matters. You need to find them. Often the best people aren't looking for jobs, so finding them can be tricky. So communities like the Irish tech community on Slack is an important point. Maybe not to attract somebody right now, but to make them aware of Cloudsmith and what we're doing or your company and what it's doing. But once you'd make that contact, having a structured interview process that reflects your culture as well. So for us, it's open, it's authentic.
We share a lot in those interviews. We expect people to be open with us. It's a safe space. We try and create a safe space that people can be themselves in the interview process and the technical assessment is fitting to what we need. And it's a high technical bar that we have, but it's fair, it's a collaborative process. When you're working in a team, you're typically, and let's say you're designing a new capability in the product, nobody knows the answer. It's uncertain. So you're collaborating together to look at different options and see and assess them. That's the kind of environment we try to create in the interview process. So it's comfortable and it gives the candidate an understanding what it's like to collaborate with us. So all of these things are important. The candidate experience is essential, but the things that you do to help good engineers find out a little bit about you and develop your reputation are as important.

So then post hire running, how do you bring that individual into the team and the culture and the processes of the company.

So in many ways it starts during that interview process because you're trying to get, you're meeting as many people as you can. So there's a familiarity when someone joins over the years, I think that that personalised onboarding experience has become critical contact before someone starts as to what to expect on day one is important and reduce that natural nerves and anxiety people have and step it into the unknown. When that experience is positive, people feel more comfortable, they feel more confident, they're joining the right place and they're more open maybe themselves. And so those first few interactions, for example, for the last number of years have been on day one person will receive a personalised document and that will include why we hired them. And some of the feedback that has been captured during the interview process and it's incredible, gives engineers incredible lift. I remember 10 years ago now maybe I turned up on day one and I walked into reception, I was nervous and I was there to head up with the engineering team and the woman at reception said, hi, Ron, we've been expecting you.
I felt 10 foot tall. I was like, they've been expecting me and I'd never met this person before. It's little things like that really count. So from day one, getting that personalised experience, having a structured onboarding process and expectations that are set and support around that. So all this feeds into your culture. Everybody is essentially motivated to onboard and to ramp up. Yes, there are a couple of key people. The hiring manager and the buddy that's assigned is important, but everybody is motivated to help. We typically try and have some newbie tasks so that people can contribute value without them being too complicated, contribute value quickly. That helps build confidence operating with a culture of openness. And I mentioned safety a few times, that's also key. The people that I find ramp up quickest are those that are curious, that aren't asked the questions, and that gets you through the first few weeks.
You're delivering value, you feel part of the team. And then from that it's really continuing to build the domain knowledge and understand the product strategy, understand what's meant, what the goal of each team is, what they have ownership for, creating an environment where they can succeed. They're relatively autonomous, and as we go through that, sometimes there's course correction that's required for new people to help them, and that's part and parcel of how we think about their first 90 day journey. I think it's also really important to celebrate their wins and the team's wins in general, speak openly about where there are challenges. And part and parcel of our engineering culture is that yes, we operate with openers and authenticity and that creates a space where people can challenge, but we have the hard conversations, we don't let them drag out, and that may be relation to getting somebody up and onboarded and people respond very well to that. So it's a consistency I think, of culture the way through. That's the same for whether you're a new engineer or you're here for years.

Yeah, I mean, I have to admit, I'm kind of fascinated by the sort of psychological safety side of things because I'm not good at that. I mean, I'm a hot head and inconsistent over time, and I do think that that is one of the strengths that you've brought to Cloudsmith in that engineering aspect of bringing engineers in and being consistent across time, across projects, across teams, is how do you think about that in terms of your day to day? Do you think that comes naturally to you? Do you have to work on it? What's your secret sauce there?

Yeah, I certainly have to work on it. And my approach is based on experience in different environments as well. I think that openness and trust as a foundation is absolutely critical. Patrick Lencioni speaks about it in his book, that Five Dysfunctions of a Team, and I'm a big fan, a great story for anyone that's interested, but that foundation of trust enables people to have those conversations without fear. It is psychologically safe and you need that in any high performing team. It requires vulnerability and the leader of that team, it starts there. So I try to operate with a high degree of authenticity and I'm open. We spoke this morning about the sad end that my phone had this week 10 years ago. I might've kept that to myself, but so you have to work on all the time.
What I've learned is that, so listening and being empathetic is a really important part of that. Understanding where people are at not necessarily jumping to solution mode. And that's something that I've got better at over the years. And also pushing back and being clear and being direct and having the hard conversations and maybe not in that moment, but stepping back and say, right, what are we seeing here? Somebody has an issue about the way something is operating, listening to that being empathetic, but the solution may be what the exact solution that that person wants or may be something that looks different and staying and remaining authentic on those in that regard as well is part and parcel of it. And then being consistent about it, as you said earlier.

Yeah, I'm just thinking we haven't done the baby picks for a while. That was a fun way of breaking down some barriers and getting people to talk and know each other at that particular point.

And over the years, I've done several different ways of having those open conversations, building trust. I recall with the senior group years ago, maybe 16, 17, mostly executives, there were half a dozen people crying and it was incredible level of emotion and vulnerability brought to that group, and that's stood to that group of people to this day, it's an incredible way of building trust. And when we share that kind of knowledge that puts us into that uncomfortable zone and get used to doing that, we're more open to maybe sharing a different idea or challenging a thought process and knowing that that's okay, that it's an opinion. I'm a big believer in strong opinions loosely held. So share your opinion, give your perspective, but hold it loosely because there may be another perspective that is more appropriate in terms of making a decision. And by holding that loosely, you can move on quickly and not carry it. I think that's what I've seen in great engineering teams do that well.

So when you came into Cloudsmith, the engineering team was actually quite small, and obviously it has grown over the last couple of years into a pretty big engineering team. How did you go around structuring that from kind of inception of a few engineers up to where we are today?

Yeah, a journey continues to be a journey and there's lots and lots of things that go into that. As a small team, we were a very small team where we were reactive. We were just getting what's the most important thing we can do right now? And that was what was needed. And as we've grown and as we've added great people, more structure was required, more processors required more intention about how we communicate was required in terms of organisational design and structure. We got to a critical mass of about eight or 10 engineers, maybe a little less and needed to. And at that point we had two squads and generally we were bringing work to the squad that had the bandwidth and that was fine at the time, but we needed to evolve that to having as we grew, to having clear ownership so that a squad could take and develop a capability and then use that knowledge that they've gained to go deeper and add to that as well.
So that helped essentially shape the start of a more structured approach. We are big on guiding principles and maybe we can talk a little bit more of that later. But the guiding principles for structure was okay, so just enough structure, just enough process, durable teams. So we weren't having people move based on the work. We wanted to build that and deepen that knowledge intentionality about how those interactions, how the difference worlds work. We also, I think a big part of the success is planning your target organisation. So we planned what the organisation looked like with 20 engineers when we had eight and with 30 engineers when we had 15. So much as you might have a target architecture for your platform and you make decisions in that context. We have a target organisation for our people as well. And all the slots haven't been filled yet, but there comes a point that for example, one team might become too big to operate as one team anymore. You can see kind of when that happens, we plough that quarter to be out in advance. I do that in partnership with the head of product as well. So we're aligned organizationally as well as from a product strategy perspective.

Yeah, and do you think, I would imagine that developers themselves, the engineers would feel good that there is a structure that they can operate within and understand?

Hundred percent think one of the challenges I've seen in teams, high performing teams is when the strategy isn't clear to them, they feel like we're just working on the next thing. And that strategy, I'd be the product strategy and often is, and equally it can be the people, strategy engineers, talented engineers are want to know what's ahead, what are the opportunities, how can their career progress in their career, how can they potentially move? How is the organisation likely to grow and what that means for them. So being able to articulate that and even to gain confidence in leadership that there's a plan here and we're not just reacting because sometimes you need to react again, an incident happens, you need to or as a crisis of some form or a unexpected opportunity relating to a customer comes up and you need to react and be resilient to that, the change that goes along with that. That's all part and parcel of being a great team, but you need that ability and you need the ability to, or you need the knowledge to know, listen, there's a plan here and we're moving. That plan is intentional and we're moving in a specified direction. Yeah.

So you mentioned guiding principles. I guess what are those guiding principles?

So they apply, they're context specific. So for example, in relation to the software development lifecycle or how we build, we have guiding principles around not being too specific and being autonomous and having just enough process and having durable teams. As I mentioned, engineering principles are separate, somewhat related, but separate. They live in a separate space and they cover design decisions. What we do around building in the monolith or microservices, what we do when we think about costs and the cost of building a new capability. So we have about 16 or 17 guiding principles very specific to engineering, and they allow us to make the right decisions or best decisions we can, given the context when we're stuck or where there are different perspectives, we can lean back into our engineering principles and see well based on those, what's the right decision here?
The guiding principles around how we communicate with customers in the event of something happening or in the event of product being sunsetted, for example, how we run incidents. And in some cases you need more than just guiding principles. We need to be more prescriptive. So it's very easy, no, I need to make a call. What is the answer? And on call for example is a good, like what's expected? Well, I'm on call, what's expected of me, what's not? Black and white is good there, but in general, a set of guiding principles to help us map out how we work and how we make decisions I find is both empowering to engineering teams and just enough process. And as we grow, that needs to change and evolve, but it's something that we want to embrace. I would recommend engineering teams embrace that mindset or the guiding principle to help them make decisions.

Over the years you've worked with multiple teams in multiple companies, presumably some of them have been remote, some of 'em have been in office. How do you think about building remote first teams nowadays, which seems to be maybe a bit more the norm?

Yeah, we could record a full podcast series and many have about remote first teams. Listen, every engineer more less that's been in our business for the last 30 years is used to working with some remote teams. And we have teams in Ireland and the US and Malaysia, India and Australia and each of those locations. And the remoteness of it brings its own set of challenges and opportunities too. More recently, in the last number of years, remote first has become much more common even within a single region. And for the most part, from an engineering perspective, it brings great opportunity. Engineering is a discipline that requires both focus, time, writing code, working out what's next and collaboration because no one person is going to define the design, the platform to make all the right decisions. So I think remote first teams can strike a great balance of getting the right mix of both of those things. And I think engineers really appreciate that.
I think it's the most important things to be intentional about your remote strategy. So striking the right balance of interaction of places to collaborate, of synchronous and asynchronous of focus and serious areas, discussions, and of fun as well of remote first doesn't mean remote always. And I think it's really important in person time and collaboration and trust. We spoke earlier about the importance of trust in any high performing team. It's very hard to build that trust remotely. The benefit that you get from spending time with people and be that both socially and collaborating in person in front of a whiteboard is massive. So that intentionality is critical to it. It also depends on the size of the organisation and the type of teams. I've worked with some great teams in Eastern Europe and what most was, and they were remote most of the time, what was the probably critical success there is that we made sure that every team be it based in Ireland or abroad, were having in person time twice a year.
And there was a cost and investment required in that, but it was absolutely essential for our success. More recently, clear hiring strategy. So remote first doesn't mean remote anywhere. So for example, at Cloudsmith, our hiring strategy is, so we're a Belfast company, we're proud of our Belfast heritage, and we look to hire the best people that we can find at Belfast. We also hire on the island of Ireland and we hire in mainland UK as well. And that's a strategy. Good engineers, I'm sure there's lots of good engineers in South Africa and Brazil and the United States, but that doesn't fit with our hiring strategy. And so being clear on that is also important part of how we get a remote first to work. So hiring people in the same kind of general region for us is a big part of it. And then having the pattern of in-person time and remote time as well.
So what's working for us as a company, we come together three times a year and that's a really important investment that we make to build those connections, not only within teams, but very much across the different functions in the business. And then from an engineering perspective, we come together as an entire team, another three to four times per year. And that focus is partly on learning. So we spend time topics that cover the broad engineering team. We may have guest speakers from other business functions there as well. And then mixing that with focused within a smaller team or a squad, they might focus on the plan for the next quarter or going deep on an area that is just better done in front of a whiteboard. And then beyond that, again, teams have the autonomy to come together. They want to go and travel to Belfast and work on something to travel as a dull. And that's something that we do as well. So it's intentional. It gives the space of strikes, what we believe to be the best mix of focus time remotely good interactions every day, and then in person time on a relatively frequent basis. It doesn't mean in the office two days or three days or four days a week. For me, that's not the right balance for us.

And then in terms of just that interaction remotely, so obviously once you have met in person and then you go back to your desk at home, how do you manage the interaction within teams and across the broader department?

So again, it's intentional and it mirrors how it follows the work. So for us in engineering, all of our engineering teams have interactions, have synchronous interactions every day that might start off with a check-in in the morning. Sometimes some of the teams that do some of those check-ins asynchronously as well. We try to keep Fridays mostly free of meetings, but they're short check-ins, making sure that they're establishing contact, everybody knows what's going on, people can ask for help. A lot of what we do is asynchronous. We use Slack almost exclusively. Emails, just a place where messages go to die as far as I'm concerned. So the tooling that we have, it supports that remote work. It's important to keep an eye on the frequency of meetings and protect that focus time as well. Yeah, so those regular interactions, we have a couple of slots during the week and people just can pop in and they may want to talk about a technical topic and share something or ask for feedback, or they may just want to talk about what they're up to for the weekend. And there are slots that people can drop into as well to maintain those. And some people want lots of social interaction and feed off that and get their energy off it, and some don't. And that's okay.

I mean, we've always been big users of Slack, and I think as we've gotten bigger, it's been interesting to see how big and how many banter channels we have. And I do kind of feel like a lot of our culture does kind of live online and live in Slack. Just in terms of the nature of the transparency of communications and both personally and professionally. I mean, it has grown quite substantially there. I mean, there's a banter weekend, there's a banter, pets, there's banter, chop banter run. We literally have 10 or 12 channels that go across multiple aspects of what you would be thinking about in your personal lives and bringing that to work and sharing it. So I guess I think that being a really important part of that remote side of things.

Yeah, I completely agree. You can't have trust if you don't have openness and vulnerability and sharing some of the crazy stuff that's happened to you as well. I think another thing that you see on the use of Slack is, for example, when a senior member of the team comes on and asks a question or makes a mistake and says, I got this wrong, that's tremendously valuable and empowering to others and go, okay, I thought they would've known the answer to that, but they don't. And so maybe where there are feelings of imposter syndrome, for example, which are very common in remote interest in general, seeing people opening up and be vulnerable or admitting mistakes, we celebrate those kinds of things and they feed the culture too. And Slack plays a big role in that as well.

In terms of the, I suppose the flip side and changing tact a little bit, the flip side of Slack is it can be a bit overwhelming at times. There's a lot of messages flying about across departments, internal departments, which are pretty transparent in many ways. You can join as many channels as you want. There's not, we do, most things are public. So I mean, how do you think that kind of affects an engineer that needs that focus time and leaning in towards the topic of stress and burnout? How do you manage that for or help your teams manage that?

Yeah, listen, it's one of the, every strength can become a weakness as well. And the strength of Slack and the openness and transparency can be problematic if it becomes too much of a distraction. It's something that we try and keep an eye out on individuals, much like living an email. Some people like to operate inbox zero and spend a lot of time doing that, and others have a different approach that works for them. I find it somewhat similar in Slack. We talk about it, which is important. We don't expect everybody to understand everything that's going on across the business. We use Slack AI to help summarise, but then that's something that we continue need to adjust for because there's a lot of information there and it's very easy to be distracted by just trying to keep up with everything that's going on. And that's not necessarily what we're looking for.
Stress and burnout. And while that can contribute to stress and burnout, stress and burnout is, it's common in engineering. Teams are moving fast. The high pace of work is common in our field, particularly in companies that are scaling up. And it's one of the things that we're attracted, certainly one of the things I'm attracted to that pace of work, but it could be very easy for that to spill over to become too chaotic to induce stress and lead to burnout as well. It's one of my key responsibilities as the engineering leader to make sure that we're striking a sustainable pace and make that a goal and talk about it. And there are times that we need to push harder.
What I like to think about is that, so our goal is to maintain a high cruising speed in terms of operating sprint harder when necessary, but do that in short bursts and make sure that on the other side of that is there's a return to the norm, and that can be over the course of a three day period or over the course of a three month period. And there's also things that it's important for us as leaders to do to reduce context switching, to make sure we're not operating in a firefighting mode by having good practises for planning and for prioritisation to identify where the needle has gone too much. The other direction we're sprinting to for too long to take a breath.
I've used in the last few engineering teams have led what we've call the focus framework. So we're measuring the amount of investment we have in building new capabilities and improving existing capabilities and features, but also investing in productivity and investing in reefing, keep the lights on, kind of worked like serving the business and answering questions and helping customers and doing upgrades and that kind of stuff as well. By having that balance, it reduces the panic and the chaos and ultimately drives towards achieving a sustainable pace as well. And listen, it's not just on the leaders. Leaders have the most important part to keep an eye out for that, but a healthy culture has, and we see this a lot as engineers looking out for one another as well. They spot the signs. We're in this together as a team, it's not just the manager's role. And that's something that we encourage as well. And it's very healthy team where the teams are autonomous in many ways, but they're also looking out for, and they're also looking out for one another too.

Yeah, I mean you typically would see that on, on-call incidents, not to go down the on-call route, but I'm always impressed when you see the number of people that respond to an incident and get on a call and want to provide advice and help.

Yes, and we spoke about psychological safety earlier. I think a really important part of this is making it okay for people to call out when they're feeling stressed or overwhelmed. Again, it's really important that people know that they can do that and know that that's not a poor reflection on them. It's actually celebrated and they're congratulated for it. And that these are really important ways of making sure that stress and burnout doesn't become a thing. Chaos is fine in short, and we talked at the start of this podcast, chaos is something that we're attracted to or managing that chaos, but it's not something that really can be done on a, it's not sustainable in time. So finding that right balance is key.

I really like some of the things that you said about sustainable pace and a high cruising speed, and we've touched on psychological safety and hiring and everything. Is there any other advice you would have for engineering leaders?

I would say from, to be authentic, you're a leader. You're there to provide clarity to your team about the direction you're going. We touched on product strategy and also the people, the organisation development. Create that open environment, safe environment, encourage people to speak, listen, listening, asking people about the challenges, being intentional about how you interact. We talked about remote strategy. I think that's critical as well. Celebrate the wins and have the hard conversations and don't wait to have the hard conversations. I think that's, for me, if there's one thing that I've learned in the last four or five years and do better that now, it's having those, creating that open environment where it's safe and having the difficult conversations about a design decision or a people decision or how to address firefighting situation or where some process is no longer working for you, just go and have that difficult conversation and just do better. But ultimately, as engineering leaders in a high growth or high performance environment, we, it's changing. Be prepared to make changes, go on a journey. There's no silver bullet, but all of the things that we've spoken about today, for me, make of the culture in which talented people can thrive and ultimately provide products that fuel the growth to the business.

Thank you so much, Ron.

Thanks. Enjoy that.