The First 90 Days as a CTO: A Field Guide

The first 90 days as a CTO are the ones people remember. Not because of what you built, but because of what you understood before you touched anything.

The most common mistake I see from new technology leaders is speed in the wrong direction. You walk in, you spot ten things that are obviously wrong, and you start fixing them in week two. Six weeks later the team quietly stops telling you things, because from their side it looks like a stranger showed up and started rearranging the furniture before learning where the doors are.

So here's the field guide I wish someone had handed me the first time. It borrows the bones of Michael Watkins' The First 90 Days, the book most senior transitions are quietly measured against, but it's written for the person actually walking into an engineering org. If you want the interactive version, I turned this into a First 90 Days as a CTO planner you can work through and share.

First, figure out which situation you're actually in

Before you plan anything, name the situation. Watkins calls these STARS, and the label changes everything downstream:

Startup. You're building the team, the process, and the strategy from nothing.
Turnaround. Something is on fire and everyone knows it. You have permission to move fast, and the clock is loud.
Accelerated growth. The thing works, and now it has to work at ten times the scale without falling over.
Realignment. This is the tricky one. From the outside the org looks healthy, but it's drifted, and the problems are hidden because nobody's panicking yet.
Sustaining success. You inherited something genuinely good, and your job is to not break the momentum while finding the next act.

A turnaround rewards decisive action in week one. A realignment punishes it. Get your situation wrong and even good instincts will fail you, because you'll apply the right playbook to the wrong game.

Days 1–30: learn, and earn the right to be listened to

Resist the urge to be impressive. Your only jobs this month are to understand and to build trust.

Get your success metrics in writing from whoever you report to. Not a vibe, an actual sentence: what does "this hire worked" mean in a year? You'd be surprised how often the CEO and the new CTO have never said it out loud, and how often they disagree once they do.

Then do the listening tour. One-on-ones with every direct report, skip-levels below them, and the part technical leaders skip: time with sales, support, and finance. Sit in on a customer call. Read a week of support tickets. The gap between how the engineering team thinks the product works and how customers experience it is usually where your real work is hiding.

Ship nothing structural yet. If you must touch the code, push one trivial change end to end so you feel the real deployment process. It teaches you more about the team's actual maturity than any architecture diagram.

By day 30 you should be able to write a one-page diagnosis of the situation and a rough plan. That page is your first real deliverable.

Days 31–60: turn observations into a plan

Now the facts become a shape.

Join the on-call rotation if there is one. Nothing tells you the truth about a system faster than getting paged by it at 2 a.m. If deployments are scary, you'll find out. If the monitoring is theater, you'll find out.

Get your baselines. I lean on the delivery metrics from the DevOps research (deployment frequency, lead time, change failure rate, recovery time) because they're boring and honest. If you're new to them, I wrote a piece on reading DORA metrics without fooling yourself and built a benchmark reference you can hold your team up against. The point isn't the dashboard. It's that you now have a before-picture, so in six months you can prove you changed something real.

Start finding your quick wins: one or two, and small. Not a rewrite. A rewrite in your first sixty days is a promise you're making with money that isn't yours yet. A quick win is removing a piece of friction the team has complained about for a year that nobody senior ever prioritized. It buys you enormous credibility for the price of a week.

Look hard at hiring. Find the two or three roles that, if filled well, would unblock everything else. Shadow the interview process and be honest about whether it's actually screening for anything.

By day 60 you should have a diagnosis plus a technology roadmap the business can read. Not the team. The business.

Days 61–90: execute, but as systems, not heroics

This is where you finally get to change things, and the temptation is to change everything. Don't. Pick one or two durable improvements (a process, an org tweak, a piece of the architecture) and do them properly.

Publish your technology strategy and walk the team through it. People will forgive a hard direction. They won't forgive not knowing the direction. Set up the boring cadences now: a monthly all-hands Q&A, a weekly written update, a real operational review. Boring and predictable is a feature at the leadership level.

And put on your own oxygen mask. The CTOs who flame out in year one are almost always the ones who spent 90 days firefighting and never built the habits that let them lead instead of react. If your calendar is 100% other people's emergencies at day 90, you haven't set up the job. You've just absorbed it.

By day 90 you want three things visible to everyone above and around you: clarity about where technology is going, a roadmap people believe, and the quiet sense that someone is actually in control.

The one line to remember

Watkins' research puts a number on it: a leader who onboards deliberately reaches the point of contributing more than they consume roughly 40% faster than one who wings it. The 90 days aren't a probation period. They're the highest-leverage time you'll ever have in the role, precisely because you're still allowed to ask why.

Spend them learning. The building comes after, and it comes easier.

Stepping into a technology leadership role, or hiring someone who is? I do fractional CTO work and CTO onboarding advisory. Let's talk.