S first 90 days: You just became CTO. Now what? A week-by-week guide to understanding your new role, building credibility, and setting direction without brea... This guide explains The Startup CTO's First 90 Days: A Practical Playbook with practical patterns WRKSHP uses on client builds. Use the checklist below to prioritize next steps and avoid common mistakes that.

You just became CTO. Now what? A week-by-week guide to understanding your new role, building credibility, and setting direction without breaking what's working. This guide explains The Startup CTO's First 90 Days: A Practical Playbook with practical patterns WRKSHP uses on client builds.

S first 90 days overview

Teams implementing s first 90 days need clear ownership, observability, and rollout guardrails. The sections below walk through patterns WRKSHP uses on client builds.

Congratulations on the CTO role. Now the real work begins. Whether you were promoted internally, hired from outside, or are a founder taking on the title formally, the first 90 days set the trajectory for everything that follows.

The temptation is to change things immediately. Resist it. Your first job is to understand, the technology, the team, the business, and the culture. Only then can you make changes that stick.

This playbook provides a week-by-week guide to your first 90 days, drawing from patterns we've seen work across dozens of early-stage companies.

Before Day 1: Preparation

Start gathering context before you officially begin.

Understand the Business

• Read all investor updates and board decks
• Review the product roadmap and recent releases
• Understand the business model and key metrics
• Learn the competitive landscape

Technical Reconnaissance

• Get access to repositories and documentation
• Review the technology stack at a high level
• Understand the deployment and incident history
• Identify any known technical debt or risks

Team Research

• Review org chart and reporting structure
• Read job descriptions and recent hiring activity
• Understand compensation and equity structure
• Learn about recent departures if any

Week 1: Listen and Learn

Your only job this week is to gather information. Make no decisions.

1:1 Meetings with Everyone

Schedule 30-minute 1:1s with every engineer. Ask consistent questions:

• What are you working on?
• What's going well?
• What's frustrating?
• What would you change if you could?
• What should I know that I might not learn otherwise?

Take detailed notes. You'll see patterns emerge.

Stakeholder Meetings

Meet with other leaders to understand their perspective on technology:

• CEO: Vision, priorities, concerns about technology
• Product: Roadmap, engineering relationship, delivery predictability
• Sales: Customer feedback, competitive gaps, promises made
• Customer Success: Top pain points, technical issues affecting retention

Observe

• Sit in on engineering meetings without speaking
• Read recent Slack discussions
• Review recent PRs and technical decisions
• Understand the on-call rotation and recent incidents

Weeks 2-4: Deep Dives

Now dig deeper into specific areas.

Technical Architecture Review

Understand the system deeply:

• How does data flow through the system?
• What are the critical paths for users?
• Where are the scaling bottlenecks?
• What's the testing and deployment pipeline?
• What keeps the team up at night?

Codebase Exploration

Don't try to read everything. Focus on:

• Most frequently changed files
• Most complex components
• Areas mentioned as problematic
• Recent incident-related code

Process Assessment

Understand how work flows:

• How do features go from idea to production?
• How are priorities set?
• How are estimates made?
• How is progress tracked?
• What meetings exist and are they useful?

Document Your Findings

Write up what you've learned:

• Strengths (preserve these!)
• Areas for improvement
• Risks that need attention
• Questions that remain unanswered

Weeks 5-8: Small Wins and Relationship Building

Start making small changes while building trust.

Quick Wins

Identify improvements that are:

• Universally agreed upon
• Low risk
• High visibility

Examples:

• Fix an annoying tooling issue
• Improve a painful process
• Address a security vulnerability
• Clear a backlog of small bugs

These build credibility before you attempt larger changes.

Build Relationships

Deepen relationships with key people:

• Establish regular 1:1s with direct reports
• Build trust with skeptical team members
• Develop partnership with product leadership
• Establish rhythm with CEO

Communicate

Start sharing what you're learning:

• Present architecture overview to team
• Share technical direction with stakeholders
• Be transparent about challenges

Weeks 9-12: Set Direction

Now you have enough context to make bigger moves.

Create a Technical Vision

Document where technology needs to go:

• 6-month technical priorities
• Major investments needed
• Technical debt to address
• Platform and infrastructure evolution

This should connect clearly to business goals.

Establish Priorities

Identify the 3-5 most important things:

• What must be fixed urgently?
• What investments have the highest leverage?
• What can wait?

Ruthless prioritization is essential. You can't fix everything.

Start Larger Initiatives

Begin work on major improvements:

• Hire for critical gaps
• Address major technical debt
• Improve delivery predictability
• Strengthen security and compliance

Formalize Processes

Establish or improve key processes:

• Engineering career ladder
• Technical decision-making
• Incident response
• On-call rotation

Common First 90 Days Mistakes

Changing Too Fast

You don't have context yet. Changes made without context often backfire and damage credibility.

Not Listening Enough

The team knows things you don't. If you're talking more than listening in the first month, you're doing it wrong.

Ignoring Politics

Understand the informal power structures. Who has influence? Who has history? Who needs to be brought along?

Focusing Only on Technology

Your job is to make technology serve the business. If you're not connected to business outcomes, you'll make the wrong investments.

Trying to Code Full-Time

Your value is now leverage through others, not your individual contributions. Let go of being the best coder.

The 90-Day Review

At the end of 90 days, assess:

• What have you learned?
• What have you changed?
• What relationships have you built?
• What's your confidence in the path forward?
• What would you do differently?

Write this up for yourself and share relevant parts with your CEO and board.

Conclusion

The first 90 days are about building the foundation for everything that follows. Listen more than you talk. Learn before you change. Build trust before you spend it.

The companies that succeed with new technical leadership are the ones where the leader took time to understand before trying to transform. The first 90 days aren't about making your mark, they're about earning the right to make a mark later.

Work With WRKSHP

WRKSHP builds AI-native software, operated growth systems, and governance layers for teams that sell outcomes, not billable hours.

Explore enterprise software, Growth OS, GaaS governance, contact, or start a conversation about your next build.

Frequently Asked Questions

What is the main takeaway from "The Startup CTO's First 90 Days: A Practical Playbook"?

S first 90 days: You just became CTO. Use it as a production playbook for operators and engineers, not slide-deck theory.

How does "S first 90 days overview" fit into The Startup CTO's First 90 Days: A Practical Playbook?

S first 90 days overview is a core section of this guide. Apply it after you pick one measurable KPI, then instrument the path that moves that KPI before expanding scope.

What should I watch when working through "Before Day 1: Preparation"?

Treat "Before Day 1: Preparation" as a decision checkpoint: name an owner, define success metrics, and refuse to automate steps that spend money or change production data without an audit trail.

When should I bring in a partner on The Startup CTO's First 90 Days: A Practical Playbook?

Bring in help when you need a fixed-outcome delivery model, governance for agent actions, or a single platform spanning build and growth, patterns WRKSHP uses on enterprise software and Growth OS engagements.