A new CTO's first 90 days: why subtraction beats a week one roadmap. Delete inherited complexity, freeze the critical system, and rebuild team trust.
The day I got the CTO title at Shpper, I opened a fresh doc and titled it "Q1 Technical Roadmap." Ninety days later that doc had six words in it and a git branch called delete-the-nightly-sync. My first quarter as a CTO was not about building anything. It was about turning things off, one at a time, and watching who screamed.
I'm writing this because CTO advice online is almost entirely about addition. Build a vision. Build a platform team. Build a culture deck. Nobody warns you that the highest-leverage move in your opening quarter is subtraction: killing inherited complexity, unplugging services nobody can explain, and deleting abstractions written for a future that never showed up. A new CTO who ships a grand plan in week one is usually just stacking their own technical debt on top of everyone else's and calling it leadership. This post is the field guide I wish someone had handed me: a first-90-days plan for a new engineering leader built on deletion, listening, and reversible decisions instead of a roadmap you'll have to walk back by month two.
The pressure is real. You're new, you feel like you have to justify the title, and the founder is waiting for something visionary in the first all-hands. So you're tempted to walk in with a twelve-month plan and a loud opinion about rewriting the thing everyone already complains about.
Here's the problem: in week one you know almost nothing that's actually true. You know the org chart, you've skimmed the pitch deck, and you've heard three people's opinions about what's broken. That is not a foundation for a technical strategy. It's a foundation for confidently doing the wrong thing at high speed.
A roadmap shipped in week one has three predictable failure modes:
Your first quarter is a research budget, not a delivery budget. Spend it accordingly, and stop apologizing for not shipping a plan you'd have to unship in month two. The engineers who've been there two years already know where the bodies are buried. Your job in quarter one is to earn the map, not to draw a new one over territory you haven't walked.
The last team left you a codebase, and a codebase is a fossil record. Every weird workaround is a decision someone made under pressure, usually for a reason that made sense at the time and is now invisible. Your job in the first few weeks is archaeology, not renovation. You are there to understand the layers, not to bulldoze them because they look ugly from the surface.
I read inherited code the way I'd read a stranger's diary: looking for what they were afraid of. Retry loops tell you what used to fail. Feature flags that were never cleaned up tell you about a launch that went sideways. A service with three different date-formatting helpers tells you three people worked on it and none of them talked to each other. Commented-out blocks with a name and a date next to them are load-bearing anxiety — someone wasn't sure it was safe to remove, and neither are you yet.
A few concrete things I do in the archaeology phase:
Here's the kind of thing I run on day two, not day sixty:
# Files nobody has touched in over a year, ranked by size —# a rough map of "load-bearing but forgotten"git ls-files | while IFS= read -r f; do last=$(git log -1 --format=%ci -- "$f" 2>/dev/null) if [ -n "$last" ]; then printf '%s\t%s\t%s\n' "$last" "$(wc -l < "$f")" "$f" fidone | awk -F'\t' '$2 > 200' | sort | head -40
Cheap, boring, and it points at where the bodies are buried faster than any onboarding doc. The oldest files that are also the biggest are exactly the ones you want to understand before anyone touches them.
I pair that with a churn map — the opposite signal. Files that change constantly are where the pain lives now:
# Most-churned files over the last year — where the team keeps# paying the same tax over and overgit log --since='1 year ago' --name-only --format='' \ | grep -v '^$' | sort | uniq -c | sort -rn | head -30
Overlap the two lists. A file that is both old and rarely touched is a fossil to leave alone. A file that is churned constantly is a wound the team keeps reopening — that's where your eventual "next real problem" usually lives. You now have two ends of the codebase mapped without having written a single line or shipped a single opinion.
Once I can actually read the system, I start a single document. Not a roadmap — an inventory. Every service, cron job, third-party integration, feature flag, and background worker goes in a table with one of three verdicts:
| Verdict | Meaning | Default action |
|---|---|---|
| Delete | No clear owner, no clear value, or duplicated elsewhere | Turn it off reversibly and wait for someone to scream |
| Defer | Real but not urgent; costs more to fix now than to tolerate | Write it down, set no deadline, move on |
| Defend | Load-bearing, works, understood | Freeze it. Do not touch. Protect it from eager engineers |
The default verdict for anything I don't understand is not "study it more." It's delete, carefully. The safest way to learn what a service actually does is to turn it off in a controlled way and see who notices. On a recent pass I found a nightly job syncing data into a dashboard nobody had opened in eight months — I checked the access logs to be sure before I killed it. We turned it off. Nobody screamed. That's one fewer thing that can page me at 4am, one fewer integration to keep alive on the next dependency bump, and a few dollars a month back on the bill. Subtraction compounds quietly.
The "defer" column is the most important and the most underused. New engineering leaders feel like deferring is dodging. It isn't. Most technical problems are cheaper to tolerate than to fix, and a written "we know, not now" is a legitimate engineering decision. The trick is writing it down so it's a choice on the record — a lightweight architecture decision record, even a single line — not an accident you'll rediscover during an outage.
Before I delete something, I ask three questions:
If I can make a removal reversible and observable, deletion is almost free. The mistake new leaders make is treating every removal as permanent surgery, so they never do it. Most of the time it's flipping a switch, leaving a note, and watching the graphs for seven days. If something breaks, you flip it back and you've learned exactly what that service was for — which is more than the doc would have told you. This is the same instinct behind a good deploy strategy: small, reversible, observable changes beat big irreversible ones every time.
This one surprised me most, because it's the least "technical" thing on the list. In my first month I spent more time on customer calls and support tickets than in the codebase. A CTO who architects before understanding the customer is tuning a machine without knowing what it's supposed to produce.
A client once asked us for a feature that would have required a serious backend rework — new tables, a queue, the works. I nearly greenlit the design. Then I sat in on two support calls and realized the customers weren't asking for that feature at all. They were working around a small bug that made the existing flow confusing, and they'd invented a whole imaginary feature to describe the fix they wanted. We patched the bug in an afternoon. The "necessary" rework evaporated, along with the two weeks I'd have spent building the wrong thing well.
That's the pattern: customers describe solutions, not problems. Your job is to translate backwards from the feature they asked for to the friction they actually hit. What I'm listening for on those calls:
The architecture serves the product. The product serves the customer. Invert that order in your first quarter and you'll build something elegant that solves a problem nobody actually has. Every hour on a support call in month one saved me a week of misdirected engineering in month three.
Every company has one system that quietly holds the business together. Payments, auth, the core data model — whatever it is, it's the thing where a bug means real money gone or real trust gone. That system gets exactly one verdict from me in the first quarter: defend. I freeze it. No refactors, no "while we're in here" improvements, no clever migrations. Not because it's perfect — it usually isn't — but because I don't yet understand it well enough to change it safely, and the downside is catastrophic.
Everything else is fair game for questions, and the questions are boring on purpose:
Ten systems questioned, one system frozen. That ratio keeps you clear of the two classic new-CTO disasters: freezing everything out of fear and shipping nothing, or touching the one thing that takes the company down in your first month. The freeze isn't permanent. It's a promise to yourself and the founder that the scariest system will be the last thing I change, not the first, and only after I've earned the right to understand it end to end — read its tests, traced its edge cases, watched it under load.
Here's the part the technical framing misses entirely. When you inherit a team, you also inherit whatever happened to the last person in your chair. If the previous CTO left badly — pushed out, burned out, or just gone one Monday — the team is watching you to figure out which kind of leader you are before they'll tell you anything real.
You cannot delete complexity out of a codebase if the people who know where it's buried don't trust you enough to point. Subtraction is a team sport. The map lives in their heads, not in the repo. Your git blame gets you the what; only the engineer who wrote it gets you the why.
What actually built trust, in rough order of impact:
The team that watched the last CTO leave isn't cynical. They're calibrated. They've learned what a leader's first month predicts about the next year, and they're reading you closely whether you notice or not. Give them a real reason to talk, and they'll hand you the entire map — the parts that aren't written down anywhere.
Velocity is a trap in your first quarter. Measuring story points on day 30 rewards motion, and motion is exactly what a new CTO should be suspicious of in themselves. So I tracked something else at each checkpoint — leading indicators of understanding and trust, not output.
Day 30 — Understanding.
Day 60 — Subtraction.
Day 90 — Trust and clarity.
None of these are velocity. All of them predict velocity later. You go fast in year two by going carefully in quarter one — the teams that skip this pay for it with a rewrite in month nine.
The output of all this is not a fifty-slide deck. It's one page. And the test of that page is simple: I can read it aloud to the team, the founder, and the most skeptical engineer in the room, and nobody argues, because every line is built from something they already told me.
The one-pager has four parts:
Notice what's missing: a grand vision. That comes later, and it comes easier, because by day 90 you've earned the context to have one that's actually true instead of one you cribbed from a conference talk. The one-pager isn't the vision. It's the cleared ground you'll build the vision on — and it's uncontroversial precisely because you spent ninety days listening instead of announcing.