He hasn’t written production code in two years. He still reviews every pull request.
Not because the team needs it. The engineers are good. They ship clean work without him weighing in, and he knows this, he’ll say it out loud, almost proudly, in the same breath as opening the next PR to review.
A habit that outgrew its reason
This is a familiar shape for a lot of technical founders. Early on, reviewing every line of code wasn’t optional, it was the job. The founder was often the most senior engineer in the building, sometimes the only one who understood the whole system well enough to catch what mattered. That habit made sense. It was, at the time, load-bearing.
The company grew. The team got stronger. The original reason for the habit quietly stopped applying. The habit itself did not stop.
What the habit is actually doing now
Somewhere in that gap, between when the habit was necessary and now, when it isn’t, reviewing code turned into something else. Not a technical function anymore, but a way of staying inside the system that used to define him. A way of still being the person whose eyes had to touch everything before it shipped.
That’s a hard thing to notice from the inside, because it doesn’t feel like anything has changed. The behavior looks identical to what it always was. Only the reason underneath it has shifted, from necessity to something closer to reassurance.
Why this is a structural cost, not a personality quirk
It would be easy to file this under “founders who can’t delegate,” as if it’s simply a character trait to be managed or coached away. That framing misses what’s actually happening. The company genuinely doesn’t need him in that review queue anymore. The engineers can, and do, ship without him. But he needs to be in that queue, and that need is invisible to him precisely because it’s dressed up as diligence.
The cost isn’t just his time, although that’s real. It’s the quiet signal it sends to a team that’s been trusted with real ownership on paper but is still, in practice, waiting on a gate that no longer serves a technical purpose. It’s the review cycle that takes an extra day for no reason anyone can name. It’s the senior engineer who stops proposing certain changes because they know which ones will get held up, not on merit, but on habit.
The actual question
The useful question here isn’t “should the CEO review code.” It’s a narrower one: what is this specific habit still protecting him from feeling, now that it’s no longer protecting the company from anything real?
That’s not a question anyone else can answer for him. But it’s the one worth sitting with, longer than the review itself usually takes.
Myrto Zehnder partners with CEOs and founders of scaling organisations on the structural architecture underneath recurring organisational problems.
The Eagle’s Perspective — myrtozehnder.com