I became responsible for other engineers twice: once gradually, over four years as VP of Engineering at Zatiq, and once abruptly, when I took the CTO seat at Relaxy and the whole platform — team, roadmap, uptime — became my problem on a Monday. Both times I was told some version of the same advice: your job is people now, step away from the code.
I tried it. It was wrong — or at least, it was wrong for a company of that size. Below is what actually happened, including the part where my calendar collapsed, and the rules I run on now.
The week my calendar broke
Three months into the Relaxy role, I looked at a week and counted eleven hours of meetings I had accepted and four pull requests I had promised to review "by tomorrow" three days earlier. The team was blocked on me in two places. I hadn't written a line of code in nineteen days, and — this is the part that matters — my technical opinions were getting worse. I was arguing about an API design from memory of a codebase that had moved on without me.
That is the real danger of leaving the codebase. Not that you stop being useful as an extra pair of hands — the team can replace your hands. It's that your judgement starts running on stale data, and judgement is the one thing they cannot replace.
A CTO who hasn't felt the codebase in a month is making decisions about a company that no longer exists.
What still deserves my keyboard
The fix was not "code more". It was being precise about which code. I keep three categories for myself and delegate essentially everything else:
- Anything irreversible. Tenancy models, event schemas, the payment ledger design. These decisions outlive every sprint, and undoing them costs quarters. At Zatiq I wrote the first multi-tenant migration myself, not because nobody else could, but because I wanted the person accountable for the decision to have felt its sharp edges.
- The first instance of a pattern. The first service, the first background job, the first platform channel. Whatever ships first gets copied twelve times, so the first one is worth a disproportionate amount of care.
- Spikes nobody has slack for. When Riri needed a retrieval prototype and every engineer was committed, the prototype was mine. Throwaway code is a fine use of a leader's time; production features on the critical path are not, because you will get pulled into a meeting mid-feature and become the blocker.
The inverse rule matters just as much: I do not take tickets with a deadline someone else depends on. The fastest way to hurt a team is to be a bottleneck with a title.
Review is the leverage point
If I get ninety minutes of technical time a day, an hour of it goes to review. Reviewing is the highest-leverage way to stay inside the codebase: you read ten times more code than you could write, you see every engineer's actual habits, and your standards propagate without a meeting.
But review only works as leadership if the comments teach instead of gatekeep. The template I hold myself to — name the issue, name the place it should live, point at prior art, offer time:
This works, but it puts a pricing rule inside the controller.
Move it to PricingService so the discount cap lives next to the
other money rules — applyPromo() is the pattern to copy.
Happy to pair for 20 minutes if that's faster.Compare that with "why is this here?", which reads as a quiz. The first version costs me sixty extra seconds and saves a round-trip; multiplied across a team and a year, it is the cheapest training programme I know.
Two cadence rules that survived both companies: reviews get answered within one working day or explicitly handed to someone, and I never merge-block on taste. Style is the linter's job. My comments are reserved for boundaries, correctness and money.
The calendar that recovered
What ended the eleven-meeting weeks was structural, not willpower. Mornings became build time — mine and the team's — and everything with a calendar invite got compressed into afternoons. It has looked like this, give or take, ever since:
The protected block is the whole trick. People will schedule over "free time" but they will respect a standing block, especially when the whole engineering team shares it. Our meeting load didn't shrink because anyone was disciplined; it shrank because the space for meetings got smaller.
What I got wrong about delegation
I used to delegate tasks and keep the decisions. That is backwards. A task with the decision stripped out of it is typing, and senior people leave jobs that turn them into typists.
What finally worked was delegating the decision and keeping only the constraint: here is the budget, here is the deadline, here is the one thing that must remain true — everything else is yours, and I will defend whatever you choose. The first time I did this properly at Zatiq, the engineer chose a design I would not have chosen. It shipped, it held, and the parts of it I'd been wrong about taught me more than the review queue had all quarter.
Staying in the codebase and letting go of decisions sound like opposites. They are the same move: both keep you close enough to reality to trust the team with it.