The Day My Title Made Me Worse at My Job
Six years into my role as CTO, I had a revelation that changed everything. I was sitting in my fourth meeting of the day — a "strategic alignment sync" — when a junior developer pinged me on Slack: "Hey, the payment gateway integration is failing silently in production. Can you take a look?"
I stared at the message. Six months ago, I would have opened the codebase, traced the issue, and had a fix deployed within the hour. Instead, I forwarded it to the team lead and went back to my slide deck about "Q3 engineering velocity metrics."
That was the moment I realized: my CTO title was making me a worse technologist.
And I am far from alone. Across the startup ecosystem, I see the same pattern — brilliant engineers get promoted to CTO and slowly drift away from the very thing that made them valuable in the first place.
The Two CTO Archetypes: Manager vs. Builder
In my 13+ years building technology, I have worked with dozens of CTOs. They almost always fall into one of two camps:
The Manager CTO
This CTO lives in meetings. Their calendar is a wall of colored blocks — standups, retros, one-on-ones, stakeholder updates, roadmap reviews. They speak fluently about "engineering culture" and "developer experience," but they have not merged a pull request in months. Maybe years.
Their technical decisions are based on what the team recommends, not on first-hand understanding. They optimize for process — Agile ceremonies, sprint velocity, Jira boards with perfect swimlanes.
The Builder CTO
This CTO still ships code. Not all day — they are not trying to be a senior engineer. But they review pull requests with real feedback, not rubber stamps. They prototype critical features. They can debug a production issue at 2 AM because they understand the system, not because they read the architecture doc.
They optimize for product — making the right technical bets, catching architectural mistakes before they become expensive — embodying the CTO mindset every startup needs, and keeping the team honest about what is actually hard versus what is just unfamiliar.
Why Manager CTOs Fail at Startups
Let me be blunt: the Manager CTO archetype works at companies with 500+ engineers. At a startup? It is a disaster.
Here is why:
1. They Cannot Evaluate Technical Risk
When your CTO has not written code in two years, they cannot smell a bad architecture decision. They rely on their team's judgment — which is fine, until the team is wrong. And at a startup, one bad architectural bet can cost you six months and your entire runway.
I have seen this firsthand. A startup I consulted for had a CTO who approved a microservices architecture for a team of four developers. Four. They spent eight months building infrastructure instead of features. They ran out of money before they had a working product.
2. They Lose the Team's Respect
Developers are a skeptical bunch. We can tell when someone is faking technical depth. When your CTO cannot meaningfully contribute to a code review, the engineering team notices. Trust erodes. The best engineers leave for companies where leadership actually understands what they do.
3. They Make Expensive Hiring Mistakes
A non-coding CTO cannot properly evaluate technical candidates (see my guide on what nobody tells you about hiring your first developer). They end up relying on LeetCode scores and system design whiteboard exercises — which test interview skills, not engineering ability. I have watched companies hire "senior architects" who could not write a working API endpoint.
The 60/40 Rule for Early-Stage CTOs
After scaling teams from 3 to 60+ developers, here is the ratio I recommend for startup CTOs:
60% building. 40% leading.
That 60% is not just writing code. It includes:
- Reviewing every critical pull request — not as a bottleneck, but as a quality gate
- Prototyping high-risk features — proving the approach before the team invests weeks
- Debugging production issues — staying sharp on the actual system
- Writing technical documentation — because the CTO should be the best communicator of technical decisions
The 40% leading covers the essential management work: hiring, mentoring, roadmap planning, stakeholder communication. But it never crowds out the building.
As your company scales past 20-30 engineers, the ratio shifts. By 50+ engineers, you might be at 30/70 or 20/80. But you should never hit 0/100. The moment a CTO stops writing code entirely is the moment they start making decisions based on memory instead of reality.
What Happens When Your CTO Cannot Read a Pull Request
Let me paint a picture of what goes wrong:
Monday: The team proposes rewriting the authentication system. The Manager CTO asks, "What is the timeline?" The Builder CTO asks, "Why is the current system failing? Show me the specific pain points in the code."
Wednesday: A production bug takes down the checkout flow. The Manager CTO asks, "What is the ETA for the fix?" The Builder CTO opens the logs, identifies the race condition, and pairs with the engineer to fix it.
Friday: A vendor pitches a $50K/year observability tool. The Manager CTO schedules a demo. The Builder CTO asks, "What can't we do with our current logging setup?" and saves the company $50K.
In each scenario, the Builder CTO makes faster, cheaper, better decisions — because they have context the Manager CTO simply does not have.
How to Evaluate If Your Tech Leader Is Still Sharp
Whether you are a founder evaluating your CTO or a board member assessing technical leadership, here are five signals:
- Ask them to explain the last bug they personally debugged. If they cannot remember, that is a red flag.
- Check their Git history. When was their last commit? Last code review? I am not saying they need to commit daily, but quarterly silence is concerning.
- Present a technical trade-off and ask for their opinion. A sharp CTO will have a nuanced take with real-world examples. A detached CTO will give you a textbook answer.
- Watch how the engineering team talks about them. Do they say "our CTO is brilliant" or "our CTO is nice"? Respect versus politeness tells you everything.
- Ask them to whiteboard the system architecture — from memory. A hands-on CTO can sketch the entire system, including the ugly parts. A removed CTO will draw high-level boxes.
The Fractional CTO Model: Why It Works
Not every startup can afford — or needs — a full-time CTO. This is where the fractional CTO model shines.
A fractional CTO gives you:
- Senior technical leadership without the $250K+ salary
- Hands-on architecture and code review — because they are still actively building across multiple projects — like when I cut a client's AI costs by 73% by staying hands-on in the code
- Battle-tested judgment from working with dozens of products, not just one
- Flexibility — scale up during critical phases, scale down during maintenance
I have worked as a fractional CTO for multiple startups, and the model works precisely because it forces you to stay technical. You cannot lead four different companies if you are not actively in the code. There is no hiding behind process when you have 10 hours a week instead of 50.
The Bottom Line
The best CTOs I know — the ones who build companies that last — never fully leave the code. They evolve from writing features to reviewing architecture to setting technical direction, but they always maintain the ability to sit down, open their editor, and build something.
If your CTO cannot do that, you do not have a CTO. You have a technical project manager with an inflated title.
And in a world where technology is the product, that distinction is the difference between winning and running out of money.
Need a CTO who still writes code? I offer fractional CTO services for startups that need senior technical leadership without the full-time overhead. Let's talk about your project.