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 First 90 Days Determine Everything

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.

But before the framework: the CTO role is not a senior version of VP Engineering. They are different jobs pointing in different directions. The VP Eng faces inward — delivery cadence, team health, execution quality. The CTO faces outward — board, investors, customers, market — and the decisions that live at that boundary are yours alone: build or buy, platform strategy, technical narrative in fundraising, how risk is framed to the board.

The first 90 days are where you build both kinds of credibility simultaneously. Internal trust from the team. External trust from the board and investors. Only the CTO owns both.

Phase 1: Days 0–30 - Understand & Stabilize

Day ranges sourced directly from the framework. The overlap is intentional: standup observation (days 1–5) anchors the technical culture read; 1-on-1s (5–20) gather individual perspectives; cross-functional listening (15–30) closes the business context gap. Nothing changes in month one.

Your job in month one is to become an expert on the organization 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. Watch for the same system name appearing across multiple standups. Watch for "waiting on" answers that never resolve. The blocker that comes up three Tuesdays running is what your early Phase 3 decisions need to target.
  • How does the team decide what to build? Watch whether engineers can answer "why is this the priority?" without looking at a manager. Confident, specific answers signal good product-engineering alignment. Vague or deferred answers signal a decision process that doesn't reach the people executing it.
  • What does the VP Eng care about? Watch what they follow up on in the room — velocity metrics, incident counts, headcount numbers? What they track publicly tells you more than what they say in 1-on-1s. You need to know this early to anticipate where you'll align and where you'll need to negotiate.
  • Who are the opinion leaders? Not necessarily managers — often senior engineers. Watch for who other engineers glance at before agreeing to something, whose pushback changes the room, who speaks last when a disagreement surfaces. These are the people whose trust you need first, because their buy-in cascades.

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?"

Map the board's technology view (Days 10–20)

Before you form your own view, understand theirs. Read the last three investor updates the CEO sent. What is the technology narrative being pitched to the board? What technical risks are already in investors' minds? What platform promises have been made that engineering hasn't fully committed to?

Ask the CEO directly: "What does the board think is our biggest technical risk right now?" The answer will surprise you. Boards often fixate on the wrong thing — security theatre, competitor feature parity, infrastructure labels that mean nothing operationally. You need to know this early, because part of your job is to correct that framing, not just execute inside it.

This conversation is yours alone. The VP Eng does not have it. You do.

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 organization 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.

Write a one-page board summary in parallel. Not the 10-page detail — that stays internal. The board version answers one question: "Are we technically sound enough to execute the next 12 months of our strategy?" One paragraph on current state, one on the top risks, one on what you're doing about each. This is the version that builds your credibility with investors and non-executive directors who will never read the full document.

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

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

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.

Set your build/buy/partner position (Days 40–50)

At some point in month two, you will be asked — or will need to answer unprompted — whether a capability should be built in-house, purchased from a vendor, or delivered through a partnership. These decisions cannot sit below CTO level. They affect team size, the product roadmap, and what you tell investors about your moat.

Get ahead of the obvious ones. Which capabilities would become strategic if built internally, and which are better bought? What is the team currently building that an off-the-shelf tool would cover at one-tenth the cost? Your technical state assessment already contains the inputs. The build/buy/partner call is the output — and it belongs in the board summary, not buried in the technical document.

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 organization 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."

Make one external credibility move (Days 70–90)

Internal trust is necessary. External credibility is a different asset, and it is also yours to build.

By Day 90, the CTO should have done at least one thing visible outside the organization: a conference talk, a podcast, a technical post that represents your engineering standards publicly, or a contribution to an advisory board in the space. This does not need to be high-profile. It needs to exist.

This is not vanity. Recruiters use your external presence to assess the quality of team you will attract. Investors use it in technical due diligence to validate that the CTO has a coherent point of view. Enterprise customers — particularly regulated ones — use it to decide whether your platform is being led by someone they can trust with their data.

One signal in the first 90 days is enough. It sets the pattern for the years ahead.

Mistakes Most New CTOs Make

Mistake 1: Reorganizing 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 optimize 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.

Mistake 6: Assuming the context is benign

This framework assumes good faith and a company that is fundamentally operational. Not every context is. If the previous CTO left badly, if there's a pre-existing fault line in the leadership team, or if the board hired you specifically to change something fast — the listening phase still matters, but the risk calculus shifts. What you learn in 1-on-1s may not stay private. Your state assessment may be used politically before you've built enough trust to survive it. The "don't change anything in month one" rule can directly contradict what you were hired to do. In charged contexts: compress Phase 1, be more guarded in what you commit to writing, and identify early whose trust matters most to the board — then build that relationship before you publish anything. If your pre-start briefing contained phrases like "the last CTO had a difficult exit" or "the board wants to see change quickly," treat them as a signal to recalibrate the pace and visibility of every Phase 1 action.

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
  • The board has seen a one-page technical state summary from you — they know who owns the technology narrative
  • You have a clear build/buy/partner position on the organization's most strategically significant capabilities
  • You have made at least one external credibility move — a talk, a post, or a public point of view that represents the company's technical direction

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.

Conclusion

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.