You've just accepted the CTO role. The job is real. The pressure is real. Here's what actually matters in the first 90 days.

The temptation, when you step into a CTO or VP Engineering role, is to move fast. Reorganize. Fix the most obvious problems. Hire your people. Ship the thing that's been delayed for six months.

Resist this temptation.

The companies I've seen succeed in this transition follow a three-phase pattern. Not by accident. By design. Each phase has a clear objective. Miss one, and the next becomes exponentially harder.

Phase 1: Days 0–30 — Understand & Stabilise

Your job in month one is to become an expert on the organisation without changing anything.

This feels wrong. It feels slow. Do it anyway.

Daily standup observations (Days 1–5)

Attend daily standups in every engineering team. Don't run them. Observe. Listen for:

  • What blocks are recurring? (They're not emergencies — they're architecture problems.)
  • How does the team decide what to build? (Is it clear? Is it working?)
  • What does the VP Eng care about? (Velocity? Quality? Headcount? You need to know.)
  • Who are the opinion leaders? (Not necessarily managers — often senior engineers.)

1-on-1s with every engineering leader (Days 5–20)

Meet privately with:

  • VP Engineering / Head of Engineering (if different from you)
  • Every team lead
  • Architects and principal engineers
  • Hiring managers

Ask the same three questions in each meeting:

  1. "What's working really well right now? What should I understand about your team before anything else?"
  2. "What's the biggest bottleneck you're hitting? What would you fix if you had complete freedom?"
  3. "What do you think the CTO role should focus on in the first 90 days?"

Do not offer solutions. Do not commit to anything. Listen and take notes. You'll see patterns emerge.

Code review sessions (Days 10–25)

Sit in on 2–3 code review sessions. Watch what engineers debate. What standards matter to them? What's non-negotiable? What's cargo cult?

This tells you far more about the technical culture than any document.

Cross-functional listening (Days 15–30)

Meet with Product, Finance, GTM, and Ops:

  • Product: "What features are blocked by technical constraints?"
  • Finance: "What's our unit economics? How does engineering impact it?"
  • GTM: "What are customers asking for that we can't deliver?"
  • Ops: "What infrastructure or reliability issues keep you up at night?"

Establish visibility (Days 20–30)

You need basic dashboards by end of Week 4. Not fancy. Accurate.

  • Deployment frequency (how often does the main branch ship to production?)
  • Lead time for changes (from commit to production)
  • Incident response time (time to detect, time to resolve)
  • Platform health (uptime, error rates, latency percentiles)
  • Key business metrics (ARR, churn, MRR, active users)

These aren't for public reporting. They're for you. You need baseline data before you can diagnose anything.

The principle: By Day 30, you should be able to articulate the state of the organisation in your own words. Not from documents. From people. From observation.

Phase 2: Days 31–60 — Design & Align

Now you diagnose. Now you design. Now you align.

Write your technical state assessment (Days 31–40)

This is a 5–10 page document shared with the CEO and VP Eng (if they're different people). It answers:

  • What's the current state of the architecture? (What works? What's fragile?)
  • What are the three biggest technical risks to the business in the next 12 months?
  • What's the quality of the delivery system? (Can you ship weekly? Why or why not?)
  • What's the state of the team? (Are people happy? Are you losing high performers? Why?)
  • What do you recommend? (3–5 concrete initiatives, not vague goals.)

This document does three things: it proves you've listened, it creates a shared understanding with leadership, and it signals that you're moving from observation to action.

Identify the three highest-impact technical decisions (Days 35–45)

Not ten. Not a roadmap. Three decisions that, if made well, cascade across the organisation.

Examples:

  • "Do we refactor the monolith or build new services alongside it?"
  • "Do we invest in ML infrastructure now or wait six months?"
  • "Do we move from Postgres to a distributed database?"
  • "Do we hire for AI capability or outsource to agencies?"

These decisions define the next 12 months. Get them right, and everything else follows. Get them wrong, and you'll be fixing them for the next two years.

Clarify role boundaries with VP Eng (Days 40–50)

If you have a VP Eng, this conversation is critical. And it's uncomfortable. Do it anyway.

Agree on:

  • Who owns hiring for technical roles? (Usually shared, but who decides?)
  • Who owns the delivery roadmap? (Your vision, their execution? Or shared?)
  • Who talks to the board about technical progress? (Both, but who leads?)
  • Who decides architecture? (You set the framework, they implement?)
  • What's the escalation path when you disagree? (It will happen.)

Write it down. Review it with the CEO. This prevents six months of resentment.

Define a predictable delivery model (Days 45–60)

The team needs to understand how decisions get made. How priorities are set. How work gets done. How risks are escalated.

This is not policy. This is rhythm.

  • Weekly: Team standups, architecture review (if needed), demo of shipped work
  • Bi-weekly: One cross-team sync to align on dependencies
  • Monthly: Leadership review with CEO / board (what shipped, what's at risk, what changed)
  • Quarterly: Roadmap reset, hiring plan, technical investment review

Consistency matters more than perfection. The team will rely on this rhythm.

Phase 3: Days 61–90 — Execute & Scale

Now you ship. Now you prove it works.

Land one architecture recommendation (Days 61–75)

Pick the decision that delivers the most immediate value. Not the most elegant. Not the most interesting to you. The most impactful.

Examples of Day 61-75 wins:

  • "Migrate search to Elasticsearch and cut response time from 2s to 200ms" → Product becomes faster overnight
  • "Standardise API responses and cut mobile app build time in half" → Teams move faster
  • "Build a data governance framework" → Finance can report to the board more confidently

This recommendation should land in the next sprint. Should ship by Day 75–80. Should be visible to the whole company.

Unblock a hiring bottleneck (Days 70–80)

By now, you know what the team needs. Bring someone in. Someone you know. Someone who can start fast.

This sends a signal: the CTO is enabling the team, not constraining it.

Address one piece of technical debt (Days 75–85)

Not the biggest. Not the most urgent. The one that's been haunting a specific team.

Example: "The payment processing service has been brittle for six months. Let's rebuild it properly."

This proves you listen and you prioritize what matters to the team, not just what matters to you.

Present the 12-month technical roadmap (Days 85–90)

This is not a detailed project plan. It's a narrative. It tells the story of where you're taking the organisation technically.

Show it to the board. Show it to the company. Explain:

  • Why this direction? (What changes if you execute?)
  • What's the sequence? (What blocks what?)
  • What's the risk? (What could go wrong?)
  • What do we need? (Hiring, tools, infrastructure investment?)

This is your social contract with the organization: "This is what I'm here to do. This is what it requires. This is how we'll know if I'm succeeding."

Mistakes Most New CTOs Make

Mistake 1: Reorganising before understanding

You arrive on Monday. By Wednesday you've renamed five teams and moved people around. This is wrong. You don't yet know what's working and what isn't. The team is now confused and resentful. Don't do this.

Mistake 2: Announcing the "fix" too early

You find a major architectural problem on Day 7. You announce a complete rewrite on Day 10. The team panics. Trust erodes. The rewrite takes three times longer than expected. Don't announce solutions before you've built consensus.

Mistake 3: Trying to fix everything at once

Delivery is slow, architecture is fragile, hiring is broken, and the cloud bill is out of control. You can't fix all four simultaneously. Pick one. Own it. Ship it. Then move to the next.

Mistake 4: Not building relationships with non-technical leaders

You're a technologist. You're comfortable with engineers. But if you don't understand what Product needs, what Finance cares about, and what GTM is struggling with, you'll optimise for the wrong problems. Meet them early. Listen to them.

Mistake 5: Leaving decisions hanging

You gather input for the first month. Then you disappear to write a document. The team doesn't hear from you. Uncertainty grows. Anxiety grows. Set a rhythm: "I'll have recommendations by Day 40. We'll align by Day 50." Then stick to it.

How to Know You're on Track

By Day 30:

  • You've had one-on-ones with every engineering leader
  • You can name the top three technical risks facing the company
  • The team sees you in standups, code reviews, and social spaces
  • You understand the company's unit economics and how engineering impacts them

By Day 60:

  • You've published a technical state assessment
  • You've clarified role boundaries (if there's a VP Eng)
  • Leadership understands your three-priority focus for the next 12 months
  • You've held the first cross-functional leadership sync

By Day 90:

  • You've shipped one meaningful architectural change
  • You've enabled one hire that the team wanted
  • You've addressed one piece of technical debt that was blocking the team
  • The company knows where you're taking them technically — not the details, but the direction and why
  • Engineers and leaders have begun trusting you

Trust isn't built on a Day 1 all-hands. It's built on small actions repeated. It's built on listening before prescribing. It's built on shipping something that mattered to someone else, not just to you.

Building this kind of leadership credibility takes time, and I've shared these frameworks at conferences and in podcast interviews — see the Media & Impact page for talks on technical leadership.

The goal of Day 90 is not "have changed everything." It's "the team trusts you, understands your vision, and has seen you solve one real problem."

Everything else follows from that foundation.

New to a CTO role and looking for guidance on the bigger picture? I help incoming CTOs navigate their first 100 days and beyond. Schedule a consultation →

Related Articles