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. Move too slow and the board will question whether they hired the right person. The art is in the calibration.

Here’s the playbook that actually works.

Days 1-30: Listen

Your primary job in the first month is not to fix things. It is to understand things.

Week 1: The Listening Tour

Schedule 30-minute 1:1s with every engineering manager, every product manager, and every executive. Ask the same five questions:

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 notes. Look for patterns. The things that three or more people mention independently are your real priorities — not the ones in the board deck.

Week 2-3: Read the Code

Not all of it. But enough. Pull down the main repository. Read the README (if it exists — that’s a signal in itself). Look at the deployment pipeline. Read the last 20 incident reports. Check the test coverage. Read the architecture decision records.

You’re not auditing. You’re building a mental model. When an engineer tells you “the payment service is fragile,” you want to know what that actually means.

Week 4: The Assessment Document

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

• Strengths: 3-5 things the organization does well
• Risks: 3-5 things that could cause major problems
• Opportunities: 3-5 things that could dramatically improve
• Questions: Things you still don’t understand

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

Days 31-60: Build

The Quick Win

Every new CTO needs a quick win. Not a vanity project — a genuine improvement that engineers can feel.

The best quick wins share three characteristics:

• They fix something that annoyed the team for months
• They take less than 2 weeks to implement
• They demonstrate the kind of leadership you intend to provide

Common quick wins:

• Fix the CI/CD pipeline so deploys take 10 minutes instead of 45
• Establish a clear incident response process (if one doesn’t exist)
• Kill a meeting that everyone hates but nobody has the authority to cancel
• Upgrade the on-call rotation so it’s actually fair

The Organizational Design

By week 6, you should have an opinion about the engineering org structure. Not a org chart — a philosophy:

• Team topology: Are teams aligned to products, features, or technologies? Which should they be?
• Span of control: How many direct reports does each manager have? (More than 8 is a problem.)
• Decision rights: Who can deploy to production? Who can approve a new database? Who can say no to a feature request?

Don’t reorganize yet. But start socializing your thinking with the leadership team.

The Technical Strategy Draft

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

• 3-5 pages maximum
• Written for a business audience, not a technical one
• Tied to business outcomes, not technology goals
• Honest about trade-offs and risks

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

Days 61-90: Execute

The 90-Day Plan

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

Three initiatives you will start: Choose initiatives that demonstrate your priorities. If reliability is the biggest risk, start an SRE initiative. If talent retention is the problem, start a developer experience program. If technical debt is crushing velocity, propose a “debt sprint.”

Two things you will stop: This is where courage matters. Every engineering organization has projects that should have been killed months ago. Failed experiments that are consuming resources. Technologies that were adopted by a previous leader and nobody wants to maintain.

Stopping things is harder than starting things. It requires acknowledging that smart people made decisions that didn’t work out. Frame it as learning, not failure.

One thing you will protect: Identify the cultural or technical asset that makes this engineering organization special. 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.

Whatever it is, explicitly commit to protecting it. Your team needs to know that change doesn’t mean destroying everything that came before.

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.

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 and problems that need patience.

The CTOs who fail in the first year are almost always the ones who had all the answers on day one. The ones who succeed are the ones who had all the right questions.

---

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. Explore the audit →