Last Tuesday I mass-deleted a hundred lines of Python that I’d spent two days writing. Not because the code was bad. It was actually pretty elegant, if I say so myself. I deleted it because I realised I’d spent two days solving a puzzle that I should have handed to my team on Monday morning.
I love solving puzzles. That’s the problem.
The early days are different
When you’re a co-founder getting an idea off a whiteboard and into a working demo, you should be writing code. You should be writing CI pipelines. You should be debugging at 11pm with a cold coffee next to your keyboard. You should be doing devops, handling support tickets, and deploying on Fridays because there’s nobody else to do it.
That phase is real, and anyone who tells you a CTO shouldn’t be hands-on during it has never built anything from zero. In the early days, you ARE the engineering team. Your technical credibility isn’t theoretical, it’s the reason the company exists.
The problem isn’t that you write code. The problem is that you don’t notice when you should have stopped.
The 40% rule
I’ve landed on a rule for myself, arrived at through painful experience rather than any management textbook. I call it the 40% rule: no more than four half-days a week on hands-on engineering work. That’s the ceiling, not the target.
Go above 40% and the exec work starts to slip. The board deck gets written at midnight. The 1:1s get rescheduled. The hiring pipeline goes quiet because you haven’t reviewed CVs in two weeks. You tell yourself you’ll catch up, but you won’t, because tomorrow there’s another interesting bug and your brain would much rather chase that than write a quarterly update.
I’ve blown through my own 40% rule more times than I’d like to admit. Every single time, leadership has suffered. Not immediately, not dramatically, but in that slow, creeping way where you look up after three weeks and realise you haven’t spoken to half your team about anything other than pull requests.
Staying technical is not the same as doing all the technical work
Here’s where I want to plant a flag. The advice you’ll hear, “CTOs should be strategic, not tactical,” is incomplete at best and harmful at worst.
Staying technical makes you a better leader. Full stop. You can’t ask smart questions in an architecture review if you haven’t touched an architecture in three years. You can’t evaluate whether a timeline is reasonable if you’ve forgotten what “reasonable” feels like from the inside. You can’t mentor engineers if your mental model of the work is frozen in 2019.
But, and this is the bit I had to learn the hard way, staying technical doesn’t mean staying in the code all day. It means understanding enough of the task to frame it well, to ask the questions that matter, and then to let your engineers handle it. It means reading PRs, not writing all of them. It means pairing occasionally, not owning the sprint.
As you get older in this industry, you simply can’t keep up with every trend, every new framework, every paradigm shift. And that’s fine. Your job isn’t to be the best engineer on the team. Your job is to be good enough to lead the people who are.
The joy of pairing with juniors
One of the things I refuse to give up is pair-programming with junior engineers. It’s selfish, honestly, because I get as much out of it as they do.
There’s an energy that junior devs bring that you just can’t manufacture with experience. They’re enthusiastic in a way that makes me feel ancient, but in the best possible way. They suggest things I’d never consider because they haven’t learned yet that something is “supposed to be hard.” They reach for tools I’ve never heard of. They ask “why?” about things I stopped questioning years ago, and sometimes the honest answer is “actually, I don’t know, let’s find out.”
Those sessions are where I stay sharp. Not by writing production code at midnight, but by sitting next to someone (virtually, because remote) who sees the problem completely differently to how I see it.
The thing that doesn’t scale
The counter-argument I hear most is “it doesn’t scale.” And they’re right. A CTO who writes code doesn’t scale. That’s the point.
What scales is building team structures underneath you. What scales is hiring people who are better than you at the things you used to do, and then actually letting them do those things. What scales is creating the space for your engineers to have their own good ideas, bring techniques from their own experiences, choose tools you wouldn’t have chosen, and own the outcomes.
The part that doesn’t scale is you, personally, being in the codebase. And the sooner you make peace with that, the sooner your team starts to grow beyond what you could build alone.
I’ve seen CTOs who can’t let go. They review every PR, they override architectural decisions, they rewrite things their team shipped because it wasn’t how they would have done it. That’s not staying technical. That’s blocking your own team’s progress and calling it quality control.
What I actually do now
On a good week, here’s roughly how my time breaks down:
- Two mornings: deep technical work. Code reviews, architecture spikes, debugging something gnarly. Slack is closed. (Yes, I practice what I preach from my last post.)
- Two mornings: leadership work. 1:1s, hiring, board prep, strategy.
- Afternoons: the messy middle. Meetings that could be documents, documents that should be meetings, and the occasional fire.
On a bad week, the technical mornings eat the leadership mornings, and then I’m writing the board deck on Sunday. I’m getting better at noticing when this is happening. I’m not great at it yet.
The uncomfortable bit
I don’t think there’s a clean transition from “CTO who codes” to “CTO who leads.” It’s not a switch you flip. It’s a gradient, and where you sit on it changes with the company’s stage, the team’s size, and honestly, how you’re feeling on any given Tuesday.
What I do think is that the instinct to stay in the code comes from a good place. It comes from caring about the craft, from wanting to understand what your team is dealing with, from the genuine pleasure of making something work. Those instincts make you a better leader, not a worse one.
The trick is channelling them into the right activities at the right time. Pair with a junior instead of rewriting their PR. Read the code instead of writing it. Ask the question instead of answering it yourself.
And when you catch yourself two days deep in a puzzle you should have delegated on Monday morning, have the good sense to hit delete and send a Slack message that starts with “hey, I’ve got an interesting one for you.”