The question “should a CTO code?” often turns into a debate between two camps. One side says a technology leader must remain hands-on. The other says a real CTO should have moved on to strategy and people long ago.
Both answers are too simple. The CTO role changes as the company changes.
At an Early Stage, Coding May Be Part of the Job
In a small team, job boundaries are flexible. A CTO may design architecture, write critical parts of the system, review code, and hire the first engineers at the same time.
There is nothing wrong with that as long as this is genuinely the highest-value use of their time.
The problem starts when the organization grows but the CTO continues working as if there were still only five developers around them.
Becoming the Company's Most Expensive Developer Is a Bad Goal
If critical production code can regularly be written only by the CTO, the company has not created technical leadership. It has created another critical dependency.
Every hour the CTO spends on a task a strong engineer could do should be compared with what does not happen during that hour: a manager is not hired, a cross-team conflict remains unresolved, an architectural decision waits, or an important conversation with the business never happens.
The larger the company gets, the higher the opportunity cost of the CTO's personal coding time.
Stopping Regular Coding Does Not Mean Stopping Understanding Technology
There is an opposite extreme too. The CTO becomes so distant from engineering reality that technology is discussed only through presentations and budgets.
A technology leader must still be able to go deep enough: understand an architectural trade-off, ask an uncomfortable question, challenge an estimate, or notice when a team is hiding an organizational problem behind technical language.
But “I can go deep” and “I must do it myself” are very different things.
There Are Many Ways to Stay Hands-On Without Owning Production Tasks
A CTO can join design reviews, participate in incident analysis, read key technical documents, build small prototypes, discuss architecture with engineers, or occasionally inspect code to test an assumption.
This keeps contact with reality without turning the CTO into part of the daily delivery pipeline.
Signs the CTO Is Coding Too Much
Decisions wait until the CTO finishes their current task. Engineers escalate hard problems directly to them instead of solving them at the right level. Team leads get less attention than pull requests. The CTO starts bypassing normal processes because “it's faster this way.”
An especially dangerous signal is when the team assumes that the CTO will eventually come and fix any truly critical problem.
The leader's technical strength then starts making the organization weaker.
Signs the CTO Has Drifted Too Far Away
They cannot discuss key technical risks in substance. They do not understand why team estimates differ by multiples. Serious architectural constraints reach them only through escalations. Polished technical explanations are accepted too easily.
Then the opposite problem appears: the role is formally strategic, but the strategy is built on an increasingly weak understanding of reality.
A Useful Balance
I would define it this way: a CTO should be able to go deep enough into technology, but the organization should not need their personal code to function normally.
As the company grows, the CTO's main product becomes the technology organization itself: people, decisions, architectural principles, investments, and the ability to change systems without relying on individual heroics.
A CTO should stop writing production code regularly when their personal speed starts limiting the speed of the whole organization.