First 90 Days as CTO: Week-by-Week Survival Guide

You just got the title. The business card says Chief Technology Officer. And somewhere between the congratulations and the first Monday morning, a quiet thought settles in: what exactly do I do now?

The first 90 days as CTO are the most consequential of your tenure. The relationships you build, the decisions you make, and the signals you send during this window will define how the next two years unfold. Move too fast and you alienate the team. Move too slowly and the board loses confidence. Get it right and you build a foundation that compounds.

This guide is organised roughly week by week, because the first 90 days have a rhythm, and understanding that rhythm is half the battle. It draws on published practitioner guidance, including Will Larson's first-90-days framework for CTOs and VPs of Engineering.

What should a new CTO do in the first 90 days?

In the first 90 days a new CTO should listen first (days 1 to 30), take two or three visible quick wins while drafting a technology strategy (days 31 to 60), then publish a six-month roadmap, a small set of metrics and a first board update (days 61 to 90). Larson's guidance makes the same point: understand the organisation before making a few well-chosen system changes.

The timing is a practitioner convention, not a research finding. Treat the day counts as a rhythm rather than a deadline. The pressure is real: LeadDev's 2025 report found 65% of surveyed developers and engineering leaders reporting expanded responsibilities (LeadDev, 2025), so protect your learning time.

How do the first 90 days differ if you were promoted, hired or are the founder?

The plan stays the same, but the risks differ by how you arrived. An internal promotion starts with trust and context but carries old relationships and blind spots. An external hire starts with fresh eyes but no map. A founder-CTO already knows the product but must change from builder to leader. Adjust the listening tour accordingly.

If you are weighing the step into the seat, our guides to the engineering manager to CTO and VP of Engineering to CTO transitions cover each route.

Build your own plan: the free CTO 90-day plan generator turns your stage, team size and top problems into a printable 30/60/90 checklist. No signup.

Days 1-30: Listen and Learn

Your instincts will scream at you to fix things. Resist. The first month is not about proving yourself. It is about understanding the terrain before you start moving troops.

Week 1: Orient Yourself

Your only job in the first week is to absorb context. Meet with the CEO, the executive team, and your direct reports. But do not come in with an agenda. Come in with questions.

Questions to ask the CEO:

• What does success look like for the technology org in 12 months?
• What are you most worried about on the technical side?
• What did the previous CTO get right? What did they get wrong?
• Where does the board's attention sit regarding technology?

Questions to ask your direct reports:

• What is working well that I should not touch?
• What is the single biggest thing slowing down the engineering team?
• If you had my job for a day, what would you change first?
• What has been promised to you that has not been delivered?

Write everything down. You are building a map of the organization, and every conversation adds detail.

Weeks 2-3: The Listening Tour

Schedule a 1:1 with every team lead and senior individual contributor. In a smaller company, talk to every engineer. In a larger org, aim for 20 to 30 conversations across all levels. These are not status updates. They are open-ended conversations designed to surface what no dashboard will ever show you.

What you are listening for:

• Morale signals. Are people energized or burned out? Do they trust leadership?
• Tribal knowledge. Who are the unsung heroes keeping critical systems alive? Where are the single points of failure, both technical and human?
• Cultural undercurrents. What gets rewarded? What gets punished? Is the stated culture the actual culture?
• Technical reality. Where does the architecture diagram lie? What is the real state of the codebase, the deployment pipeline, the on-call burden?

You will hear contradictions. That is normal. Two people will describe the same system in completely different terms. The contradictions are data too.

Which listening-tour questions should you ask each stakeholder?

Ask different questions of each stakeholder, because each sees a different part of the system. The goal is to hear what no dashboard shows. Take notes, and share back what you heard in the second month.

Week 4: Map the Landscape

By the end of month one, you should have a working understanding of:

• The technology stack and where it is sound versus where it is held together with hope
• The team structure and whether the org chart reflects how work actually flows
• The stakeholder map including who outside engineering has influence over technical decisions (product, sales, the board)
• The delivery health of the team, including how reliably they ship, how painful deployments are, and what the incident cadence looks like
• The key skills and gaps across your leadership bench

Bessemer's guidance on scaling engineering is a useful reference for structure decisions at this point: add at least one manager beyond about 10 engineers, and around 20 engineers decide whether the current leadership can scale the organisation (Bessemer Venture Partners Atlas).

Do not present findings yet. Resist the temptation to write a "state of engineering" memo. You are still learning, and premature conclusions will cost you credibility when they turn out to be wrong.

Days 31-60: Quick Wins and Strategy

Month two is the bridge. You have enough context to act, but not so much time that people will wait patiently for a grand plan. The goal is to demonstrate good judgment through targeted action while drafting the longer-term strategy in the background.

Identify Three Quick Wins

A quick win meets three criteria: it is visible, it is achievable within two to three weeks, and it directly addresses a pain point your team told you about during the listening tour.

Common quick win categories:

• Developer experience. If builds take 20 minutes, cut them in half. If the local dev environment is a nightmare to set up, fix it. Engineers notice these things immediately.
• Process friction. Kill a meeting that everyone hates but no one has had the authority to cancel. Simplify an approval process that slows down deployments.
• Unblocking a stuck initiative. There is almost always a project that has been stalled for months because it needs an executive decision. Make the call.

Quick wins are not about ego. They are about building trust. Each one sends a signal: this person listens, and things actually change when they listen. If you are preparing for a CTO interview and want to demonstrate this kind of thinking, our guide to CTO interview questions covers how interviewers evaluate your approach to the first 90 days.

Draft Your Technical Strategy

While executing quick wins, start writing the technical strategy document. This is the most important artifact you will produce in your first 90 days. It should cover:

• Current state assessment. Honest, specific, and non-judgmental. Describe the strengths alongside the problems.
• Target state. Where the technology platform needs to be in 18 to 24 months to support the business plan.
• Key initiatives. The three to five major workstreams that will close the gap between current and target state.
• Trade-offs. What you are choosing not to do and why. A strategy that tries to fix everything at once is not a strategy.
• Investment thesis. What resources (headcount, tooling, infrastructure spend) you need and what business outcomes they unlock.

Share early drafts with your direct reports before presenting to the CEO. Their input makes the strategy better, and the process makes them co-owners rather than recipients.

Establish Engineering Principles

Your team needs to know how you think about engineering decisions. Publish a short set of principles, no more than five or six, that will guide technical choices.

Good principles are opinionated and specific. "We value quality" is useless. A principle such as "We invest in automated testing because a production incident costs more than the tests that would have caught it" gives your team a decision-making framework they can apply without you in the room.

Build the Critical Relationships

By month two, you need solid working relationships with three people outside your direct team:

• The CEO. They need to trust your judgment. Establish a regular cadence (weekly or biweekly) and use it to surface decisions and trade-offs, not status updates. A copyable agenda and the other early conversations are in the CTO-CEO relationship.
• The Head of Product. The product-engineering relationship is the engine of the company. If it is adversarial, fix it now. If it is healthy, invest in making it exceptional.
• The CFO. You will need budget. The CFO needs to understand what technology spending produces. Start building the language of ROI around your initiatives early.

Understanding what the CTO role actually demands will help you prioritize which relationships to invest in first.

Days 61-90: Build Momentum

The final month is about converting your listening and learning into visible, sustained momentum. By day 90, the organization should feel that there is a clear direction and a credible plan to get there.

Assess and Restructure If Needed

By now you have a clear picture of your team's strengths and gaps. Some restructuring may be necessary, but approach it carefully.

Restructuring signals that are hard to ignore:

• Teams organized around technology layers instead of customer outcomes
• Key leadership roles filled by people who were promoted past their capability during a growth phase
• Critical capabilities (security, platform, data) that live nowhere in the org chart

If you need to make changes, make them. Delaying a necessary reorg past day 90 rarely makes it easier. But be transparent about the reasons, move quickly once you decide, and support the people affected.

Deliver Your First Board Presentation

Most new CTOs face the board within their first quarter. This is your opportunity to establish credibility with the people who hired you.

What the board wants to hear:

• That you understand the current state of the technology platform, including the risks
• That you have a credible strategy to address those risks and enable growth
• That the engineering team is stable, motivated, and capable
• That you are thinking about technology as a business lever, not just a cost center

Keep it concise. Boards respond to clarity and candor, not to exhaustive detail. If there is a serious problem, name it directly and present your plan to address it. The common practitioner advice is that boards forgive problems more readily than surprises.

Establish Metrics and KPIs

You need a small number of metrics that tell you whether the engineering organization is healthy and improving. Pick no more than five.

Metrics worth tracking:

DORA's five metrics are well-researched and widely adopted; pick the few you can measure reliably rather than all of them. The satisfaction score is the one most CTOs neglect, and it is often the earliest warning signal of trouble.

Prepare Your Day-90 Readout

Close the quarter with a short written readout to the CEO and board: what you learned, what you changed, what you are choosing not to do, and what you need. Use one page and no jargon. For a deeper guide to the metrics and format a board expects, see board-ready CTO communication.

A day-90 readout works best with five parts:

1. What I heard. The three or four themes from the listening tour.
2. What I changed. Quick wins delivered and their effect.
3. What the numbers say. Your chosen metrics, with baselines.
4. The plan. The six-month roadmap and what is not on it.
5. What I need. Decisions, budget or support required from the CEO and board.

Set the 6-Month Roadmap

With your strategy document drafted and your quick wins demonstrating execution, publish a 6-month technology roadmap. This is not a feature list. It is a commitment to the three to five major initiatives that will move the platform from its current state toward the target state you defined in your strategy.

Each initiative should have:

• A clear owner from your leadership team
• A definition of success that the business can verify
• A rough timeline broken into monthly milestones
• Identified dependencies and risks

Share it broadly. Engineering, product, the executive team, and the board should all be able to point to this document and understand where technology is heading.

Common First-90-Day Mistakes

Even strong leaders fall into predictable traps during their first quarter. Here are the ones that recur in practitioner guidance:

Rewriting everything. The codebase is messy. The architecture has problems. But a ground-up rewrite in your first quarter is almost always the wrong call. You do not yet understand why things were built the way they were, and you will underestimate the hidden complexity. Improve incrementally.

Hiring too fast. The instinct to "bring in your people" is strong. Resist it for the first 60 days. You need to understand the existing team before you know what gaps to fill. And importing a crew of loyalists from your last company signals to the current team that they are not trusted.

Ignoring the business. You were hired to lead technology, but the CTO is a business executive first. If you spend your first 90 days deep in architecture diagrams and never learn the revenue model, the sales cycle, or the competitive landscape, you are building strategy in a vacuum. The CTO readiness checklist includes specific questions on business acumen that can help you identify these blind spots before they become liabilities.

Making promises you cannot keep. In the first 30 days, everyone will ask you to commit to timelines, headcount, and priorities. The pressure to say yes is enormous. Say "I need to understand the full picture before I commit" instead. A delayed promise kept is worth far more than an early promise broken.

Skipping the listening tour. Some CTOs, especially those promoted internally, believe they already know what is going on. They skip the structured listening phase and jump straight to action. They are almost always wrong about something important, and they find out the hard way.

Not managing up. Your relationship with the CEO is your most important asset. If you do not proactively manage it, you will find yourself reacting to their concerns instead of shaping their understanding. Schedule the regular check-ins. Send the brief weekly updates. Surface the hard truths before they surface themselves.

The Assessment Advantage

The first 90 days expose your strengths and blind spots faster than any other period in your career. Some CTOs are natural communicators who struggle with technical depth. Others are brilliant architects who cannot navigate boardroom politics. Most have gaps they have never been forced to confront.

Understanding your leadership profile before you walk in the door, or in the first few weeks, gives you a significant advantage. You can lean into your strengths for quick wins and build support structures around your gaps before they become liabilities.

The CTO Coach Leadership Assessment is designed for exactly this moment. It maps your capabilities across the dimensions that matter most in the CTO role, from technical strategy and team building to board communication and stakeholder management. Knowing where you stand is the difference between a deliberate first 90 days and a reactive one.

Having a seasoned CTO as an advisor during your first quarter can compress months of learning into weeks.

Conclusion

The first 90 days as CTO are a paradox. You need to move fast enough to build confidence, but slowly enough to build understanding. You need to demonstrate leadership without appearing to dismiss what came before you.

The framework is simple even if the execution is not: listen first, act on what you learn, then build the systems that will carry you forward.

Day 91 will arrive faster than you expect. When it does, you want to look back on a quarter where you understood the terrain, earned the trust of your team, built the right relationships, and set a direction that the entire organization can get behind.

That is not just survival. That is the foundation of a CTO tenure that actually works.

Frequently asked questions

What should a new CTO do in the first 30 days?

Listen. Meet the CEO, the executive team and your direct reports, then hold one-to-ones with team leads and senior engineers. Learn the stack, the team structure, the stakeholder map and how reliably the team ships. Avoid presenting conclusions or making promises about timelines and headcount until you have the full picture.

What are good quick wins for a new CTO?

A good quick win is visible, achievable in two to three weeks and tied to a pain point raised during the listening tour. Common examples are shortening slow builds, fixing a painful local setup, cancelling a meeting everyone dislikes, simplifying an approval step, or making a decision that has stalled an initiative for months.

How do I present a 90-day plan to the board?

Keep it to one page and lead with the decision or ask. Cover what you heard, what you changed, the metrics with baselines, the six-month roadmap and what you need. Name serious risks directly with your plan to address them. Practitioner advice is that boards respond to clarity and candour and dislike surprises.

What mistakes do new CTOs make in the first 90 days?

Common mistakes are rewriting systems before understanding why they exist, hiring loyalists too fast, ignoring the business and revenue model, promising timelines early, skipping the listening tour (especially after an internal promotion) and neglecting the relationship with the CEO. Each is avoidable with a structured plan and regular check-ins.

Should a new CTO change the tech stack?

Rarely in the first quarter. You do not yet know why systems were built as they were, and rewrites underestimate hidden complexity. Will Larson's guidance argues for understanding the organisation first and then making a few well-chosen system changes. Improve incrementally, and decide on large changes once you have a strategy and the team's input.

Sources

1. Your first 90 days as CTO or VP Engineering Will Larson, 2020
2. DORA metrics: the four keys (current five-metric model) DORA, 2026
3. Engineering burnout is rising as layoffs reshape the tech industry (Engineering Leadership Report 2025) LeadDev, 2025
4. Scaling your engineering team from one to 50 and beyond Bessemer Venture Partners Atlas, 2026