The CTO (Chief Technology Officer) is the person in the Org Chart who is responsible for the company’s technology strategy, which in practice means: attending meetings about technology instead of doing technology, drawing architecture diagrams that nobody follows, and explaining to the CEO why the thing the CEO saw at a conference cannot be implemented in the timeline the CEO promised the board.
The CTO is the most tragic role in the boardroom. Every other C-suite executive does a refined version of what they always did — the CFO still does finance, the CEO still makes decisions, the CIO still manages IT. The CTO used to write code. The CTO loved writing code. The CTO was promoted because they were the best at writing code, and the promotion’s primary consequence was ensuring they would never write code again.
This is known as the Peter Principle, except it’s worse, because the Peter Principle describes people promoted to their level of incompetence. The CTO was promoted to their level of irrelevance — still competent, still sharp, still capable of solving the problem in an afternoon, but trapped in a calendar that has no afternoons.
The Two CTOs
Every company has a CTO. Not every company has the same one.
The CTO Who Codes. This CTO was a developer, became a tech lead, became an architect, and was eventually given the title because nobody else could explain the system to the board. This CTO still opens the IDE. This CTO still reviews pull requests. This CTO still debugs in production at midnight, not because they have to, but because midnight is the only time nobody schedules a meeting. This CTO’s architecture diagram is accurate because this CTO drew it while building the thing.
The CTO Who Codes eventually faces a choice: remain the best developer in a company that needs a strategist, or become a strategist in a company that needs them to stop touching the code. Most choose neither, attempting both, and becoming the bottleneck they spent their career eliminating. Brooks’s Law applies to CTOs too — adding the CTO to the development team makes the team slower, because every decision now routes through someone with a calendar conflict.
The CTO Who Decks. This CTO came through management consulting, enterprise sales, or a series of VP roles at companies large enough to have VP roles. This CTO has never committed code to a repository that was not a demo. This CTO’s architecture opinions come from Gartner, conference keynotes, and vendor lunches. This CTO’s primary deliverable is a “Technology Strategy” slide deck that is updated quarterly and implemented never.
The CTO Who Decks is not incompetent. The CTO Who Decks is excellent at vendor management, budget negotiation, board communication, and the political navigation required to keep a technology department funded in an organisation that views technology as a cost center. These are valuable skills. They are just not the skills that the title “Chief Technology Officer” implies.
The codebase does not know which CTO is in charge. The codebase knows which CTO’s architecture diagram matches reality. The answer is almost always: neither. The architecture is whatever the senior developer built while both CTOs were in meetings.
The Monolith Confession
The CTO’s most revealing moment is the Monolith Confession — the private, usually after-hours admission that the monolith was fine.
“I can’t go to the board and say we’re going back to the monolith.”
— CTO, Interlude — The Blazer Years
The monolith was at 3% CPU. It served twelve hundred users. It responded in 47 milliseconds. Then the CTO attended a conference, saw a keynote about Microservices, and launched a migration that produced forty-seven services, a 2.3-second response time, and a £47,000/month cloud bill.
The CTO knows the monolith was better. The CTO cannot say the monolith was better, because saying the monolith was better means admitting the migration was wrong, and admitting the migration was wrong means admitting the Transformation Initiative was wrong, and admitting the transformation was wrong means admitting that the CTO’s primary strategic contribution over the past two years was a net negative.
The CTO cannot say this to the board. The CTO says this to The Consultant, at 11 PM, in a hotel bar, after the third drink. The Consultant says: “Call it something else.” The CTO calls it “Platform Consolidation.” The monolith returns. The board is satisfied. Nobody uses the word “monolith.”
The CTO-CIO Boundary
Every company with both a CTO and a CIO has an ongoing, low-grade territorial conflict about where one role ends and the other begins.
The theoretical distinction: the CIO manages internal technology (IT, infrastructure, enterprise systems), while the CTO manages external-facing technology (the product, the platform, the thing that makes money). In practice, this distinction is as clear as a dotted line on an Org Chart, and just as useful.
The CIO buys SAP. The CTO deploys to AWS. The CIO manages the internal network. The CTO manages the production infrastructure. The CIO’s team uses JIRA. The CTO’s team also uses JIRA but a different instance, because Conway’s Law demanded it. Both report to the CEO. Neither is sure which of them should own the data platform.
The data platform is the Alsace-Lorraine of the C-suite: a strategically valuable territory claimed by both sides, fought over periodically, and administered poorly by whoever currently holds it.
The Technology Radar
The CTO’s equivalent of the CEO’s conference problem is the Technology Radar — a periodic assessment of which technologies the company should adopt, trial, assess, or hold.
The Squirrel loves the Technology Radar. The Technology Radar is a formalised permission structure for proposing new technologies, and the Squirrel will fill every quadrant with proposals: Kubernetes (adopt), GraphQL (trial), whatever was on Hacker News this morning (assess), and the working monolith (hold, which in Radar vocabulary means “stop using this,” which in practice means “ignore because it’s the only thing running in production”).
The Lizard’s Technology Radar has one quadrant. The quadrant contains Go, SQLite, and scp. Everything else is “hold.” Everything has always been “hold.”
Measured Characteristics
- Average CTO tenure: 4.5 years
- Time spent coding: 0-5% (inverse to company size)
- Time spent in meetings about code: 40-60%
- Time spent wishing they were coding: the remainder
- Architecture diagrams that match reality: ~0
- Architecture decisions actually made by: the senior developer
- Monoliths secretly missed: most of them
- Monoliths publicly acknowledged as missed: 0
- Conference keynotes that launched a migration: at least 1 per CTO
- Technology Radars produced: quarterly
- Technology Radar items implemented: the ones the senior developer already chose
- Midnight debugging sessions: the CTO’s happiest hours
- CTOs who would go back to coding if the salary matched: all of them
- CTOs who admit this: at hotel bars, after the third drink
