The CTO question has always been complicated. Right now, it feels more complicated than ever. Tech leaders are navigating blurring boundaries between engineering, product, delivery and strategy, while AI reshapes what leadership actually means at the top level.
At our second To CTO or Not To CTO event at The Conduit, we brought together four experienced technology leaders to go a level deeper. Not just to ask whether the CTO role is right for you, but the harder question: do you actually want what the CTO role is?
Jacob Brown, Head of Practice at La Fosse, hosted the evening. Facilitating the panel was Georgina Owens, CTO at Luxion, eight days into her new role. She was joined by Mel Unsworth, CTO at the Financial Times, Shaun Pearce, CPTO at Gousto, and Gareth Webber, CIO at Clarion Events.
What followed was one of the most honest conversations we have hosted about what senior tech leadership actually demands.
Key takeaways
1. The question changes at the top. Engineers solve for how. CTOs solve for what. If you love deep technical problem-solving above all else, the role may not be for you. If you want to shape culture, influence strategy and build organisations, it is.
2. Organisational design is architecture. How you structure teams, accountability and roadmap ownership is as consequential as any technical decision. It determines whether you are the bottleneck or the lever.
3. Politics is an engineering problem. Understand what people are trying to achieve, map your stakeholders, build relationships before you need them, and give yourself time to prepare for difficult conversations.
4. Finance is not optional. Learn it properly. Understanding EBITDA, CAPEX, OPEX and the language of the CFO is the difference between having influence at the table and nodding and pretending.
5. Speed matters on people decisions. The biggest mistake most CTOs make is not moving fast enough when something is not working. It affects culture, performance and your own energy.
6. AI is coming for the shape of engineering, not the need for it. The leaders who are reskilling their teams now to think in terms of specs, architecture and verification rather than feature delivery are the ones who will be ahead.
What actually changes when you step up to CTO
The first question Georgina put to the panel was deceptively simple: what felt different when you stepped into the bigger role?
For Mel, it was the shift in focus from her own function to the whole business. “You become more aware of your peers, other C-suite roles, and how the technology role can support within that.” Stepping into a CTO remit meant understanding what every other executive was trying to achieve and working out how technology could enable it. The job was no longer about what you were building. It was about trading off competing priorities across the leadership table and making sure the whole business moved forward together.
Shaun described a formative moment early at Gousto. His founder sent him an email laying out what he was looking for in a CTO: first, a partner to help run the business. Second, a member of the leadership team. Third, someone to run the technology. “That always just landed with me. I spend more time with the leadership team that runs Gousto than I do with the technology team. I spend as much time thinking about how our performance management process might shape our culture as I do about any technology scaling problem.”
For Gareth, the change was about the nature of the question itself. “If you’re an engineer, someone presents you a problem and you think, how can I best fix this? As a CTO or CIO, the question is not how, it’s what. What should this company be doing? What’s the highest priority?” He made a point that resonated across the room: when interviewing for his current role, the chief exec asked how he would fix their priorities. His answer was that he would not. He would present choices, and the decision would be made based on business value. “I’m not going to be making those prioritisation choices for you. It’s a business decision.”
Organisational design as a leadership tool
Shaun had a distinctive take on where CTOs should focus their energy. “I still love doing architecture, but I do nearly all of my architecture now in organisational design.” At Gousto, this translated into a tribes and squads model where every team, including marketing and operations, is accountable for a clear customer outcome. “If I talk to a software engineer and ask what team they’re in, they won’t say software engineering. They’ll say the Activate tribe. That has bonded the organisation together.” The trade-off? As CPTO, Shaun described having the least direct influence over roadmaps in the business. Everything runs on soft influence and relationship-building with tribe leads.
Gareth approached the problem differently. His superpower, as he described it, is project setup. “We were delivering stuff that just really wasn’t what the business wanted. Making sure whatever the sponsors were after was what the teams were pushing into requirements, that was the thing that got my team moving faster.”
What CTOs refuse to let go of
An audience question prompted one of the most useful sections of the evening: what do you hold onto, regardless of how much you delegate everything else?
Gareth was unambiguous: the purpose behind the work. “If you set out with a team to build the wrong thing, no amount of process or great teams will ever make that right.”
Shaun’s answer was architecture, specifically platform engineering. “The decisions that platform engineering teams make have a ramification across 20 other technology teams.” He still attends the Friday architecture forum every week. “Most of the time I find it fascinating. I don’t need to contribute, but it’s really important I know where that drift is going and where I can intervene.”
Mel focused on business and technology strategy alignment. “Everything that we do and that we work on should align to one of those two things. The technology strategy should support the business strategy. If a new initiative doesn’t align, we need to be calling a stop on it.”
Navigating the politics of the C-suite
The panel were candid about C-suite politics, a reality that derails more senior tech leaders than most care to admit.
Gareth talked through the discipline of stakeholder mapping: understanding the relationships between directors, what they are after, what will make them look good. “If you want to influence someone, make sure some of their projects get some decent priority, and then use them to help support you get other stuff done. It’s human dynamics.”
Mel’s approach starts with understanding individual motivators. “When people feel threatened, or they’re concerned they’re not delivering their numbers, it’s then working out how technology can support that person.” She also made the point that building relationships outside the office matters. “I try to make an effort out of the office as well, whether that’s going for a drink or dinners, just to get to know the person.”
Shaun offered a practical reframe. “Rather than labelling it as politics, think about it as an engineer. How do I engineer this problem out? That person probably wants to achieve something. They might not have the resources to achieve it. They might be being set expectations that are
unrealistic by someone else.”
He also made a point about the tone set at the top. “Look at the collaboration of a leadership team at the top of the organisation and that will tell you what the politics of the whole organisation is going to be like.” If the problems are there at exec level, they will be amplified going down.
One practical piece of advice from Gareth stood out: “If you’ve got a meeting where it’s going to be difficult, allow yourself time to prep. Kick something out before it. Make sure you’ve slept. Go in because if you get yourself irritated, you’re not going to have a good conversation.”
He also challenged the assumption that every CTO must sit on the exec. He pointed to a leader he had worked with who deliberately chose to report into the CEO rather than join the full exec team for her first big CTO role. “She said, I’m going to go in through this route because the CEO has got my back. So I can still influence and achieve my goals without spending all my energy fighting the rest of the exec team.”
Running your own business within the business
As tech teams scale, CTOs must think and act like business owners. The panel’s experience here was varied and specific.
Gareth described the discipline of building budgets that give individual teams clear goals and ownership. “You need to have a number of departments that have clear goals, and they have budgets they have to achieve, and deliveries they have to achieve.”
Shaun emphasised the importance of pushing financial ownership as far down the organisation as possible. “I’ve learned to build a system that gives the person leading software engineering, the person leading product, as much autonomy as possible over that budget.” His advice for new CTOs: learn finance properly. “I honestly did not know what EBITDA was. I’d sit in meetings and nod and pretend I knew.” He built an internal MBA programme at Gousto to close that gap, covering basic accounting, finance and key metrics.
Mel added the human dimension: the ability to hold ambiguity and help teams through it. “A lot of engineers don’t like ambiguity. They want certainty. When you’re constantly changing and moving the goalposts, that can be really disruptive. We need to help teams through that.”
On people decisions, all three were consistent: move faster than feels comfortable. Shaun put it plainly. “Nothing has made more of a difference to the performance of the business, the performance of my team, and also my day-to-day happiness than shaping that team. The biggest mistake is not dealing with it quickly and letting something fester.”
Shadow IT and AI governance
Shadow IT came up in the context of AI, with teams adopting tools faster than governance can keep up.
Shaun described Gousto’s approach as foundation-first: rather than fighting tool adoption, invest in the platforms and principles that allow it. “You can buy any products you want if you’re a marketing leader, but there are certain requirements around what data can come in and come out, and certain requirements around single sign-on.” With those foundations in place, shadow IT stops being the biggest battle.
Mel, four weeks into the Financial Times, was already building a list of what needed addressing and what to leave for now. “If it’s not burning, try not to touch it just yet.” Her priorities: establishing standards, getting finance and procurement aligned to redirect shadow spend, and educating teams on why the controls exist.
Gareth took the most pragmatic line. “My approach is control what I have to. If it’s something I want to replace because I can do it better, great. If it’s an AI note-taker and it’s secure, I’m not going to be bothered.” His bigger concern was governance, not control: ensuring that sensitive data was not being fed into AI tools without proper oversight.
The AI question
The most energised part of the evening was a question from the floor about whether AI is fundamentally changing what engineering is for.
Gareth was direct. “I’m a bit of a naysayer on AI. What it’s very good at is building POCs, templates, the boring stuff around projects that takes lots of hours but isn’t really adding value. The actual thinking bit, what is the architecture, what does this need to do, you need people that think.”
Mel focused on cost reality. “Everyone is thinking if we can get AI to take the space of a junior engineer, we can save the cost of that salary. But the reality is we’re not looking at what the tools are actually costing.” At the Financial Times, an AI community has been built specifically to create guard rails and assess where AI genuinely makes sense.
Shaun had the most bullish view. In February, he took a week off work to use AI tools properly, doing pet projects and then actual tickets. “I had my oh wow moment where I thought this changes everything.” His conclusion: tech leaders have a moral obligation to help their teams rethink what engineering is for. “We’re not building features anymore. We’re going to be building the machine that builds the features. I think that’s an amazing opportunity if you’re a creative builder.” He was clear that it means smaller teams achieving more, and that reskilling is urgent. “They’ve got careers of decades to develop.”
Staying visible at scale
One of the most resonant audience questions was about how you stay human and visible to your team when it grows beyond the point where you can know everyone by name.
Shaun described going from knowing his full team of 60 before COVID to returning after lockdown to a team of 300 where he knew almost no one. “It took me a long time to work out how to lead in that environment.” His current approach is intentional and systematic: reverse mentoring schemes, regular group sessions scheduled throughout the year, skip-level conversations not just with managers but with whole teams.
Gareth pointed to the power of organic presence. “Management by walking around. You’ve got to like people.” And to the influence of the managers you put over teams as your true reach into a large organisation. “It takes months and years to build a culture. It takes weeks to destroy it.”
Mel, just four weeks into the Financial Times, described sitting in on daily stand-ups and retrospectives as part of her onboarding, simply listening and learning the pulse of the team before trying to drive change.
What’s next
This is the second event in our To CTO or Not To CTO series, and the conversations keep getting better. If you are thinking about your next step into senior tech leadership, or you are already there and want to keep connecting with people who get it, we would love to stay in touch.
Get in touch with Jacob to carry the conversation forward, or take a look at our upcoming events to see what we have coming next.