What a CTO Should Do in the First 90 Days

Here's what a CTO should do in the first 90 days: spend days 1–30 listening and assessing the technical landscape, days 31–60 delivering quick wins and building strategy, and days 61–90 executing and scaling the foundation for long-term success.

I've worked with dozens of CTOs stepping into new roles, and I've noticed a clear pattern: the ones who spend their first 30 days listening and asking questions consistently outperform those who start making immediate changes. Yet most new CTOs get it backwards.

Your first 90 days as CTO will define your entire trajectory at the organization. You can either build trust and credibility by being thoughtful and deliberate, or you can create friction by moving too fast without understanding the landscape. The good news? There's a proven playbook.

In this post, I'm sharing the exact framework I use — both as a fractional CTO who joins companies to assess their technical health, and as someone who has advised hundreds of founders and engineering leaders. This isn't theory. These are patterns that work.

The First 90 Days Framework

Think of your first 90 days in three distinct phases:

• Days 1-30: Listen & Assess — Understand what you're working with
• Days 31-60: Quick Wins & Strategy — Build momentum and credibility
• Days 61-90: Execute & Scale — Establish the foundation for long-term success

The magic of this framework is that each phase builds on the previous one. You can't execute effectively on days 61-90 if you haven't done the listening work in days 1-30. And you'll lack the political capital to push major changes if you haven't delivered quick wins in days 31-60.

---

Days 1-30: Listen & Assess

Your job in the first month is to become a student of your organization. Resist the urge to "fix" things yet. You don't have enough information.

Conduct a Technical Audit (Week 1-2)

Start with your tech stack. Document:

• Current architecture — What does your system look like? Draw it out. Where are the bottlenecks?
• Technology choices — What languages, frameworks, databases are you running? Why were these chosen?
• Infrastructure — Are you on-premise, cloud, hybrid? What's your deployment process like?
• Code quality — Run a static analysis. Look at test coverage. Read 10-15 pull requests to understand code patterns.

This isn't about judgment. It's about context. I've walked into codebases that seemed messy on the surface but had solid engineering principles underneath. I've also seen beautiful code that hid fundamental architectural problems.

You're looking for answers to: "What would break this system right now?" and "Where is the team experiencing the most pain?"

Meet Every Engineer 1-on-1 (Week 1-4)

Schedule 30-45 minute conversations with every engineer on your team. If you have a team of 8, that's 4-6 hours per week. That's non-negotiable.

In these conversations, ask:

• "What's your biggest frustration with our tech right now?"
• "What part of the codebase do you dread touching?"
• "What decision made by the previous CTO do you think was wrong?"
• "If you could change one thing about how we work, what would it be?"
• "Who on the team should I talk to about [specific area]?"

Listen more than you talk. Take notes. Don't defend previous decisions. Don't promise changes. Just listen.

By week 2, you'll start seeing patterns. Three engineers mention database query performance. Two engineers say the CI/CD pipeline is broken. Four say they wish there was better documentation.

Those patterns are your gold.

Understand the Product Roadmap (Week 2-3)

Meet with your VP of Product or Product Manager. Get clarity on:

• What are the top 3 product priorities for the next 6 months?
• What's constrained by technical limitations?
• Where do we lose deals because of technical debt?
• What's the user retention trend?

This is critical because your technology roadmap must serve the product roadmap. Too many CTOs build technology roadmaps in isolation. That's a mistake.

Identify the Top 3 Technical Risks (Week 2-4)

By the end of week 4, you should be able to articulate:

1. The single biggest technical risk to the business (e.g., "Our database is 85% capacity and we have no sharding strategy") 2. The area causing the most operational pain (e.g., "Deployments take 2 hours and fail 20% of the time") 3. The technical debt that's slowing product velocity (e.g., "Our API has no versioning strategy, so every change breaks clients")

These aren't things to fix yet. They're things to understand deeply.

Map the Current Architecture

Create a simple document or diagram that shows:

• How data flows through the system
• What external dependencies exist
• Where single points of failure are
• Performance characteristics of each component

This artifact will be invaluable when you need to explain technical decisions to non-technical stakeholders later.

Key Principle for Days 1-30: Your job is to be a good listener and observer, not a decision-maker. The engineer who complains about the database isn't always right. The founder who says "this is our biggest problem" might be wrong. You're gathering data, not making judgments yet.

---

Days 31-60: Quick Wins & Strategy

Now you have context. Use it.

In this phase, you want to accomplish three things:

1. Deliver at least one quick win that improves daily developer experience 2. Establish the fundamental engineering processes 3. Present a clear technology roadmap to leadership

Fix the Most Painful Developer Experience Issue

Pick one thing that's causing friction for most engineers. Based on my experience, these are the most common:

• Slow deployment pipeline — Engineers are waiting 30+ minutes to deploy
• Flaky tests — The test suite is unreliable, so engineers don't trust it
• Broken CI/CD — Merging code is a nightmare because the build system is broken
• Unclear documentation — New engineers spend days figuring things out

Pick the one that affects the most people. Fix it in days 31-45. Make sure engineers see the impact.

Why? Because delivering a quick win builds trust. Engineers start thinking, "This new CTO actually understands the problems and can fix them."

I worked with a startup where the CI/CD pipeline was a Frankenstein of shell scripts held together with duct tape. It was failing 25% of the time. We spent three weeks redesigning it around a proper CI/CD platform (GitHub Actions, in this case). Deployment time dropped from 45 minutes to 8 minutes. That single improvement changed the entire team's perception of the new CTO.

Establish Core Engineering Processes (Days 31-60)

Before you go further, you need basic processes:

Don't overcomplicate these. A one-page code review guide is better than a 50-page document no one reads. An on-call runbook that covers "what to do when the database is slow" is better than philosophy about on-call culture.

You need these in place before you scale. They're the foundation.

Present a 12-Month Technology Roadmap to Leadership (Days 45-60)

This is your first major deliverable to the organization. It should answer:

• What are we shipping in the next 12 months from a technology perspective?
• How does this serve the product roadmap?
• What technical risks are we mitigating?
• What will we NOT do, and why?

This roadmap doesn't need to be detailed. Here's a real example from a company I advised: Notice what's NOT on the roadmap? Complete rewrites of the frontend. Switching to a different database because it's "trendy." Migrating to Kubernetes "because enterprise companies use it."

A technology roadmap is about serving the business, not about using the latest technology.

Hire the First 1-2 Critical Roles (Days 31-60)

If you need more people, start recruiting now. Not because you want to build a big team, but because you've identified specific gaps.

Maybe you need a Staff Engineer who can own the architecture work. Maybe you need a DevOps engineer to overhaul your deployment pipeline. Maybe you need someone to take over payment processing.

Be specific about what you're hiring for. "We need more engineers" is not specific. "We need a Staff-level engineer who has worked with distributed systems and can lead the architecture redesign" is specific.

Key Principle for Days 31-60: You're building credibility and momentum. Deliver one meaningful improvement. Show a thoughtful roadmap. Make one key hire.

---

Days 61-90: Execute & Scale

Now it's time to move. You have trust. You have a roadmap. You have the core processes in place.

Deliver One Meaningful Technical Improvement

This is where you start executing on your roadmap. Pick the first priority from your 12-month plan and get it done (or get it significantly started) by day 90.

This doesn't mean it's finished. It means you have a working prototype, a clear implementation plan, and the team is excited about it.

Establish Engineering Metrics

You can't improve what you don't measure. By day 90, you should be tracking:

• Deployment frequency — How often are we shipping code to production?
• Lead time for changes — How long from "idea" to "in production"?
• Mean time to recovery (MTTR) — When things break, how fast do we fix them?
• Change failure rate — What percentage of deployments cause issues?

These are the DORA metrics. They're not perfect, but they're a good starting point for understanding engineering efficiency.

The goal isn't to hit specific numbers on day 90. The goal is to have baseline measurements so you know if you're improving 6 months from now.

Create the 12-Month Technology Roadmap in Detail

You presented a high-level version in days 31-60. Now create the detailed version. This includes:

• Month-by-month breakdown of what you're building
• Resource requirements (how many people, external tools, budget)
• Dependencies (what needs to happen before something else can start)
• Risks (what could derail this)

This isn't written in stone. It will change. But it gives the organization clarity on the direction.

Start Building Engineering Culture

Engineering culture compounds over time. Start early.

• Institute tech talks — Once a week, have someone deep-dive on a technical topic
• Establish documentation standards — Architecture Decision Records (ADRs) for big decisions
• Create a mentorship program — Pair junior engineers with senior ones
• Celebrate wins — When the team ships something meaningful, acknowledge it

Small investments in culture now prevent massive problems later.

Key Principle for Days 61-90: You're transitioning from learning to executing. You're not done learning — you'll learn for years — but you're moving from observation to action.

---

What Mistakes Do New CTOs Make in Their First 90 Days?

I've seen these patterns repeatedly, so let me be direct about what not to do:

Mistake #1: Trying to Rewrite Everything

The biggest mistake is declaring "the codebase is a mess, we need to rewrite it." This is almost always wrong.

Rewrites take 2x as long as you think, introduce new bugs, and distract the team from shipping product. The existing codebase works. It has bugs. It has debt. It also has institutional knowledge embedded in it.

If something truly needs to be rewritten, you'll know by month 4 or 5, not by month 1.

Mistake #2: Not Talking to Customers

I've worked with CTOs who spend all their time optimizing the infrastructure and zero time understanding what customers actually need. Then the VP of Product says, "We're losing deals because customers want X feature," and the CTO is surprised.

In your first 90 days, talk to 5-10 customers. Ask them what's broken. Ask them why they chose you over the competition. Ask them what they wish worked better.

This context will inform every decision you make.

Mistake #3: Over-Hiring Too Fast

You'll be tempted to say "we need 5 new engineers right now." Resist this.

Hiring too fast is one of the clearest ways to create dysfunction. New engineers need onboarding. Your processes need to scale to handle more people. Culture gets harder to maintain.

Better to be conservative and hire one great person every 4-6 weeks than to hire five mediocre people at once.

Mistake #4: Ignoring Technical Debt

Some CTOs swing too far in the other direction. They ignore technical debt because it's not "user-facing."

Technical debt is like compound interest on a credit card. Small amounts don't matter. Massive amounts destroy you. By year 2, if you haven't been thoughtful about tech debt, it will be crippling your product velocity.

Make tech debt reduction part of your quarterly planning from day 1.

Mistake #5: Not Building Relationships with Product and Sales

The worst CTOs are the ones who say, "I don't talk to customers, I just build the product."

You need to understand what Product is trying to do. You need to understand what Sales is hearing from the market. You need to understand what Customer Success is struggling with.

The best technologists are the ones who understand the business context for their decisions.

---

Why Is a Fractional CTO Effective in the First 90 Days?

Here's something many founders don't realize: a fractional CTO can do this entire 90-day assessment and hand off to a full-time hire with a clear playbook.

The scenario usually looks like this:

1. Founder says: "We've grown to 5 engineers and we need a CTO, but we're not sure what direction to go." 2. Fractional CTO comes in for 4-6 weeks and does the full Listen & Assess phase. 3. Clear picture emerges of what the team needs, what the architecture should look like, what processes are missing. 4. Fractional CTO helps recruit and onboard the full-time CTO, making sure they're the right fit. 5. Full-time CTO comes in with a playbook, not a blank slate.

This is dramatically more efficient than hiring a full-time CTO blind and hoping they figure it out.

I've seen founders avoid hiring a CTO for 12+ months because they were worried about getting the wrong person. A fractional CTO can derisk that decision significantly.

Learn more about how fractional CTO services work: Fractional CTO Services

---

What Should a CTO Have Accomplished After 90 Days?

By the end of day 90, you should be able to say:

• I've talked to every engineer on the team and understand their top frustrations
• I've done a complete technical audit and identified the top 3 risks
• I've delivered one meaningful improvement to developer experience
• I've established core engineering processes (code review, CI/CD, on-call, docs)
• I've presented a 12-month technology roadmap to leadership
• I've started recruiting the first critical hire
• I've established baseline engineering metrics
• I've started building engineering culture
• I've talked to 5-10 customers and understand their pain points

If you can check 7 of these 9 boxes, you've had a successful first 90 days.

---

Ready to execute your 90-day plan? Whether you're a new CTO building your roadmap or a founder looking to hire one, schedule a call to discuss your specific situation. Or learn more about Fractional CTO Services if you need the assessment without the full-time commitment.