Fordel StudiosThe company has 25 engineers. The CTO reviews every significant PR. They write the infrastructure code themselves because "I'm the only one who understands it." They attend every engineering interview and make most of the final calls. They are in Slack at 11pm debugging a production issue because nobody else knows the system well enough to handle it without them.
The board thinks this is a sign of technical excellence. It is a sign that the team never developed the capability to operate without them. The CTO built a dependency. They called it a standard.
The Transition Most CTOs Miss
Being a great individual contributor is how most CTOs got their role. They were the best engineer. They shipped the most. They understood the system most deeply. These are legitimate qualifications for a technical leadership role. They are not the job description of the role itself.
The job description of a CTO is to make the engineering organisation capable — to build the systems, processes, and people that can execute on a technical vision without requiring the CTO's direct involvement in every decision. This is a fundamentally different skill from being a great engineer. Some great engineers develop it naturally. Many do not, because it requires deliberately reducing the scope of your individual contribution in order to multiply the contribution of everyone else. That feels like losing.
“If your engineering organisation cannot make a major architectural decision without you in the room, you have not built an organisation. You have built a dependency.”
What the Bottleneck Looks Like in Practice
PRs queue waiting for CTO review. Engineering decisions stall while the CTO is in board meetings. Junior engineers learn to ask the CTO directly rather than developing independent judgment, because the CTO's judgment always supersedes theirs anyway. The CTO is the critical path on more things than one person can be the critical path on. The team moves at the CTO's throughput. The CTO is always the constraint.
The CTO is also usually aware of this and experiences it as job security rather than as an organisational failure. "I'm still the most valuable person here" feels good. What it actually means is "I haven't built anyone else up to where they could do this."
What Good Looks Like
A CTO in a well-functioning engineering organisation spends most of their time on: the system that produces technical decisions, not the decisions themselves. The hiring process that produces capable engineers, not the individual hiring decisions. The architecture principles that guide the team, not the specific architectural choices. They are present in the highest-leverage technical decisions and absent from the medium-leverage ones. The test is: if the CTO took a two-week vacation with no access to Slack, would the engineering organisation know what to do?
If the answer is no, the CTO has not yet done the most important part of their job. The code they are still writing is the most expensive code in the organisation — not in compute cost, but in opportunity cost.