A new CTO's first instinct is usually to ship something. Announce a re-platform, kill a legacy service, reorganize the teams by Friday. Resist it. The most expensive mistakes I've watched leaders make in their first quarter came from acting before they understood what they were looking at — treating symptoms they hadn't traced to a cause.
Your first 90 days are not for building. They're for diagnosis. The org already has a working theory of its own problems; your job is to find out whether that theory is true.
Weeks 1–3: Listen before you touch anything
Start with people, not dashboards. Book 30-minute one-on-ones with every engineer, plus the product managers, the two loudest people in support, and whoever answers the pager at 3 a.m. Ask the same handful of questions and watch where the answers stop lining up.
My standard set:
- "Walk me through what happens when you ship a one-line change." The gap between the confident version and the real version is where your delivery pain lives.
- "What did you try to fix last year that didn't stick?" This surfaces the political landmines and the graveyard of half-finished migrations.
- "If you had one week to fix one thing, what would it be?" When five people name the same thing unprompted, you've found your first real signal.
Write down what you hear verbatim. You are collecting evidence, not forming conclusions — and you will be tempted to conclude far too early.
Weeks 3–6: Read the system, not the org chart
People tell you what they believe; the system tells you what's true. Pull the data that doesn't lie and let it argue with the interviews.
The four numbers I always pull first
- Deployment frequency and lead time. How long from merged PR to production? If it's measured in days, you have a flow problem, not a talent problem.
- Change failure rate. What share of deploys cause an incident or rollback? Above roughly 15% and your team is running scared, which quietly slows everything else.
- Time to restore. When it breaks, how fast is it green again? This exposes the health of your observability and on-call more honestly than any survey.
- Where the engineering hours actually go. Feature work versus unplanned work versus toil. If more than a third is unplanned, you're funding a fire brigade, not a product team.
Then read the codebase and the incident history yourself. Not to judge — to calibrate. Skim the last 20 postmortems and you'll see the same three root causes wearing different costumes.
An engineering org's real architecture is not in the diagrams. It's in the pull requests that sit for four days and the one service everyone is afraid to touch.
Weeks 6–10: Separate the disease from the symptom
By now you'll have a pile of complaints. The discipline is refusing to fix any of them until you've sorted them into three buckets.
- Technical: the flaky pipeline, the untested legacy monolith, the missing staging environment.
- Process: code review that takes days, planning that changes weekly, no clear definition of done.
- People and org: a team owning three unrelated domains, a staff engineer quietly doing the work of four, unclear decision rights.
Most "technical" complaints are process complaints in disguise. Slow deploys are rarely a tooling gap alone — they're usually a review culture, an ownership vacuum, or a fear of production that no amount of CI will cure. Trace each symptom down one more level before you name it.
Weeks 10–13: Commit to a diagnosis, then a first cut
Around day 75, write the memo. One page. Here is what I found, here is what's actually causing the pain, here is the sequence in which we'll fix it, and here is what we are deliberately choosing not to touch yet. That last part earns more trust than any roadmap — it tells the org you can prioritize.
Pick one visible, winnable fix for the first 30 days after diagnosis. Not the biggest problem — the one that proves the diagnosis is right and shows the team that friction is beatable. Cutting deploy time from two hours to fifteen minutes will buy you more credibility than a six-month platform bet, and it funds the harder work that follows.
Where to start Monday
Open your calendar and block the one-on-ones before anything else fills the space. Resist every urge to announce a strategy in week two — you don't have one yet, you have hypotheses. The CTOs who last are the ones who spent their first quarter being usefully curious instead of performatively decisive.
Ninety days from now, could you defend your top three priorities with evidence rather than instinct? If not, you're not ready to build yet — and that's exactly the right place to be.