What Four CTOs Taught Me About Planning, Code, and the Business

I think I’m reasonably well placed to answer this one. Over the years, I’ve worked under four CTOs.

Three of them made a real impact on me. The fourth, I didn’t learn much from — if anything, I nearly picked up some bad habits.

The three that mattered had completely different styles, but each one left me with a habit I still carry to this day.

First CTO: Richard

Richard taught me how to plan.

He wasn’t the type of technical leader who lived in the codebase. He’d come up through the Tech Lead track, but his real strength was never the technology itself: it was that he was exceptionally good at planning.

At the time, he ran both the engineering and product teams. He had one criterion for judging whether a product manager was any good that really stuck with me:

Do they have a plan?

What are you building in the next six months? What about next year? What direction is the product line moving in? A competent product manager ought to know these things cold.

Later I realised the same thing applies to engineering teams. Beyond just chasing business requirements, there are plenty of things on the technical side that have to be planned in advance: stability work, security, architecture improvements, internal tooling. If nobody plans for them, they never get done.

That’s when I picked up the habit of doing technical planning myself. After that, wherever I went, I’d always map out the engineering roadmap first, rather than waiting to be pushed around by the business.

Richard also said something to me that I still remember almost word for word:

“If a tech lead doesn’t plan technical work, where’s the team’s sense of fulfilment supposed to come from? Drowning in feature requests every day — people get worn out.”

So when I started leading teams, I deliberately carved out a fixed chunk of time every quarter for technical projects. Stability, tooling, architecture: it didn’t matter. The point was to avoid having my people spend the entire year doing nothing but feature delivery.
Most engineers, I’ve found, genuinely want to do that kind of work.

Second CTO: Alan

Alan was a different breed entirely: the classic technical CTO.

The early system architecture, a large share of the first wave of core code, was all written by him personally.

I once asked him: now that you’ve made it to the CTO seat, do you still need to write code?

He said something that has stayed with me ever since:

“The head of technology is, at the core, the chief architect. You need to know how to design, and you need to know how to code.”

He added that careers are long, and no one can guarantee they’ll stay at the same company forever. If you go out and interview one day, people will still test your architecture skills and your coding ability. They won’t lower the bar just because your title says CTO or Engineering Manager.

I’d actually fallen into that trap myself. For about two years in the middle, I shifted almost entirely into pure management and barely touched code. Later, when I was exploring opportunities, one company hiring an Engineering Manager told me very plainly that they wanted someone who could maintain a hands-on capability, not someone who had fully detached from the technology.

After that, I never stepped away from the code again. I’ve been leading teams while staying involved in core system development ever since. Over time, I’ve come to agree with Alan more and more:

Engineering managers should write code. If you don’t, it’s really hard to keep your technical instincts sharp.

Third CTO: Michael

My third CTO, Michael, who I report to right now, represents an even more complicated case. On top of running technology, he directly owns the company’s most profitable business line.

I hadn’t really seen that setup before. One of the lines he always has at hand is:

“A CTO who doesn’t understand the business is far too easy for the business side to challenge.”

Especially when you’re in meetings with heads of different business lines, if your business understanding is weak, you can find yourself on the back foot very quickly.

But the thing he says even more often is:

“I understand the business better than the business people. They can just listen to me.”

I was a little sceptical when I first heard that. But after watching him for more than three years, I can see he wasn’t wrong.

Finance, supply chain, product, brand, retail operations: team leads from all over would come to find him, one after another. They’d sit on that little chair he keeps in his office for visitors, my desk happened to be nearby, and I’d overhear their conversations all the time.

A lot of the time, those people weren’t coming to submit a request. They were coming to consult on a solution, to validate a business direction, sometimes even to make a decision together with him.

After a few years working alongside him, I no longer evaluate a requirement purely from a technical angle. I first try to stand on the business side and think it through.
For requirements that don’t make sense, I can often talk it through with the business team during the review stage, and a lot of issues get resolved without ever needing to escalate to the CTO.

So you end up with a deep conviction: the further you go in technology, the more it stops being about the technology alone. Business understanding gets heavier and heavier on the scale.

These three CTOs taught me things that point in entirely different directions.

Richard got me into the habit of planning.
Alan is the reason I still keep my hands in the code to this day.
Michael made me realise that when you go deep enough in this profession, one of the things you’re competing on is how deeply you understand the business.

I still stick with all three habits.
They continue to shape the way I manage, and the direction of my entire career.