Summary

After twenty years as a CTO, the most useful thing I learned is that the engineering, the part I was best at, was the easy part. Deep technical skill is real and rare, but for a natural technologist it is also the most predictable and masterable part of the job. The hard part, the part that decides whether the engineering matters at all, is leadership. Being good at the measurable thing fooled me into assuming I was a good leader. I was not, and it quietly capped projects that deserved better. You do not need to choose between the two. You need a Goldilocks balance of both, and for most deep technologists the blind side is the human one.

After twenty years as a CTO, the most uncomfortable thing I learned is this: the engineering, the part I was best at, was the easy part.

That is not false modesty. Deep technical skill is real, valuable, and rarer than most people think. But for someone wired the way I am, it was also the most predictable, masterable part of the job. Systems behave according to rules. Get good enough and you can design them well, reliably, again and again. The hard part, the part that actually decided whether any of that engineering mattered, was everything else: people, and above all leadership. It took me far too long, and several failures of my own making, to understand that.

The trap of being good at the measurable thing

Here is the trap, and naturally talented people are the most exposed to it. When you build something genuinely excellent, a robust system that serious organisations depend on, it feels like proof. Proof that you are good, that your judgement is sound, that you must therefore be a good leader too. I had that proof in abundance. I built systems used at national scale by governments and billion-dollar operations across more than thirty countries. So I assumed the leadership would take care of itself.

It did not. The very thing that made me a strong engineer, the comfort with systems that behave predictably, made me blind to the one domain that does not behave predictably at all: people. I was, for a long time, a poor leader. Not a cruel one, if anything the opposite, too far toward the compassionate and conflict-avoiding end. But poor all the same, and unaware of it, which is the worst kind.

The reckoning

The evidence was there for years before I read it honestly. Projects with real stakes, serious funding, and years of effort behind them, technically sound, that quietly failed to become what they should have. For a long time I looked everywhere except the obvious place. When I finally did, the common factor in the disappointments was not the technology. It was me. The engineering was excellent. The leadership around it was not, and that is what capped the outcome.

That is a hard thing to write on a website where people come to assess my judgement. I am writing it anyway, because the realisation was the most valuable one of my career, and because the founders I now work with are often standing exactly where I stood: certain that if the build is good enough, the rest will follow.

Necessary, but never sufficient

What I understand now is that building technology has an order to it, and the engineering sits at the bottom of it, not the top. The business reason has to be right, then the requirements, then the build. A flawless build on a weak foundation is still a failure, just a well-engineered one. Engineering is necessary. It is the price of entry, and doing it badly will sink you. But it is not sufficient, and on its own it guarantees nothing.

Leadership is what sits above it and decides whether the whole thing pays off: setting the right direction, getting people to do their best work, and making good calls under uncertainty. Without that, the most elegant system in the world is effort spent in vain.

You need a Goldilocks of both

So I did the unglamorous thing. I treated leadership as a discipline to be learned, not a talent I could assume I had, the same way I had once learned to engineer. Programmes, coaching, books, and a lot of deliberate practice, including an executive leadership programme at Oxford. It is still the work I find hardest, and the most worthwhile.

The lesson is not the tired one that soft skills beat hard skills. That is just as wrong in the other direction. You cannot lead your way out of a broken architecture, and a charismatic founder with no technical judgement is as exposed as a brilliant engineer with no people skills. What you need is a Goldilocks balance of both: enough technical depth to make sound decisions, and enough leadership to make that depth count. If you are strong on one and blind to the other, the blindness is what gets you. For most deep technologists, including the one I was, the blind side is the human one. And in the end, that is the side that decides.


If you are technical and quietly certain that the engineering is the hard part, I would gently suggest checking your blind side. And if you are a founder trying to work out whether you have the right balance around your technology, that is one of the most useful things an outside pair of eyes can tell you. Let's talk.

Related: Does your business need a CTO? · How big tech wins the talent war, and it isn't the money · The most important skill in business and life

Frequently asked questions

Is technical skill or leadership more important for a CTO?
Both, in balance. Technical skill is necessary and, for many, the easier part to master because systems behave predictably. Leadership is the harder, decisive part: without it, even excellent engineering fails to pay off. In the end leadership matters more, but neither is sufficient on its own.
Why do great engineers often make poor leaders?
Because being good at building robust systems feels like proof of broader competence, including leadership. That confidence is a trap: the comfort with predictable systems is exactly what can leave a technologist blind to people, who behave nothing like systems.
What order determines whether a tech project succeeds?
The business reason first, then the requirements, then the engineering. A flawless build on a weak foundation is still a failure. Engineering is the price of entry, not the thing that guarantees success.
Can leadership be learned?
Yes, as a discipline, the same way engineering is learned: through programmes, coaching, practice, and feedback. Assuming leadership is an innate talent you already have is one of the most common and costly mistakes talented people make.
What should a non-technical founder take from this?
That the build is not the hard part. The leadership, direction, and judgement around it are what decide outcomes. Do not over-index on finding brilliant engineers and under-invest in the leadership that makes them count.
Stay ahead

AI & tech are moving fast.
Get the signal, not the noise

Ready to make AI actually work?

Tell me what you're working on. I'll respond personally. If there's a fit, we'll take it from there.

Accepting one new client · second slot opens Q3 2026