← CTO Handbook Chapter 5

The First 90 Days

A playbook for new CTOs — whether you're joining as a fractional leader or full-time. How to assess, plan, and start making impact quickly.

Your first 90 days set the tone for your entire tenure. Move too fast and you'll make mistakes that damage trust. Move too slow and you'll lose momentum and credibility. This chapter provides a structured approach to getting it right.

Assessment Framework

Before you can fix anything, you need to understand what you're working with. The first 30 days should be primarily about learning.

The Five Dimensions

Assess each of these areas systematically:

1. Technical Health

  • Architecture: Is it sound? Scalable? Maintainable?
  • Code quality: What does the codebase look like?
  • Technical debt: How much? Where? How urgent?
  • Infrastructure: Reliable? Secure? Observable?
  • Development practices: CI/CD, testing, code review?

2. Team & Organization

  • Team composition: Skills, experience levels, gaps
  • Team health: Morale, engagement, turnover risk
  • Structure: How are teams organized? Is it working?
  • Processes: How does work flow from idea to production?
  • Leadership: Who are the key people? Who has influence?

3. Product & Business Alignment

  • Product-engineering relationship: Healthy or adversarial?
  • Roadmap clarity: Does the team know what they're building and why?
  • Customer impact: How does engineering connect to customer value?
  • Business understanding: Does the team understand the business model?

4. Risks & Vulnerabilities

  • Key person dependencies: What breaks if someone leaves?
  • Security posture: Any obvious vulnerabilities?
  • Compliance: Any regulatory requirements being missed?
  • Scaling concerns: What happens at 2x, 10x current load?

5. Culture & Dynamics

  • Decision-making: How are decisions made? By whom?
  • Communication: How does information flow?
  • Conflict: How is disagreement handled?
  • History: What's been tried before? What failed? Why?

How to Gather Information

1:1 conversations: Meet with everyone — engineers, product managers, designers, executives, support team. Ask open-ended questions and listen more than you talk.

Key questions to ask everyone:

  • "What's working well that we should preserve?"
  • "What's the biggest thing slowing us down?"
  • "If you were me, what would you focus on first?"
  • "What do you wish leadership understood better?"
  • "What would make your job easier?"

Technical review: Read code. Look at the architecture. Review recent incidents. Examine the deployment process. Don't just rely on what people tell you — verify.

Data analysis: Look at metrics if they exist. Cycle time, deployment frequency, incident rates, velocity trends. Data tells stories that people might not.

Quick Wins vs. Strategic Changes

You need both, but the timing matters. Quick wins build credibility for strategic changes.

Quick Wins (Days 15-45)

Quick wins are improvements that:

  • Can be implemented in days, not weeks
  • Have obvious, visible benefit
  • Don't require major process or cultural change
  • Low risk — if they fail, it's not a big deal

Examples of good quick wins:

  • Fixing a long-standing bug that frustrates everyone
  • Removing a bureaucratic process nobody likes
  • Setting up a dashboard for visibility into something important
  • Improving a painful part of the development workflow
  • Clearing a blocker that's been stuck for weeks

💡 The Best Quick Wins

The best quick wins come from your listening tour. When multiple people mention the same frustration, that's a quick win waiting to happen. You get credit for listening AND for acting.

Strategic Changes (Days 45-90+)

Strategic changes are larger initiatives that require more time and buy-in:

  • Reorganizing team structure
  • Major architecture decisions
  • New processes or workflows
  • Significant technology changes
  • Hiring strategy shifts

For strategic changes:

  1. Build the case: Data, examples, clear reasoning
  2. Socialize before deciding: Get input, address concerns
  3. Start small: Pilot with one team before rolling out widely
  4. Communicate clearly: The what, why, and how
  5. Measure and adjust: Track whether it's working

Building Trust & Relationships

Everything you do depends on trust. Without it, your technical expertise is useless.

Trust with Engineers

  • Listen first: They've been here longer than you. They know things you don't.
  • Be technically credible: You don't need to be the best coder, but you need to understand the work.
  • Have their back: Shield them from politics. Advocate for their needs.
  • Be honest: If you don't know something, say so. If something is hard, acknowledge it.
  • Deliver on promises: Small commitments matter. Follow through consistently.

Trust with Leadership

  • Communicate proactively: No surprises. Share problems early with your plan to address them.
  • Translate effectively: Help them understand technical concepts in business terms.
  • Be realistic: Don't over-promise. Set expectations you can meet or exceed.
  • Show progress: Regular updates on what's improving and why it matters.

Trust with Peers

  • Be collaborative: Engineering doesn't exist in isolation. Partner with product, design, sales.
  • Assume good intent: Your peers want the company to succeed too.
  • Find shared goals: What do you both want? Start there.

Setting Up for Success

The 30-60-90 Framework

30

Days 1-30: Learn

  • Complete assessment across all five dimensions
  • Meet with all key stakeholders
  • Identify 2-3 quick wins
  • Build initial relationships
  • Document findings and initial observations

Deliverable: Written assessment shared with leadership

60

Days 31-60: Act

  • Execute quick wins
  • Establish working rhythms (1:1s, team syncs)
  • Begin strategic initiatives
  • Make first hiring decisions if needed
  • Deepen relationships with key people

Deliverable: 90-day plan with specific initiatives and metrics

90

Days 61-90: Scale

  • Complete initial quick wins
  • Show progress on strategic initiatives
  • Build systems that work without you
  • Develop internal leaders
  • Plan for the next phase

Deliverable: Review of progress and plan for months 4-6

Common Pitfalls

❌ Changing Too Much Too Fast

The urge to prove your value by making immediate changes is strong. Resist it. Changes made without understanding context often backfire. The team will resent being "fixed" by someone who doesn't understand their situation.

❌ Criticizing Predecessors

However tempting, never trash-talk those who came before you. The team might have worked hard on things you're criticizing. Focus on the future, not blame for the past.

❌ Going Dark

New CTOs sometimes disappear into assessment mode, emerging weeks later with a grand plan. Stay visible. Over-communicate. Share what you're learning along the way.

❌ Ignoring the Human Element

Technology problems are often people problems in disguise. That slow deployment process might exist because of a painful incident. That weird architecture decision might have made sense at the time. Understand the history before judging.

❌ Trying to Do Everything Yourself

You can't scale by being involved in everything. From day one, look for people you can develop and delegate to. Your job is to make the team better, not to be the hero.

Key Takeaways

  • Spend your first 30 days primarily in learning mode
  • Assess systematically: technical, team, alignment, risks, culture
  • Quick wins build credibility for larger strategic changes
  • Trust is the foundation — with engineers, leadership, and peers
  • Use the 30-60-90 framework to structure your approach
  • Avoid the common pitfalls: moving too fast, criticizing the past, going dark