Your First 90 Days as CTO: A Practical Playbook for Startup and Scaleup Leaders

Welcome to the Fire

It's day three. You've just stepped into your new role as CTO, and the reality is nothing like the job description promised.

Production went down twice yesterday. The deployment pipeline breaks more often than it works. Your best senior engineer just pulled you aside to say she's "thinking about options." The CEO wants a confident 12-month technical roadmap by Friday. And you're staring at architecture diagrams that look like they were designed during a particularly chaotic brainstorming session—because they were.

Welcome to the fire.

Here's what most new CTOs get wrong: they think their job in the first 90 days is to fix everything. To prove they were the right hire by making bold, decisive moves. To rewrite that legacy system, reorganize the team, and replace half the tech stack.

This is a recipe for disaster.

Your actual job in the first 90 days is simpler and harder: build a clear picture of reality, earn trust from your team, and set a defensible direction. Everything else is noise.

I've been through this transition multiple times—both as the new technical leader and as the person handing over the keys. I've watched brilliant engineers flame out in their first CTO role because they optimized for looking decisive instead of being effective. And I've seen quieter leaders transform dysfunctional engineering organizations by moving deliberately through these critical first months.

This post is the playbook I wish I'd had on day one. It's not a motivational essay. It's a survival framework.

Days 1–10: Diagnosis, Not Heroics

The Rewrite Temptation

Your first instinct will be to fix things. Fast.

The monolith is a mess? Let's go microservices. The deployment process is manual? Let's implement CI/CD. The team structure doesn't make sense? Let's reorganize.

Stop.

Every one of these instincts might be correct. But acting on them in week one—before you understand the system, the constraints, and the people—is like performing surgery in the dark. You'll cause more damage than you fix, and you'll burn your credibility before you've earned any.

The first 10 days are about diagnosis, not heroics.

The Three-Lens Diagnostic Framework

Think of your first weeks as a structured investigation. You're gathering evidence through three distinct lenses:

Lens 1: Code & Systems

You need to understand the technical reality—not through PowerPoint slides, but through the actual bones of the system.

What to examine:

• Architecture diagrams – Do they exist? Are they current? Ask three different engineers to explain the architecture and see if the stories match.
• Deployment pipeline – How does code go from laptop to production? How long does it take? Who can deploy?
• Incident history – Pull the last 90 days of production incidents. Look for patterns. What breaks repeatedly?
• Key technical risks – What keeps the senior engineers up at night? What's the "if this person gets hit by a bus" scenario?
• Data flows – Where does business-critical data live? Who owns it? What happens if it's lost?

Red flags to watch for:

• "We can't deploy on Fridays" (brittle systems, no confidence)
• "Only Sarah can deploy payments" (knowledge silos, hero dependency)
• "The build takes 45 minutes" (technical debt tax on every change)
• "We don't really have staging" (cowboy operations, high risk)

Action item: Schedule a 2-hour "architecture walkthrough" with your senior engineers. Ask them to draw the system on a whiteboard. Record it. You'll reference this dozens of times.

Lens 2: People & Teams

Technology problems are rarely just technology problems. They're usually people problems wearing technology's clothes.

What to understand:

• Team structure – How are teams organized? By product? By layer? By random historical accident?
• Key individuals – Who are the actual technical leaders, regardless of title? Who has the deep system knowledge? Who do people go to when they're stuck?
• Morale signals – Are people excited or exhausted? How's the on-call rotation working? When did the team last celebrate something?
• Turnover patterns – Who left in the last year? Why? Who's currently interviewing elsewhere?
• Collaboration health – How do engineering and product work together? Is it partnership or constant tension?

Red flags to watch for:

• High turnover among senior engineers (usually a culture or leadership problem)
• "Hero culture" where one or two people work weekends while others coast
• Teams that don't talk to each other (organizational silos)
• Fear-based culture where people hide problems instead of surfacing them

Action item: Set up 30-minute 1:1s with every engineer in the first two weeks. Yes, every single one. If that's more than 30 people, you have an organizational design problem we'll address later.

Lens 3: Business & Product

You're not the CTO of a technology company. You're the CTO of a business that uses technology to create value. Understand the business model or you'll optimize for the wrong things.

What to learn:

• Revenue model – Where does money come from? What are the key customer segments?
• Product strategy – What's the product roadmap for the next 6–12 months? Who decided this?
• SLAs and commitments – What promises has the company made to customers that engineering must deliver?
• Competitive position – What's the moat? What are we racing to build before someone else does?
• Unit economics – What does it cost to acquire and serve a customer? Where does engineering impact that?

Red flags to watch for:

• Engineering has no idea what the business priorities are
• Roadmap was created without engineering input on feasibility or cost
• "We promised the client it would be ready by..." (external deadline-driven chaos)
• Product and engineering see each other as adversaries, not partners

Action item: Schedule time with the CEO, head of product, and head of sales. Ask one question: "If you could wave a magic wand and have engineering deliver one thing in the next 6 months, what would it be and why?"

Your First 10 Days Checklist

By day 10, you should have:

• Read the last 6 months of postmortems
• Talked to every engineer 1:1 (or started the process)
• Understood the deployment pipeline by watching an actual deploy
• Reviewed the current roadmap with product leadership
• Identified the top 3 technical risks (the real ones, not the official ones)
• Found at least one "quick win" opportunity to build credibility
• Resisted the urge to announce major changes

Most importantly: you should have earned the reputation as someone who listens before deciding. That reputation is your foundation for everything that comes next.

Days 10–30: Building Trust and Information Flows

The Listening Tour

You've done the initial diagnosis. Now it's time to go deeper.

Your goal in weeks 2–4 is to establish yourself as someone who asks good questions, takes problems seriously, and follows through. This is how trust gets built—not through inspiring speeches, but through consistent, trustworthy behavior.

The 1:1 Framework

Here's the structure I use for early 1:1s with engineers:

Opening (5 minutes):

• "Tell me about what you're working on right now."
• Listen for energy level, clarity of purpose, and whether they're excited or just grinding.

System knowledge (10 minutes):

• "What's the most fragile part of the system?"
• "If you could refactor one thing with zero consequences, what would it be?"
• "What do you wish the rest of the company understood about what engineering deals with?"

Process and blockers (10 minutes):

• "What slows you down the most in your day-to-day work?"
• "How would you rate our code review process? Our deployment process?"
• "When was the last time you did really focused, uninterrupted work?"

Future vision (5 minutes):

• "If you were me, what would you change first?"
• "What would make this the best job you've ever had?"

Critical final question:

• "Is there anything I should know that I haven't asked about?"

This last question surfaces the hidden issues—the toxic person everyone's afraid to name, the technical timebomb, the secret project that's draining resources.

Pattern Recognition

After 15–20 of these conversations, patterns will emerge:

• Everyone mentions the same pain point (that's your quick win target)
• Everyone talks around the same person or problem (that's your hidden issue)
• Everyone describes the same process as broken (that's a systems problem, not a people problem)
• Senior engineers are exhausted and junior engineers are undertrained (that's a mentorship and delegation issue)

Document these patterns. Not in some formal report—just keep a running list. You'll need it when building your strategy.

The Quick Win Strategy

Between day 10 and 30, you need to deliver at least one visible quick win. Not a six-month platform rewrite—something that makes the team's life measurably better within two weeks.

Good quick win examples:

• Fix the noisy on-call alerts that wake everyone up for nothing
• Speed up the flaky test suite that wastes 20 minutes per developer per day
• Improve the staging environment so deployments stop failing mysteriously
• Kill the weekly status meeting everyone hates and replace it with async updates
• Get approval to hire the senior engineer the team has been begging for

Bad quick win examples:

• Announce a major reorg (too disruptive, too early)
• Mandate a new technology (premature, undermines trust)
• Promise aggressive roadmap acceleration (sets you up for failure)

The quick win serves two purposes: it shows you listened, and it shows you can execute. Both matter equally.

Building Your Kitchen Cabinet

You also need to identify your informal leadership team—the 3–5 senior engineers who actually influence how the team thinks and operates, regardless of their official title.

These are the people you'll:

• Test ideas with before announcing them broadly
• Rely on to help diagnose thorny problems
• Lean on to communicate changes authentically to the team

This isn't about playing favorites. It's about understanding how influence actually flows in your organization. The org chart is a fantasy. Real leadership networks are organic.

Days 30–60: Drafting Your Engineering Strategy

By day 30, you should have a clear picture of reality. Now it's time to turn diagnosis into direction.

The One-Page Engineering Strategy

Most engineering strategies fail because they're either:

• Too vague ("We will build world-class engineering")
• Too detailed (50-page documents no one reads)
• Too disconnected from business reality

What works is a one-page strategy that anyone can read in 3 minutes and remember after one meeting.

Here's the structure:

[Company Name] Engineering Strategy: Next 18 Months

Vision:
One sentence describing how engineering enables the business. Example: "Build a reliable, scalable platform that lets us move from 1,000 to 100,000 customers without multiplying our team size or infrastructure costs."

Strategic Pillars (3–4 maximum):

1. Reliability & Operational Excellence

   • Why: We're losing customer trust and burning out the team with constant firefighting
   • What success looks like: 99.9% uptime, incidents resolved in <30 minutes, on-call load reduced by 50%

2. Developer Velocity

   • Why: Our build times and deployment friction are costing us 30% of engineering capacity
   • What success looks like: Deploy multiple times per day safely, reduce cycle time from 2 weeks to 3 days

3. Platform Consolidation

   • Why: We're running 7 different data stores and 4 languages with a 12-person team
   • What success looks like: Reduce to 2 core data stores, standardize on 2 languages, document our "golden path"

Key Risks:

• Talent: We have 3 critical single points of failure (Sarah on payments, Mike on data pipeline)
• Architecture: The user service can't scale past 10K concurrent users
• Morale: Current on-call rotation is unsustainable; we'll lose people if we don't fix it

Metrics We'll Track:

• Deployment frequency (current: 3x/week → target: 10x/week)
• Mean time to recovery (current: 90min → target: 30min)
• Onboarding time for new engineers (current: 6 weeks → target: 2 weeks)
• On-call pages per engineer per week (current: 8 → target: 2)

How to Build This Strategy

Step 1: Synthesize your diagnosis

Go back through your notes from the three-lens diagnostic. What are the 3–5 themes that keep appearing?

Step 2: Connect to business outcomes

For each potential pillar, ask: "If we succeed at this, how does it help the business grow, save money, or reduce risk?" If you can't answer this clearly, it's not strategic—it's a pet project.

Step 3: Test with your kitchen cabinet

Share a draft with your 3–5 key senior engineers. Ask:

• "Does this match your understanding of our biggest problems?"
• "Are these the right priorities, or am I missing something?"
• "Is this achievable in 18 months, or am I being naive?"

Step 4: Align with the CEO

Schedule an hour with your CEO. Walk through the strategy. Ask:

• "Does this support where we're trying to take the business?"
• "If you had to rank these pillars 1–4, what order would you choose?"
• "What am I not seeing about our competitive or market position?"

The goal isn't to get permission. It's to ensure alignment. You own the engineering strategy, but it must serve the business strategy.

The Anti-Strategy: What You're NOT Doing

Just as important as your strategic pillars is being crystal clear about what you're explicitly choosing not to do.

Examples:

• "We're not migrating to Kubernetes this year—we'll squeeze more out of our current infrastructure"
• "We're not building a mobile app yet—we'll nail the web experience first"
• "We're not hiring 20 junior engineers—we're hiring 5 senior engineers and investing in internal growth"

This gives you cover when stakeholders ask for the moon. You can point to the strategy and say, "That's important, but it's not one of our strategic bets this year. Here's why."

Days 60–90: From Strategy to Execution Plan

Strategy without execution is just philosophy. Now you turn your one-page strategy into a concrete 90-day plan that your team can actually deliver.

The 90-Day Roadmap

Pick 3–5 initiatives maximum. Each initiative should:

• Map directly to one of your strategic pillars
• Have a clear owner (a senior engineer who's accountable)
• Have a measurable outcome (not "improve reliability" but "reduce MTTR to <30 minutes")
• Be achievable in 90 days (or show meaningful progress)

Example 90-day plan:

Initiative 1: Stabilize production operations

• Owner: Sarah K.
• Goal: Reduce incident MTTR from 90 minutes to <30 minutes
• Key work: Implement structured on-call runbooks, add better observability to top 5 services, create incident retro process
• Success metric: 30-minute MTTR maintained for 4 consecutive weeks

Initiative 2: Speed up deployment pipeline

• Owner: Mike R.
• Goal: Cut build time from 40 minutes to <15 minutes
• Key work: Parallelize test suite, upgrade CI infrastructure, implement smart test selection
• Success metric: Developers can deploy a hotfix in under 20 minutes end-to-end

Initiative 3: Document platform architecture

• Owner: You (delegate after it's started)
• Goal: New engineer can understand core system in first week
• Key work: Architecture decision records, service catalog, data flow diagrams, onboarding guide
• Success metric: Next two hires complete onboarding in <2 weeks (vs current 6 weeks)

Notice what's not on this list: rewrites, major technology changes, moonshot features. You're building foundation first. The flashy stuff comes later, once you've earned the right to take bigger swings.

Communicating the Plan

You need two versions of this plan:

Upward communication (CEO, board, founders):

Keep it concise and business-focused:

• "We're investing in operational stability because downtime is eroding customer trust and costing us $X per month"
• "We're accelerating deployment velocity because our current 2-week cycle time means we're losing to competitors who ship daily"
• "We're documenting architecture because our onboarding time is preventing us from scaling the team"

Downward communication (engineering team):

Be honest and empathetic:

• "I know we have 47 things we could work on. I've talked to every one of you, and these three emerged as the biggest force multipliers."
• "This means we're not doing X, Y, and Z right now. That's not because they don't matter—it's because we have to be disciplined about focus."
• "Every initiative has a clear owner and a measurable outcome. We'll review progress every two weeks, and if something isn't working, we'll adjust."

The Discipline of "Not Now"

This is where most new CTOs fail. They say yes to everything because they want to seem responsive and supportive.

But every yes is a dozen no's you're not saying explicitly. When you agree to build that custom integration for the big prospect, you're implicitly saying no to improving test coverage, refactoring the payments system, and mentoring junior engineers.

Learn to say:

• "That's important, but it's not one of our top 3 priorities this quarter. Let's revisit in Q2."
• "We could do that, but it would mean delaying [current priority]. Which would you prefer?"
• "I understand the urgency, but our reliability work is existential. If we don't fix this, nothing else matters."

Your job is to protect focus. The team will thank you for it.

Anti-Patterns for New CTOs

Let me share the failure modes I've seen (and occasionally been guilty of myself):

1. The Big Rewrite Hero

What it looks like:
You arrive, see a messy legacy system, and decide the solution is a ground-up rewrite. You pitch it with confidence: "We'll build it right this time."

Why it fails:

• Rewrites take 3x longer than estimated (always)
• You're now maintaining two systems (legacy + new)
• You've stopped delivering features for 6+ months
• The new system repeats 80% of the old system's mistakes because you didn't understand why decisions were made

What to do instead:
Strangler fig pattern. Identify the most painful 20% of the legacy system and replace it incrementally. Prove you can ship the new approach before committing to a full rewrite.

2. The Tool Tourist

What it looks like:
You read Hacker News and immediately want to replace the team's tools. "Why are we using Jenkins? Everyone uses GitHub Actions now!" Within 60 days, you've changed the monitoring stack, the CI/CD pipeline, and the programming language for new services.

Why it fails:

• Every tool change has a 6-month productivity trough while people learn it
• You've alienated senior engineers who feel their judgment is being dismissed
• You're optimizing for resume-driven development, not business outcomes

What to do instead:
Respect the tools that are working. Change tools only when you have clear evidence they're blocking a strategic goal. And when you do change, migrate incrementally and document why.

3. The Shadow Product Manager

What it looks like:
You bypass the product team and start making product decisions directly. You talk to customers, define features, and set roadmap priorities.

Why it fails:

• You've created a turf war with product leadership
• You're doing two jobs badly instead of one job well
• Engineers lose sight of who to actually listen to

What to do instead:
Build a partnership with product. Make it clear that product owns what to build and why, and engineering owns how and when. Collaborate intensely on feasibility and tradeoffs.

4. The Absent CTO

What it looks like:
You spend all your time in board meetings, fundraising conversations, and conference talks. You haven't touched code in months. You make decisions in a vacuum and the team feels like you're disconnected from reality.

Why it fails:

• You lose technical credibility fast
• You make architectural decisions based on outdated mental models
• The team stops trusting that you understand their daily struggles

What to do instead:
Protect time to stay technical. That doesn't mean writing production code necessarily, but it means doing architecture reviews, reading PRs, participating in incident retros, and staying connected to the actual work.

5. The Perfectionist

What it looks like:
You set incredibly high standards for code quality, documentation, and process. Nothing ships until it meets your exacting bar. You reject PRs for style issues. You insist on 90% test coverage before any deploy.

Why it fails:

• Velocity drops to near-zero
• Engineers feel like they can't meet your standards and stop trying
• You optimize for perfection over progress and the business stalls

What to do instead:
Articulate clear quality gates for different types of changes. A customer-facing feature needs higher quality than an internal tool. A payment system needs higher quality than a marketing page. Right-size your standards to the risk and impact.

Architecture Is Destiny, But Culture Is the Multiplier

Here's what I've learned after 15+ years and dozens of these transitions:

Your architecture decisions will shape velocity for years. Choose monolith vs microservices poorly and you'll pay the tax daily. Choose the wrong database and you'll hit scaling walls at the worst possible moment.

But culture is the multiplier on everything.

A great culture with mediocre architecture will gradually improve the architecture. A toxic culture with beautiful architecture will gradually turn that architecture into a maintenance nightmare as people cut corners, hide problems, and protect their turf.

Your first 90 days are as much about establishing cultural norms as they are about setting technical direction:

• How you react to bad news will determine whether people hide problems or surface them early
• How you handle mistakes will determine whether people take smart risks or play it safe
• How you prioritize will determine whether the team focuses or thrashes
• How you communicate will determine whether the team trusts you or tunes you out

Every decision you make in these 90 days is a signal about what kind of leader you are and what kind of organization you're building.

Move deliberately. Listen generously. Decide clearly. And follow through consistently.

Your 90-Day Checklist

Print this out and keep it somewhere visible:

Days 1–10: Diagnosis

• Complete three-lens diagnostic (code, people, business)
• Meet 1:1 with every engineer
• Read 6 months of postmortems
• Watch an actual production deployment
• Identify top 3 technical risks
• Resist the urge to announce major changes

Days 10–30: Trust Building

• Complete structured 1:1s with full team
• Identify your kitchen cabinet (3–5 key senior engineers)
• Deliver at least one visible quick win
• Document patterns from 1:1 conversations
• Establish regular communication rhythms (standups, retros, etc.)

Days 30–60: Strategy

• Draft one-page engineering strategy
• Test strategy with kitchen cabinet
• Align strategy with CEO/founders
• Share strategy broadly with the team
• Clarify what you're explicitly NOT doing

Days 60–90: Execution

• Create concrete 90-day roadmap (3–5 initiatives max)
• Assign clear owners to each initiative
• Define measurable outcomes for each initiative
• Communicate plan upward (business language) and downward (empathetic language)
• Set up regular progress reviews (every 2 weeks)
• Practice saying "not now" to protect focus

Continuous

• Protect time to stay technically connected
• Model the culture you want to build
• Follow through on commitments, especially small ones
• Celebrate progress, however incremental
• Build trust through consistency, not grand gestures

The first 90 days as CTO are not about being a hero. They're about being deliberate, trustworthy, and clear.

You don't need to fix everything. You need to understand everything, earn trust, and set a direction. The fixes will come—but only if you've built the foundation to make them stick.

Welcome to the fire. Now let's put it out systematically.