Should Your CTO Still Be the Best Technologist in the Room?

We've spent years telling technology leaders to become better business leaders. But as technology becomes more important to the business, what should happen to the expertise that got them there?

For years we've been telling technology leaders they need to become better business leaders, and I've probably said it a few hundred times myself. Understand strategy, learn the numbers, influence your peers, talk to the board, understand customers, build great teams, stop disappearing into the technology and start thinking about the whole organisation. It's good advice. But there's something about it that's been bothering me.

Because at precisely the same time we're telling CTOs to become broader business leaders, technology is becoming more consequential to almost every important decision a business makes. AI, cyber, data, architecture, product, automation, cloud, engineering — these aren't simply technology decisions anymore. Increasingly they're business decisions.

So why would we want the executive responsible for technology to become less technical? I don't think we do. But I don't think the answer is that the CTO should remain the best engineer in the company either. After more than 20 years interviewing and assessing technology executives, I think something more interesting happens as the best ones become more senior. Their expertise doesn't disappear. Its job changes.

Your expertise got you here. Don't abandon it.

I've met some exceptional technology executives over the years. Some have stayed remarkably close to the technology; others lead teams full of people whose specialist knowledge considerably exceeds their own. I don't think either model is inherently better, and the evidence doesn't suggest there's one universally correct profile. Research into senior technology leadership points broadly the same way: technical expertise still matters, but it isn't sufficient on its own, and as the role becomes more strategic, business knowledge, judgement, organisational influence and the ability to operate across the enterprise all start to count for more.

Context matters too. A CTO leading a deeply technical product company may need very different technical depth from one leading an enterprise transformation. The title doesn't tell you how technical you need to be. The mandate does.

But regardless of the mandate, there's a transition every aspiring technology executive eventually has to make. You have to change your relationship with the expertise that made you successful.

From answers to judgement

Early in your career, knowing the answer is enormously valuable. If you're a good engineer, architect, security specialist or data professional, much of your value comes directly from expertise. You understand difficult things, you solve difficult problems, you spot what other people miss. And organisations reward that. They give you harder problems, then bigger teams, then greater responsibility, until eventually you may find yourself running the function.

And that's where it gets really interesting. The capability that made you successful hasn't suddenly become irrelevant, but the organisation no longer gets its greatest value from you personally solving its hardest technical problem. You might now have a Chief Engineer who knows more about architecture than you do, a CISO who knows considerably more about a particular vulnerability, a data leader with deeper specialist knowledge, an AI leader operating in a field moving so quickly that keeping up with every development is almost impossible. Your job is no longer to prove you know more than they do. It's to create the conditions in which all of that expertise produces the right outcomes for the organisation.

That takes a different kind of technical capability: judgement. You don't need to know more about security than your CISO to ask the question that exposes weak reasoning. You don't need to design the architecture yourself to recognise that an elegant technical solution carries an unacceptable commercial trade-off. You don't need to be the organisation's leading AI engineer to understand where AI might fundamentally change its operating model. And you don't need to settle every technical disagreement yourself to know when you haven't heard enough evidence to make the call.

Earlier in your career it's "I understand the problem, so I can solve it." As your responsibility grows it becomes understanding the problem well enough to know who should solve it, then well enough to challenge the solution you're handed, and eventually well enough to judge what a given decision means for the organisation. The expertise hasn't disappeared. Its job has changed.

From expertise to curiosity

This might be the harder transition. Imagine spending twenty years being rewarded for knowing the answer. Your expertise builds your reputation, people seek out your judgement, you solve things others can't, and that success carries you steadily up the organisation. And then you reach a position where one of the most important things you have to get comfortable saying is: "I don't know. Tell me what you think."

I don't see that as a loss of technical credibility. If anything it's the opposite. The technology executives I find most impressive aren't threatened by the expertise around them — they go looking for it. They ask questions, they let specialists challenge their assumptions, they change their minds when the evidence warrants it, and they keep learning even at a level of seniority where it would be very easy to assume they're supposed to have all the answers.

That matters more than ever right now. If you built your career in infrastructure, software engineering or enterprise architecture ten or twenty years ago, some of what you know remains enormously valuable and some of it won't. The challenge is knowing the difference.

From one lens to many

Technical specialists tend to get rewarded for seeing things other people don't. Enterprise leaders also have to get good at seeing what other people do.

Take a major platform decision. The engineer sees architecture and technical debt. The CFO sees capital and return. The customer leader sees experience. The CISO sees exposure. The CEO sees strategic capability. The board may primarily see risk. None of them is necessarily wrong, and your job is increasingly to move between those perspectives without losing your own. That's not about becoming a generalist who knows a little about everything and nothing deeply. It's about holding several legitimate readings of the same problem in your head at once and judging what matters most. You still need the technologist's lens. You just need more than one.

From instinct to choice

There's one more transition that deserves far more attention: what do you do when things go wrong? Most of us fall back on the behaviours that have worked for us before, and for a technically accomplished leader that often means going deeper — taking control, getting into the detail, solving the problem yourself.

Sometimes that's exactly right. A CTO who refuses to get into the weeds during a serious technical crisis because "I'm a strategic leader now" isn't demonstrating executive maturity. But sometimes the instinct to dive in is precisely the wrong one. You undercut the leader you appointed to handle it, you become the bottleneck, your team starts waiting on your answer, and without ever intending to you build an organisation whose technical capability depends too heavily on you.

The skill isn't staying out of the detail. It's knowing when your involvement makes the organisation stronger and when it makes it weaker. Executive maturity isn't about doing less of what made you successful. It's about becoming much more deliberate about when you use it.

It also changes what I'd look for in your next CTO

After a career spent interviewing technology executives, I'm still

interested in what someone has done — what they've built, what they've transformed, how complex the environment was, what results they produced, how technically credible they are. Those questions still matter. But increasingly I'm just as interested in how the executive has changed as the roles around them have changed.

Tell me about something you once believed strongly about technology or leadership that you no longer believe. Tell me about the last time someone more junior, but more expert, changed your mind. How do you decide when you actually need to get into the detail? Tell me about a decision that looked right technically but wrong commercially. What have you had to stop doing as you've become more senior? And what happens to your leadership when you're under real pressure?

Those questions tell me something a career history can't. They start to reveal whether someone's leadership has genuinely expanded with the complexity of the jobs they've been given. And that, increasingly, is what I think we should be trying to understand when we assess senior technology leaders — not simply how good they are, but how capable they are of continuing to change as the job changes around them.

So what should a great CTO aspire to become?

Not the person with all the answers, and certainly not the executive who has moved so far from technology that they can no longer interrogate an important technical decision.

Something harder sits between the two. Be technically curious enough to keep learning when the technology moves beyond the expertise you built your career on. Be secure enough to hire people better than you, and give them enough room to prove it. Develop the judgement to know when to challenge, when to listen, when to go deeper and when to get out of the way. Learn to see the same decision through the eyes of an engineer, a customer, a CFO, a CEO and a board without losing the perspective that makes you a technologist. And when the environment changes, be willing to change with it.

Because that's ultimately the transition. You don't need to become less of a technologist to become a better technology executive. You need to become much more deliberate about how, when and where you use the expertise that got you there.