You’ve accepted the CTO role. Congratulations. Now the clock starts.

The first 90 days will define your tenure. Move too fast and you’ll break things you don’t understand — alienating the team that was there before you. Move too slow and the board will question whether they hired the right person. The art is in the calibration: appearing decisive while actually learning, building trust while establishing authority.

Here’s the playbook that actually works, built from watching dozens of CTO transitions succeed and fail.

Days 1-30: Listen

Your primary job in the first month is not to fix things. It is to understand things. Every instinct you have as a technical leader will push you toward solutions. Resist that instinct. Solutions without context create new problems.

Week 1: The Listening Tour

Schedule 30-minute 1:1s with every engineering manager, every product manager, and every executive. If the organization is large, extend this to key individual contributors — the staff engineers and senior engineers whose opinions shape the engineering culture.

Ask the same five questions to everyone:

1. What’s working well that I should protect?
2. What’s the biggest risk in the engineering organization right now?
3. If you had a magic wand, what’s the one thing you’d change?
4. What decision has been deferred the longest?
5. What’s something I should know that nobody will volunteer?

Take meticulous notes. Look for patterns. The things that three or more people mention independently are your real priorities — not the ones in the board deck, not the ones the CEO mentioned in the interview process, not the ones the previous CTO left in their departure notes.

Pay particular attention to question 5. The most valuable information in any organization is the information nobody volunteers. A senior engineer who says “the payment service has a race condition that we’ve been lucky about” is giving you a gift that no dashboard will show.

Week 2-3: Read the Code

Not all of it — that’s neither possible nor useful. But enough to build a technical mental model.

Pull down the main repository. Read the README (if it exists — its absence or staleness is a signal). Look at the directory structure. Read the deployment pipeline configuration. Review the last 20 incident reports — they tell you where the system actually breaks, not where the architecture diagram says it should.

Check the test coverage, not as a quality judgment but as a risk assessment. Read the architecture decision records (ADRs) if they exist. Look at the dependency list and note anything that’s end-of-life or severely outdated.

You’re not auditing. You’re building context. When an engineer tells you “the payment service is fragile,” you want to know what that actually means — which endpoints, which dependencies, which failure modes. When someone says “our deployment process is slow,” you want to know whether that means 15 minutes or 4 hours.

Week 3-4: The Stakeholder Map

Map the political landscape, not just the organizational one. Every engineering organization exists within a web of relationships with product, sales, finance, and executive leadership.

Understand:

• Who makes resource allocation decisions? (It’s not always who the org chart says)
• Which teams have political protection? (Usually the CEO’s pet project or the revenue-critical team)
• What’s the relationship between engineering and product? (Collaborative, adversarial, or dysfunctional?)
• What did the previous CTO get wrong? (You’ll inherit the organizational scar tissue)

Week 4: The Assessment Document

Write a 2-page document — no more — that summarizes:

• Strengths: 3-5 things the organization does well (lead with these; showing you recognize what works builds trust)
• Risks: 3-5 things that could cause major problems if not addressed
• Opportunities: 3-5 things that could dramatically improve delivery or team health
• Questions: Things you still don’t understand and need more time to evaluate

Share it with the CEO. Not as a prescription — as a diagnostic. “Here’s what I’ve learned. Here’s what I still need to learn. Here’s where I think we should focus.” This document establishes that you’ve been listening, you’ve been thoughtful, and you’re not going to make reckless changes.

Days 31-60: Build

The Quick Win

Every new CTO needs a quick win. Not a vanity project or a technology-driven initiative that only engineers appreciate — a genuine improvement that the entire team can feel.

The best quick wins share three characteristics:

• They fix something that has annoyed the team for months (demonstrating that you listen)
• They take less than 2 weeks to implement (demonstrating that you execute)
• They show the kind of leadership you intend to provide (demonstrating your values)

Common quick wins that have outsized impact:

• Fix the CI/CD pipeline so deploys take 10 minutes instead of 45. Every engineer feels this improvement multiple times per day.
• Establish a clear incident response process if one doesn’t exist. Nothing says “I care about your quality of life” like ensuring that on-call isn’t chaos.
• Kill a meeting that everyone hates but nobody has had the authority to cancel. This is a power move that engineers never forget — the new CTO walked in and immediately made their lives better.
• Fix the on-call rotation so it’s actually fair. If two engineers have been carrying the on-call burden for six months while others contribute nothing, fixing this builds enormous goodwill.

The Organizational Assessment

By week 6, you should have a well-informed opinion about the engineering org structure. Not an org chart redesign — a philosophy about how teams should be organized:

• Team topology: Are teams aligned to products, features, or technologies? Which alignment would best serve the current product architecture and business strategy?
• Span of control: How many direct reports does each manager have? More than 8 is a problem — managers can’t provide meaningful coaching to more than 7-8 people. Fewer than 4 suggests unnecessary management overhead.
• Decision rights: Who can deploy to production? Who can approve a new database? Who can say no to a feature request? Unclear decision rights create bottlenecks and frustration.

Don’t reorganize yet. Reorganizations in the first 60 days signal to the team that you don’t respect what came before. But start socializing your thinking with the leadership team to test your assumptions and build alignment.

The Technical Strategy Draft

Write the first draft of a 12-month technical strategy. It should be:

• 3-5 pages maximum (anything longer won’t be read)
• Written for a business audience, not a technical one (the CEO and CFO need to understand it)
• Tied to business outcomes, not technology goals (nobody cares about Kubernetes; they care about deployment reliability)
• Honest about trade-offs and risks (unrealistic optimism destroys credibility faster than anything else)

“We will adopt Kubernetes” is not a strategy. “We will reduce deployment failures by 80% and enable weekly releases by standardizing our container platform” is a strategy — because it names the business outcome, quantifies the improvement, and implies the approach without mandating a specific technology.

Days 61-90: Execute

The 90-Day Plan

Present your 90-day plan to the executive team. It should contain exactly three categories:

Three initiatives you will start. Choose initiatives that demonstrate your priorities and address the top risks from your assessment. If reliability is the biggest risk, start an SRE initiative with specific availability targets. If talent retention is the problem, start a developer experience program with measurable improvements to tooling and process. If technical debt is crushing velocity, propose a structured debt reduction program with clear business justification.

Two things you will stop. This is where courage matters and where most new CTOs fail. Every engineering organization has projects that should have been killed months ago — failed experiments consuming resources, technologies adopted by a previous leader that nobody wants to maintain, initiatives that have lost their business justification.

Stopping things is harder than starting things because it requires acknowledging that smart people made decisions that didn’t work out. Frame it as learning, not failure: “We’ve learned enough from this experiment to know that the approach isn’t working. Continuing to invest in it would prevent us from investing in things that will work.”

One thing you will protect. Identify the cultural or technical asset that makes this engineering organization special and explicitly commit to protecting it. Maybe it’s the open-source contribution program. Maybe it’s the weekly architecture review. Maybe it’s the fact that engineers have dedicated learning time or a strong promotion process.

Whatever it is, protect it publicly. Your team needs to know that change doesn’t mean destroying everything that came before. Change without continuity feels like disruption; change with continuity feels like evolution.

The Meta-Lesson

The first 90 days aren’t about proving you’re smart. Your team already knows you’re smart — that’s why you got the job. Every CTO who failed in their first year was smart. Intelligence isn’t the differentiator.

The first 90 days are about proving you’re wise. That you listen before you prescribe. That you understand context before you apply frameworks. That you can distinguish between problems that need immediate action, problems that need patience, and problems that aren’t actually problems.

The CTOs who fail in the first year are almost always the ones who had all the answers on day one — who came with a playbook from their previous company and applied it without understanding the new context. The ones who succeed are the ones who arrived with questions, built understanding, and crafted solutions specific to the organization they joined.

---

The Garnet Grid perspective: New CTOs face a unique challenge — they need to assess rapidly but act deliberately. We offer architecture audits designed specifically for technology leaders in transition, providing the technical and organizational assessment that accelerates the listening phase. Explore the audit →