The CTO arrives at the seat by a route that sets the trap: they were the best engineer in the building, and the promotion is a reward for exactly the behavior the new job can’t afford. Every mistake in this deep dive — following on from the hub article — is some version of not renegotiating that identity.
The early mistakes (first 90 days)
- Still writing the hard code. Taking the gnarliest ticket feels like leadership by example; it’s actually hoarding the interesting work, bottlenecking reviews on your calendar, and telling your senior engineers you don’t trust them. The org now is your output.
- Judging the stack before the context. Every inherited codebase looks wrong for the first month, because you’re seeing the trade-offs without the history. The messy service you’re itching to condemn may be load-bearing in ways the diagram doesn’t show. Ask why before declaring wrong.
- Promising dates from the old job’s instincts. As an engineer you estimated your own work; now you’re estimating an organization’s — including its meetings, dependencies, and the testing and review knots you no longer see up close. Multiply, then multiply again.
- Neglecting the CIO relationship. Data platforms, cloud spend, and AI tooling all sit on the CIO↔CTO border — the most contested turf in the C-suite. Treating internal systems as beneath you cedes decisions that will constrain your product architecture for years.
- Skipping the business fluency work. A CTO who can’t read the P&L impact of an infrastructure decision negotiates every budget from weakness. The engineering roadmap competes for capital like everything else.
The big failure modes
The great rewrite
The signature CTO trap, worth the full anatomy. The inherited codebase is embarrassing — patched, inconsistent, full of decisions nobody would make today. The seductive answer: rebuild it properly, from scratch. Here’s what the rewrite actually costs: the old system encodes a decade of fixed edge cases — every weird customer configuration, every timezone bug, every “why is this here” that turns out to be a regulator. The rewrite discards that knowledge and then rediscovers it, in production, one incident at a time. Meanwhile feature work freezes, the old system still needs patching (so you’re running two), and the market moves. Most rewrites are two years late to a destination that no longer matters.
The disciplined alternative is incremental: strangle the old system service by service, keep shipping throughout, and reserve full rewrites for the rare case where the platform genuinely cannot support the strategy. The test isn’t “is this code embarrassing?” — all working code is embarrassing. It’s “what specifically can’t it do, and is that worth two frozen years?”
Elegance over shipping
Technical debt is real and the refactor matters — but so does the competitor who shipped while you polished. New CTOs from deep technical backgrounds over-rotate toward internal quality because it’s the excellence they can see, and under-weight the customer-visible scoreboard. The mature position is a portfolio: a fixed, defended share of capacity for debt and platform work (the KPI table below makes it measurable), with the rest pointed at things customers notice. What kills companies isn’t imperfect architecture; it’s perfect architecture for a product nobody’s buying — the MVP lesson all over again, one level up.
Hiring the mirror
The new CTO hires people who interview like they would — same stack instincts, same strengths, same blind spots. The result is a brilliant team that fails identically: five system designers and nobody who loves operations, or a room of builders with no one who can talk to customers. The engineering org needs the skills the CTO doesn’t have; hiring for comfort produces a monoculture with the founder’s exact weaknesses at scale.
The invisible debt ledger
The CTO knows where the debt is; the business hears about it only as mysterious slowness — until the CTO one day demands a “quality quarter” out of nowhere, and the executive team hears a tax with no invoice. The mistake is keeping the ledger private. Strong CTOs make debt legible to non-engineers: what it costs now (velocity, incidents, onboarding time), what paying it down buys, and a standing allocation on the roadmap — the same “yes, and here’s what it costs” translation the CFO uses. Debt negotiated openly gets budget; debt asserted suddenly gets suspicion.
AI feature-washing
The board wants AI in the product; the fastest answer is bolting a chatbot onto the interface and calling it a strategy. Demo-driven AI ships fast, wows the room, and quietly embarrasses the product when customers find it confidently wrong — because the LLM was pointed at a problem that didn’t need one, or grounded in nothing. The CTO’s actual AI job is harsher: pick the few places where generative AI or agents genuinely change the customer’s outcome, build the evaluation harness before the feature, and be the person in the room willing to say “that one doesn’t need AI.” Differentiation lives in your data and your workflow, not in the model everyone can rent.
What it looks like in the wild
Netscape (1998–2000) remains the canonical great-rewrite casualty. Facing an aging codebase, the company decided to rebuild its browser from scratch — and shipped essentially nothing for about three years while Internet Explorer took the market. The rewrite (eventually Netscape 6) arrived late and rough, the browser war was already lost, and the episode became the standard cautionary tale engineers cite to this day: the code you’re ashamed of is still the code that’s shipping.
Zillow Offers (2021) is the AI-bet-without-a-harness story. Zillow scaled an algorithmic home-buying business faster than its pricing model’s error bars deserved; when the model drifted from the market, the company took a write-down north of $500M, shut the unit, and cut about a quarter of its staff. The technical lesson survives the headlines: the evaluation harness — how you’ll know the model is wrong, and how fast — has to exist before the model gets a budget.
On the other side of the ledger, Amazon’s multi-year move from monolith to services is the standard positive citation: incremental replacement, service by service, while shipping the whole time — the strangler pattern at company scale, and the disciplined alternative to the big rewrite.
How to measure a CTO: the KPIs
Engineering has the best-researched executive scorecard in the C-suite — the DORA four — plus a handful that catch what DORA misses:
| KPI | What it tells you | Healthy sign |
|---|---|---|
| Deployment frequency | Can the org ship? | Frequent, boring releases — daily/weekly, not quarterly ceremonies |
| Lead time for changes | How fast does an idea reach production? | Days, not months; trending down |
| Change failure rate | Is speed real or reckless? | Low and stable while frequency rises — the pair that matters |
| Time to restore (MTTR) | How well do we recover? | Minutes-to-hours, drilled and rehearsed, post-mortems blameless |
| Uptime / SLO attainment | Do customers feel reliability? | SLOs defined, met, and honest — not 99.9% with asterisks |
| Velocity predictability | Can the business plan around engineering? | Quarterly commitments hit within a reasonable band; slips flagged early, not discovered |
| Tech-debt allocation | Is the platform being maintained deliberately? | A visible, defended share of capacity (often ~15–25%) — not zero, not a surprise quarter |
| Engineer onboarding time | Is the codebase and culture healthy? | New hires shipping meaningful code in weeks; the truest proxy for internal quality |
The DORA pairs are the point: deployment frequency without change-failure control is chaos; stability achieved by never shipping is stagnation. And note what’s not on the list — lines of code, story points as output, hours worked. Measure those and you’ll get them, in the worst way (KPI examples covers the gaming problem).
How to use it
- “He’s proposing a ground-up rewrite in month two — classic new-CTO trap. What specifically can’t the current system do?” (the rewrite test)
- “Debt work gets 20% of every sprint, on the roadmap, where the CFO can see it.” (the visible ledger)
- “Ship frequency doubled and change failures stayed flat — that’s the pair that proves it’s real.” (DORA pairs)
- “A three-year rebuild with nothing shipping in between? That’s the Netscape story, and we know the ending.” (the rewrite test)
- “Where’s the eval harness? Zillow scaled the model before it could tell when it was wrong.” (AI with brakes)
- “Strangle it service by service, Amazon-style — replace while shipping.” (incremental over big-bang)
Related reading: The Biggest Mistakes New Executives Make · The C-Suite Explained · What Is an LLM? · MVP: Minimum Viable Product · KPI Examples That Actually Work