At some point in every engineering leader's career, someone tells them: "You should stop coding. That's not your job anymore."
It's well-intentioned advice. It usually comes from people who watched a VP of Engineering ship a feature and break the sprint by pulling the team into code review politics. The advice is right about the failure mode. It's wrong about the cure.
What "Coding" Actually Means at a Leadership Level
When I say I still code, I don't mean I'm writing 500-line PRs that block my team. I mean I maintain the ability to:
- Read any diff and understand its consequences
- Prototype a new architecture in a weekend to validate a decision
- Debug a production incident without needing four people to translate
- Judge technical tradeoffs from first principles, not just from someone else's summary
This is different from being a bottleneck. It's maintaining technical fluency — the same way a CFO who used to be an auditor still does their own taxes.
The Cost of Abstraction
When a leader loses technical fluency, they start making decisions by proxy. They ask their engineers for estimates and multiply by 1.5x. They trust architecture diagrams without questioning the load assumptions baked into them. They approve a rewrite because two senior engineers recommended it.
Sometimes this works. Often it doesn't.
The deepest technical debt I've seen in companies wasn't in the codebase — it was in leadership's understanding of the codebase. When that debt gets called in (a production incident, a failed deadline, a surprise scope expansion), the leader who can't read the code has no ground to stand on.
The Right Division of Labor
The question isn't "should the CTO code?" The question is "what's the highest-leverage use of a CTO's time?"
That answer changes constantly. In week one of a startup, the CTO probably should be writing most of the backend. In week 100, they probably shouldn't be owning any production path. But the regression to never coding is a mistake.
Some of the most valuable coding I do today:
- Greenfield prototypes: When I need to validate a product direction without committing engineering capacity
- Tooling and infrastructure: Internal tools that my team will use but aren't on anyone's roadmap
- Emergency debugging: When the on-call engineer is stuck and I can cut through faster
- Code review on critical paths: Not as a gatekeeper, but as a second set of eyes on irreversible decisions
What You Lose When You Stop
Muscle memory for debugging atrophies quickly. After six months away from a codebase, I find myself googling syntax I used to type from memory. That's fine — I can relearn it. What's harder to rebuild is the intuition for where complexity hides.
Every codebase has a shape. Senior engineers know where to look when something goes wrong. That knowledge comes from living in the code, not from reading architecture documents.
Leaders who stay technical don't just maintain their own fluency — they maintain their credibility with the engineering team. You can't bullshit engineers about complexity for long if they know you shipped a production service last quarter.
The Counter-Argument
The strongest argument against CTOs coding is opportunity cost. Every hour I spend on a PR is an hour I'm not spending on hiring, strategy, or unblocking my team.
This is a real tension. I solve it by being explicit about what kind of coding counts as leadership-leverage vs. individual-contributor work. Shipping product features is usually not the right use of my time. Maintaining the architectural context that makes all other technical decisions better — that is.
Code is how ideas become systems. A leader who can't read the code can't fully understand the systems they're responsible for. That's not a philosophical position — it's a practical one.
Stay technical. Just be intentional about what that means.
