Episode 29 – S2E9 | From Tech Expert to CTO - How to Grow Without Burning Out w/ Andy Skipper

Welcome to the Unotime and Podcast. I'm your host Agagaya Ovnik, certified OHD practitioner, business coach and a founder of Innovation Integration. I help neurodivergent founders, leaders and professionals build profitable businesses, brand friendly teams and workplaces where people thrive, diagnosed or not. This season we're diving into how leaders can boost performance, prevent burnout and make inclusion truly work by designing brand friendly organizations. Today I want to look at how leaders grow, manage high-performing teams and prevent burnout and to make this discussion album more diverse, I invited my old friend and the skipper. He is a founder of City O craft where he helps thousands of 30-os and senior technology leaders build the skills, experience and resilience needed to thrive in the most demanding tech roles. Andy, thank you so much for joining me today. Before we dive in, let's do a little warm up. What are you up to this day? Wow, so City O craft is in the middle of event season. We just had our London event, which is our flagship event last week, which was fantastic. We had about 450 people there, but we have seven other events happening this year, alongside lots of local events as well and different cities around the world. It's busy times right now. We're in the middle of organising and coordinating and bringing in lots of great speakers, panelists and facilitators. That's what we're doing right now. It's amazing to actually hear that I remember your first event that I was at and was in a small conference room and I remember you had this vision of helping people. Maybe before I start with all of the questions, can you tell us a little more, why did you start City O craft? What drove you to do that? Yeah, so I guess City O craft is kind of what I wish I had had when I was in my first leadership role. Essentially, I became a City O almost by default in that. I was the most not necessarily personable, but the most capable of working with people among the technologists within that team. But I was also quite good at stakeholder management, whether us the team really didn't have that skill set, but I was in way over my head. I wasn't prepared for how far away from the technology I would have to become. In the end, I moved too far away from the technology because I was trying to compensate for how much of the people staff and the stakeholder management and the commercial staff I was having to do. It was a traumatic experience. I'll say that. But City O craft really came about while I was a fractional CTO, so it was a fractional CTO for a long time and found that the part of that that I enjoyed the most was actually coaching CTOs who were struggling to basically coming into companies because they needed to increase their productivity or improve the culture and so on. A lot of the time there was a sitting CTO who was quite young in experience sometimes or just burnt out and say, I basically took that coaching part of what I was doing and built CTO craft around that. And it was originally just a community of people that I was coaching. And now it's far, far bigger than that. Can you share a little bit more about what you notice when it comes to changes that most of those leaders go through when they move from being a great technologist to being a leader in a tech organization? When you're an engineer, there are two things. You're an auto-died act very commonly. You sort of taught yourself how to build stuff, how to overcome certain problems or you might be through a boot camp and then you've had certain sort of commercial experience and so on. And then you're expected to take that and know how to lead other technologists. Also, when you're an engineer, you're expected to perform what I call technology heroics. So you're kind of the savior of the tech when you're a senior elite developer. And when you become a CTO, it's a much more kind of strategic and commercial role. And people overlook the needs to train people in those skills because it is a different set of skills. So either people do what I did and swing too far away from technology and become too untankable or they kind of isolate themselves and they become very protective of technology and they hire people that they know, there were clones of them and so on and they don't integrate themselves enough with their first team as you would call it. The other C-level people and the other leaders of the different functions. Those are some of the usual issues that you see with brand new CTOs for sure. Since it's such a huge change, what would you say changes in terms of identity, how leaders adapt when stepping into this much broader leadership responsibilities? When you're offered a C-level role being being an individual contributor, it's a massive ego-boost rate. So you know, there is a lot of ego attached to becoming that senior or becoming that trusted within the leadership organization. And that could be very dangerous because, as I say, it's actually very difficult to succeed in your very first CTO level role. And so you do have this situation where you either have to recognize that your ego is going to take a hit at some point or you have to shed load. And really see that that's really, really tough. And from an identity point of view, that means you're letting go a lot of the stuff that you have one favor for in the past. That it's also having to acknowledge that there are a bunch of new skills that you don't have that you're going to have to learn and very commonly have to learn on your own. You don't often get the level of support in learning those skills in startups. I'll give all skills. What would you say the skills and behaviors that make this biggest difference when it comes to long term leadership development and success? So biggest skill I think is dealing with people. That's kind of a catch all umbrella term. But realistically, you can become very senior as an individual contributor without really needing to deal with people very much. And that can be a massive issue. But from my personal case, what I need to learn in terms of skills was how to do stakeholder management better. So I need to become more commercially minded. I need to become better at translating. So better at sort of taking what I knew about what was going on with technology and the issues and the technical debt and the issues with the developers and being able to translate that into actual sort of commercial language or language that the people above me or alongside we would understand. Actually, will you like the fact that you're talking about that translating? Because lots of people think that industry called the management. It's the people management skill where you can see that you do have to have like this additional heart of commercial awareness, I would say, where you need to understand how your tech makes sense for people to accept it and adapt it if they start questioning why are we even developing that? Yeah, absolutely. And you know, that is not a skill set you learn while building software generally speaking, unless you're building for yourself. It's a tricky one. There's no specific set of training that can give you that. I think you have to be in a situation where you can absorb that from the rest of the leadership team or from the founders of your startup, if you're in a startup, it's quite difficult things to pass on. So even though you're very, very smart, you're still struggling with so many things outside of your A-reviewers for teams, isn't it? Talking about smart people, how do you approach leading teams of highly autonomous, highly intelligent people that I know many of the tech teams consist of? Yeah. I mean, if you've got good people, generally speaking, the best thing is to give them as much support as you can and stay out of the way. But it can be quite common that a very, very autonomous team will not want to be drawn into decisions about where the company is going, for example, or where the product is going. They may be quite dogmatic. So you have to be quite pragmatic about how you deal with those people in terms of if they need to be reigned if they're focused too much on architectural engineering in a certain way that doesn't actually meet the needs of the business. He has to be quite sensitive about that. But generally speaking, if you hide the right people, if you build the right culture and you're able to have a situation where you can give and receive feedback without there being negative connotations and blame culture, then generally it's quite easy to manage that sort of situation. But yeah, definitely stay out of that way. I remember once I went to Hakaten and I was responsible for the UX design and conversation of things and then we had this one developer. We agreed on what we're working on and then he just took his headphones on and started coding. And after like five hours, he presented something completely different and we're like, we didn't talk about this. He's like, yeah, I know, but like I really wanted to test this technology. So I wanted to code this. That was one of my most favorite interactions with a very high-need focused tech person. Luckily, it was a hackathon. So it wasn't really a commercial. But talking about management, obviously management is never easy. Unless you have amazing people and you have the skills to be able to do that. But what would you say are the common traps leaders fall into with these teams and how they can potentially avoid them? I'd say the biggest trap that most new leaders fall into. So I thought specifically about new CTOs or fresh leaders in the engineering space. Biggest problems tend to be around delegation. So essentially, if you're coming from a position where you're the technical hero and you've been doing all the hard stuff and that's how you've made your way into a C-level role, it can be quite hard to kind of give some of your toys away and allow other people to take responsibility for stuff. That's a big problem because it builds a culture of lack of accountability and lack of trust and all that sort of stuff. So that's a huge one. Another thing new CTOs, again, will stay with new CTOs because these are commonly where the problems happen. They sort of even out overtime. They don't listen to people. Very blanket statement that it's quite common that they will be in a position where they expect to be able to solve their own challenges. Because as I said before, you know, quite often there will take Died Act. They've built a set of skills around solving problems on their own. because that's what you do as an individual contributor, which means they can be quite resistant taking advice from people, especially if they're not tanical and so on and so forth. That is a very, very dangerous situation to be in. I believe that this shift must be really hard for people. I actually have seen it quite a lot. So how would you say you can create psychological safety when it comes to creating that space for people to develop in their new roles while also still maintaining high standards? Because as you mentioned, you mentioned culture quite a lot. You mentioned people doing things by themselves that can lead to burnout and many other things that can really be tricky when it comes to building that new role, a new environment to work in. Just these small organisations, the stakes are very, very high and the pressures immense. Yeah, it's really tough, very young organisations, because as you say, the run away is short, the market is competitive. Quite often, the company will be led by people who don't have a lot of experience either. So it is incredibly tough. That is where I most commonly see CTOs burning out in the first year, maybe two years with their company. There has to be an honest conversation with the founders of the company or whoever's in the CEO role or who I was in the leadership team around how they see the people within the teams and how they deal with them. I don't think a CTO in isolation can affect the whole company in terms of culture and the psychological safety and so on. It has to be a collaborative effort. But you can lead by example as well. You can certainly show what it's like when there is this culture of accepting that failures happen and you work with the teams to kind of go beyond them and so on rather than blaming and holding people to the torch. I don't think you can change the culture entirely on your end there, especially in those early stages. All you can do is show what it looks like, but that can be very hard to do when you're in flight. Early in the season I had one guest that mentioned something called Brave Penguin Award, which was an award for failure. Every quarter they would pick an idea that someone wanted to test but they didn't work out, but they learned something and they originally failed. But like they still got this award because they got lots of learning from it. Do you have any specific strategies that you sometimes use that you would be able to share? Like how you can introduce the psychological safety and space where people can fail based on what you've done in the past. So the way I've always approached it is to hold myself up as an example, which means acknowledging where I screwed up, acknowledging my vulnerabilities and that tends to be the most successful approach for me for my nature, how I present myself as a vulnerable human being to the rest of the team. I bet too many people it might be very difficult when it comes to failure or burnout that you mentioned before. How much burnout is about the individual way of working versus their organization and design when we look at a little bit more mature organization? burnout essentially is a mismatch of demands and resources and those demands are both organizational and market based and internal. I have no figures to back this up. It's all anecdata as they say, but I find that newer divergent people are much more prone to burning out in very early stage startups in that kind of role. We don't notice when tired, what do you mean? It's like we need to drink water, we need to need our own body, needs now sleeping boring, come out with MD. We tend to overcompensate for weaknesses that we perceive in ourselves and that's not just neurodivergent people, I think that's that's everyone. That is a very common cause of burnout in early stage startups that you don't have the experience of getting through difficult times and managing your own energy in the correct way. Quite often, as I said before, the other leaders within the team will be quite inexperienced as well, so there'll just be additional pressure and that is a vicious circle that reinforces the sense that you're not very good, which is this self-inhefficacy part of burnout. Essentially it leads to people having to leave companies very, very often. And what would you say are the first signs of burnout that you notice? It varies very widely. Physical exhaustion is quite an easy one to see, the things like musculoskeletal issues and hunching and ulcers, they're sort of the most visible symptoms, I guess, but if you're actually talking to people, I think probably the first symptoms that you would see would be around cynicism, skepticism about the mission of whatever they're working on or the journey they're on, they start to doubt themselves, essentially. They think they are very common, but you won't get to those without a pretty in-depth open and trusting conversation with someone, and quite often you won't get that from a start-up CEO or a founder or so on. Because they're probably close to burnout themselves. Very likely. Are there any practices or environments that you've seen that can help leaders stay effective without burning out? Talking to people realistically, I think that is one of the biggest benefits that being in a community like CTO CraftHound, you get to see how stressful it is for everyone else who is in the same sort of role. It is a stressful role, it's quite an isolated role, and it can be quite an ambiguous role and all these things lend themselves to burning out. Unless you have a group of other people who you know you can be open and vulnerable with that you can discuss some of these things with, you will never be able to calibrate against how other people are finding this kind of thing, and then how close they're getting to burnout and how they pull themselves away from it. Need to talk to people. As you said before, the founders might be burning out as well, so even just a conversation with them you might find that there's quite a lot of commonality there that you have to do, but you can't resolve burnout completely within yourself. You have to talk to other people. I've been building my company for 15 years, and I noticed for many years that it was really difficult for me to actually find a peer group because lots of people I would speak to are very often there are early stages, so there are more like a client profile rather than a peer, and when I realized that I did not have anyone to talk to, and it was actually really lonely and very painful, and at some point I started looking for people not only who are on similar level of experience than me, sometimes I would just go to like different experts in different fields because I knew that like I could kind of like maybe like Frankenstein support system from different people, different abilities, and at some point I remember I just moved away from the actual technical abilities and started looking at people who had similar values and maybe like went through the similar things that I went through because I know even now when I speak to some people and they say, "Oh, I spent forever vibe coding," and I didn't see it until three o'clock and I'm like, "Please, no, it's like you're giving me excited just from talking to you. I want to surround myself with people who want to sleep as much as they can. We can prioritize things that really matter so we don't burn out in a long run and I feel like in startup space there's this culture of hustling and always being under pressure and basically glorifying being busy and running around and solving problems and being this as you said, like the person that has all of the answers, ends up making people feeling really lonely and really struggling in any of the holistic management and holistic professional development. Have you seen that happen at all?" Yeah, many, many times. It's quite easy to become isolated, not just in work but also in your personal life as well if you're pouring that much energy into a company. It takes quite a lot of maturity to recognize when you're giving too much room yourself to a company like that, especially when you've got that ego kick of being given a sea level title as well. It's tough. It's very isolating. By the way, you're so calm that I'm so relaxed talking to you. This will be a very calm, meditative episode. As I mentioned earlier, I meet lots of people, crazy about vibe coding, agente AI, things happening, being very busy. How do you see the CTO role involving over the next few years, particularly with AI development and increasing strategic demands? Because obviously decision-making has to be done so quickly now. We used to manage people, now we manage people and agents and there are so many things. What do we do? We're having this conversation on the 18th of March 2026. I think if we were to have the conversation again on the 18th of May, it would probably be a different answer. I'm releasing this very verse and I'm releasing it on Tuesday. I just recorded it straight away because I knew it would be outdated. This is the issue entirely. You can have a strategy around how you experiment with AI and how you try different things with it. But right now, I don't think you can have a long-term strategy around it. That's my personal feeling from people I've spoken to. It is very, very tough as a CTO right now because of the amount of pressure we're getting to implement AI and AI enabled coding and changing what our engineering teams do on a day-to-day basis because of the tooling that's now available to them, which is apparently making them more productive, in some cases less productive in other cases. But until the evolution of this AI technology starts to stabilize a little bit until it starts to flatten out, it's really, really tough to know what our role as a CTO is going to be. But I would say we're always going to need humans looking at code, if not building it from scratch. And if you have engineers who are responsible for the quality of code and the security code, you still need CTOs, right? You still need people to manage those technologists. There might be that the actual day-to-day work is a little bit different. I do think CTAs who have become less technical, who have gotten further away from the code, are going to need to get a little bit closer to development of code and products. But as I say, if we had this conversation in June, September, it could be a completely different answer. We're still kind of finding our way a bit. But it's fun to watch the community try all these different things and see what's working for them, landing on different ways. In some cases, they're building their own paradigms for coding approaches with AI and so on. It's a really exciting time, but nervy, but exciting. So let's park this tech part and let's focus on the leadership part. So when we're looking at those things on how they're developing and obviously tech will always change. Like I've seen this happen, we had digitalization, we had agile transformation, now we have AI transformation in lots of organizations. Only the sheep's capabilities that do you think were the next generation of leaders need to manage that process. In the immediate term, there's a lot of tension, a lot of fear among engineers and among engineering leaders as well about what it might bring, what might our role look like. So I think the biggest need from CTAs right now is empathy and sort of understanding that because so much is in flux and experimental and engineers don't really know what the future is going to hold for their role or how they do their work. Just being open to the fact that that is concerning and they're also seeing in the news that thousands of people are being laid off because companies can see that AI will reduce their overheads. That can be very nerve-wracking. So empathy for the flux that we see and also recognizing that it can be a lot of pressure on yourself to sort of stay up to date with the latest. So I think one of the biggest things CTAs are having to do at the moment is support their engineers who aren't really sure where everything is going. At the same time, it's not really understanding where things are going or having to accept that things are experimental, but they're getting a lot of pressure from non-technical people to become more productive and so on. Which puts a lot of weight and a lot of demand on how engineers are doing things and the technologies that choosing that sort of thing. But it's also self-awareness and knowing that dealing with that amount of pressure and certainty can take a lot out of you as a leader. So having to deal with everyone else's uncertainty but also having to be the umbrella against the rest of the world expecting big changes from using AI tools. It's tough. So now when we look at those engineers that are actually quite stressed, I know a few myself I collected some questions that I'm going to ask you in a second. But when you look at people who are feeling a little anxious in the current environment with AI developments and with all of the firing going out there, what would you say are the gaps in leadership development for tech leaders today? So how they can potentially future proof the roles. Specifically around AI or just in general. Just in general, I'll say like are we parking tech for now? This is March. Let's see what happens in July when we have a chat again. I'd say the biggest gap that I see in most CTAs of AI coaches, commercialism and commerciality, to understanding how their role fits into how the business operates as a commercial entity. There is not a lot of good training material out there to get you up to speed on that stuff. And the CTAs of the CTA being most successful have at least some kind of entrepreneurial spark to them because they're able to work more closely with commercial sides of the business and understand that what they're building or what their team's building, how it contributes to the success of the business. I think at some points CTO craft will probably build out some tools and some training and so on to help new CTAs become more commercial. In the meantime, I'm happy to plug in our first season, it's all about business model canvas. We have 10 episodes around 30 to 40 minutes long that cover entire business model canvas in like a very simple way. I actually agree with you because I see the same problem with founders. Sometimes they have fashion, they want to develop something but because they don't really have this big picture on how this thing can be developed, how value proposition can be designed and then deliver to the customer and how the entire business works so they don't really have this commercial view of their business like they really struggle because they either get stuck in not being able to break even or take their startup to the next level or in general at burning out because the resources don't really align. So yes, definitely totally plugging in the first season of in a time of podcast we'll link that and then when Andy develops something with CTO craft we'll link that to and with that I mentioned earlier I've been speaking to some tech people and collecting questions during my networking events and also we had Q&A audience form which by the way also will link so if you have any questions to be asked in future episodes please drop them there. So one of the questions was how do I balance doing what technically or logically best with what's politically feasible or strategically necessary for the team and organization? Okay, that is the kind of question that I would push back on wanting to know a bit more about the context. There's no single approach to that I don't think unfortunately I wish there was but there isn't. I actually like that one came from someone who is really technical and very often he does have all the answers but his commercial counterparts in organization push for other things and then there is this friction because things are not moving in the right direction or in the right speed very often so then he ends up sounding really abrupt in meetings. Gotcha. Yeah, yeah. So this is stakeholder management essentially. So basically the commercial side of the team and I'm going to paraphrase here the sales part of the team are expecting things to happen more quickly than the engineering teams is expecting them to happen. Well sometimes they want magic as well from what they heard like they sell things and then they come back and say they do it. So you can do it. So part of the team is not based in Hogwarts so they can't achieve so much. But now it's a really difficult one and you know I've been in this situation as well where the sales part of the company have huge targets and they have a huge pressure and they expect a lot from the engineering team and they quite often make promises that the engineering team hasn't been privy to and that can cause a lot of tension. I think the best CTOs are the ones that can translate the needs of the sales team to technology without overloading them that can also negotiate with the sales team about what's actually possible with the engineering and a capable of sustaining a road map that they don't veer too far away from just because the sales people say to. It is about communication and collaboration understanding that you're part of a broader leadership team and not just building stuff while also keeping to a road map and keeping to a bit of discipline there as well. But it's very tough. It's very tough. I've noticed in my experience when I was building operational systems, especially in like scaling startups, what's very useful is actually involving people in trying to understand how much time things take and how difficult or easy they are. So actually inviting them to select square meetings or retrospectives and making them aware of this take, not taking two minutes. Okay, maybe now we're vibe coding. How are you taking two minutes to create? But it does take setting them out of work and complicated processes in order to actually do this because especially at the very beginning of my career when we were running hacktons between kind of a take and business, I saw that tech guys they just wanted to let us build this and then just like come and present it. And I'm like, that's really working. We need to get you guys connected and work together. So yes, I compare it. It's so important. Question number two, how do I know when to stop doing the work myself and start enabling others, especially when I'm worried they want to meet the same standards that I have? That is actually quite a common one as well. When you get to a position where you might be offered a sea level role, it's more often than not because you've been an amazing engineer or an individual contributor. So again, the ego comes back in. You have validation that you are capable of producing the best output as an individual contributor because of that title you've been offered right. So it becomes very difficult to see anyone else within your organization producing as good quality stuff as you can. But that doesn't mean they can never produce quality stuff as well as you can. And I think knowing that you are holding other people back by not trusting them with some of the stuff purely because you want to see it in a specific light, the output can be very dangerous. It will not lead to this culture of trust and lack of blame and positivity and psychological safety and so on. If you don't trust your team enough to produce things and also it's good training for you in how to set your expectations with people. If you can't verbalize your expectations around quality and approach and so on and so forth, then you can't lead a team essentially and you will always need to dip back in. Yes. No, actually because obviously I see the same thing with founders very often is what you mentioned at the very beginning. They either hire exactly the same people. Right. and they hope that they would just like, "We're just like with their mind." And they're really annoyed when they're don't with their mind. But one of the first things I always bring in is like, "Okay, so tell me what's the definition of ready and the definition of done." And for the first month of my work with them, I just like, "A drill it in every single meeting." What's the definition already and the definition of done? And at the beginning, they're so annoyed with me because the fact that they have to slow down their brain and then explain it to me. And then we have to put it down and then they have to be responsible for the put down on Trello or on any other form of sharing the instructions. It just drives them crazy. But then it's really nice to see how from one week to another, they slowly say, "Okay, so this is the definition of ready. "This is what I want done. "This is what I need." And being a little bit more specific, I noticed that also helps them in organizing their faults in their mind. And because of that, it's then much easier to produce those faults to other people. So you realize how much chaos you had in your head because you're so strategic and you're so fast. And then you just need to slow down and see what actually makes sense to put down on paper or not because it feels very real compared to, like, you should know, you know? - Yeah, right now. - Okay, question number three. How do I determine? And actually, this one is very interesting. One, and I've seen quite a lot in the past few years with people who got promoted already. So that comes from this kind of person. How do I determine whether I actually want to lead or whether I can do it without burning out or losing the things that make me a great engineer? I really miss solving problems and coding. So this person is kind of like in between. And actually, that question came from someone who went back into being an individual contributor just. - I was good. I was good to ask. I was going to ask. I think if you're asking the question, then there's already a doubt, right? I wouldn't say necessarily that if you are going to become a successful leader, then you will never have any doubts. But I think if it is forefront in your head when you're thinking about your role and, you know, that initial thought is, do I even want to be doing this? Then probably not is what I would say. But I have certainly worked with people who come to me with that question who have stayed in leadership roles. And through coaching, I've sort of understood what it was that they were missing from the leadership part of it or you worked on some of their fears about becoming untanical and that kind of thing. But I'd say if there's a question mark, then you need to at least explore it. And it doesn't matter as well. It doesn't matter if you go back into individual contribution roles. Going back again to the idea of the ego boost that you get from being given a leadership role, that can be really tough. Setting it aside feels like a failure. But being realistic, it's just being fair to yourself. And it's about following what actually makes you happy in your role in your professional life. So I think it's a very positive thing. I actually want to touch on two things with this because I think I've seen that quite a lot as well. And it's quite important. So number one is the element of actually your true mentions through coaching, how you overcome that because sometimes it is the matter of identity. You need to kind of say goodbye to a certain version of yourself to say hello to the next one. So this will be the first one. And then the second one later. The first thing I would say is that it's not permanent. If you decide that a leadership role that you're in right now is not right for you, it doesn't mean it's never going to be right for you. That can make it easier to digest, to have it step away from that back into an individual contribution role. I also say that it can be sometimes that it feels unnatural because you don't have a lot of support or don't have some of the necessary skills to do it. But again, that's a temporary problem, right? And you can learn those skills and you can gain confidence by being around other people who do the kind of role. So it's not necessarily something that you just have to say, "Right, I'm never going to do it. I'm never going to be good enough in inverted commas to do it." And that kind of ignores the fact that it's not an either or it's not that you're not good enough to be a leader, it's that you're better at being a technology person or an individual contributor. It feels like a failure, but it's really not. It's just a strategic shift. Actually, and that clears me to the second thing, which is more of a comment rather than question, but I would love the world to step away from defining one type of leadership because I see so many amazing people who can be individual contributors, but they're spectacular thought leaders that also contribute to shaping organizations and shaping teams and building different ecosystems from a perspective of actually contributing the knowledge and their expertise being spectacular, this tech leadership, rather than a people leadership. And there is nothing wrong with not having to manage a team, is there? No, no, not at all. I'd say staff engineers and principal engineers who have worked with who are very, very technical, they're still leading, they're not managing, but they're leading. That's possibly the key distinction here, where I think what we were talking about before was being a leader in the visionary mission setting sort of sense, but also being a people manager and a culture builder and that sort of stuff, which you kind of can't do both. But you can certainly be a leader and still be very hands-on and be part of the critical path in building stuff and that definitely works. Leadership is not one of the other, but it is all about bringing people along for a journey that you can do that as a technical person as well. I actually really like that. So it's just like if we were to design a startup, we have a CEO who is like a superstar presenting everything, selling things, bringing ideas in, selling all of the vision and mission, then we have a really good CEO that supports people and builds the strategies and structures. And then we have this superstar CTO that is leading through new ideas and expertise and bringing people together based on, let's say, what they believe in and what they want to build. And then through that, can you build the culture? Would we, one, people leadership skill that this CTO would have to develop if he still wanted to be a good CEO, but without becoming a people manager? That's a really tricky one. So it depends on the stage of the startup. If we're talking day one, they are going to have to heavily prioritize building stuff over people stuff. If that makes sense. If it's a year down the line and they're growing to 15, 30 people, I suppose the biggest requirement at that sort of stage is the ability to hire good people and to build a team and then to build a culture that retains those good people, those are the most important skills. Because you're kind of at a point where you validated the idea and the product and so on, but you need to be capable of accelerating production and you've got to have the right people in place to do that. So it's about hiring and then retaining people who are the right people for what you're actually doing. - So let's take someone who is really good at tech. They ended up maybe being drawn into leadership and then startup grew and they became a large organizational leader. I understand different people have different journeys, but if you were to give us an example of what people focus on when it comes to that evolution from, let's say, a very, very smart tech person to a very, very good leader leading people and leading technology would be. - I'm going to disappoint you. (laughs) - There's no one. - The defense on the business, the defense on the person, it depends on the personality, it depends on so many things. What I can do is give you my experience of how I grew, which is not necessarily atypical, I would say, but essentially I became a very good contracting developer and joined a company where they didn't have any technology leadership and so kind of became the CTO by default. And my role since then have all been kind of an amplification of that in that I joined as a CTO and the team grew underneath me. I'd say from my second CTO role onwards, the amount of hands-on technical stuff I was having to do became less and less. And I think that's fairly typical, at least it was until maybe six months ago, where CTO is now getting very technical again because of AI stuff. And I got much more commercial. So in my first CTO role, I was not commercial at all. I had no idea what was going on with the sales part of the finance, I knew he'd taken some investments, but that was the extent of my knowledge. By the time I got to my third or fourth CTO role, I was very, very commercial. I was very close to the CFO and the COO and I was part of the sales process as much as I was part of the team, or at the head of the team, actually building the technology products. That was my kind of project, really, I suppose. So from very hands-on building cool stuff, to very hands-off leading people, building very cool stuff, but also making sure that very cool stuff was actually bringing in the bucks. I just realized our startup that we just designed failed because we didn't have a CFO. We need to build a new one. Okay, lastly, if you could give one piece of advice, to take this about the growth teams or sustainability, all that be. I'd say this is advice not just to the technologists, but to everyone really, it's very hard to do an isolation. If you don't have a good community people, for a next. a small set of mentors or somewhere that you can go to calibrate based on other people's experiences and other people's learnings, it's very tough and it's very isolating. Then it can lead to burn out much more quickly. So find your tribe, even if it's only one person that you can be open and vulnerable with, go out and make those friends, make some massive difference. To all of the listeners, I believe that you have a list of things to do. If not, let me give you a quick one. Think about what kind of leader would you like to be? Do you really want to be a little, do you want to lead people? If yes, why? Why not? Then think about finding your tribe and talk to people. Try to look for people who are similar to you or completely different. They can challenge you so you can develop areas that are not entirely developed and you can build on. Then look at what's happening, have lots of compassion to yourself, but also to your teams. People are going through lots of changes these days and we need to have some empathy to look at this and then decide where you want to be on the scale from very, very technical to very, very commercial and play with that to find your own role. Andy, thank you so, so much for coming today and thank you for being part of season 2 so far. We're almost done now, but I believe that this will open the new conversation and the new set of episodes that we'll be building in the future. To everyone, remember you can always leave the questions in our Q&A form as you see today was the first time when I actually use those questions. So thank you, Andy, for being our pioneer in answering audience's question and for audience, thank you so much for being here. Thank you for listening, for sharing, sending messages, talking me, it means a lot. We're almost at 1000 listeners right now without any promotion, so I know it's only thanks to you and thank you for caring and creating brain friendly workplaces. If this episode resonated with you, please share it with someone who might need it. It means a lot and it helps a little podcast grow. Connect with me on LinkedIn. I'm Aga Gavnik or Instagram microakiydhd brain and of course, our amazing guest Andy, where can they find you? I like to find me on LinkedIn, my name Andy Skepper, but there's also CTOCraft.com. We'll definitely link all of those things in our show notes. I highly recommend CTOCraft. I always send all of the tech leaders there. I remember when you guys started building, you did it in a great way. There are lots of resources, lots of articles, look at, join the conferences and are looking forward to preparing the next episode and speaking with you next week. Follow this podcast on Inotainment Podcast on LinkedIn and Inotainment and Discord Podcast on Instagram. In the meantime, be kind to your brain, be kind to your team's brain and remind the efficiency without burnout is absolutely possible. If we build organizations with brain-friendly nursing mind before we look at efficiency, thank you so much and see you very soon. Take care, bye!