The Startup CTO Playbook: Your First 100 Days

You've just accepted the CTO role at a startup. Maybe you're employee #3 building from scratch. Maybe you're inheriting a 15-person engineering team from a departing technical co-founder. Either way, the next 100 days will determine whether you succeed or spend 18 months fighting fires you could have prevented.

I've been through this transition twice as the incoming CTO, and I've advised four other CTOs through their first quarters. The pattern is consistent: CTOs who use their first 100 days strategically build teams that scale. CTOs who dive straight into coding or immediately start "fixing things" lose credibility and create churn.

This playbook provides a week-by-week structure for your first 100 days.

The Three Phases

Phase	Days	Focus	Primary Output
Assess	1-30	Listen, learn, document	Technical Assessment Document
Align	31-60	Strategy, priorities, communication	Engineering Roadmap + Quick Wins
Accelerate	61-100	Execute, hire, systematize	Velocity metrics improving

The critical rule: do not make major changes in Phase 1. You don't have enough context yet. The fastest way to lose engineering team trust is to arrive and immediately declare "this is all wrong." Even if it is—you need to earn the right to say so.

Phase 1: Assess (Days 1-30)

Week 1: Listen and Learn

Your first week is about building relationships and gathering information. You're not making decisions yet—you're loading context.

Day	Priority Activity	Secondary Activity
1	1:1 with CEO (expectations, priorities, concerns)	Get all system access, read company docs
2	1:1 with each engineer (30 min each)	Read the codebase README and architecture docs
3	1:1 with product leader and designer	Walk through the product roadmap
4	Shadow the on-call engineer	Review incident history (last 6 months)
5	1:1 with head of sales/CS (customer pain points)	Review support tickets for technical themes

The engineer 1:1s are the most important meetings of your first week. Ask each engineer:

• What's working well that I should protect?
• What's the biggest thing slowing you down?
• What would you change if you had the authority?
• What are you worried I might change?

That last question builds trust. It shows you understand that new leadership creates anxiety, and you're not going to bulldoze through their work.

Week 2: Technical Deep Dive

Now you have relationship context. Time for technical context.

Area	Assessment Method	What You're Looking For
Architecture	Read code, trace a request end-to-end	Complexity level, coupling, scaling bottlenecks
Infrastructure	Review IaC, cloud console, cost dashboard	Spending efficiency, automation level, reliability
Development process	Observe a full feature cycle (design → deploy)	Bottlenecks, handoff friction, quality gates
Data	Review schema, data flows, analytics capability	Data quality, warehouse state, reporting gaps
Security	Review access controls, secrets management, audit history	Critical vulnerabilities, compliance gaps

You're not fixing anything yet. You're documenting what you find.

Week 3: Process and People Assessment

Dimension	Questions to Answer
Team health	Attrition history? Engagement signals? Compensation competitiveness?
Hiring pipeline	Open roles? Time-to-fill? Interview process quality?
Engineering culture	Decision-making style? Blameless vs blame? Shipping cadence?
Technical debt	Where is it? How fast is it growing? What's the team's relationship with it?
Knowledge distribution	Bus factor for critical systems? Documentation state?

Week 4: Synthesize and Document

Produce the Technical Assessment Document (TAD)—a private document shared only with the CEO initially. Structure:

1. Current State Summary (1 page) — Architecture, team, process at a glance
2. Strengths — What's working well and must be preserved
3. Risks — Technical, people, or process risks ranked by severity and urgency
4. Quick Wins — 3-5 improvements achievable in 30 days with minimal disruption
5. Strategic Recommendations — Larger investments for days 31-100
6. Hiring Plan — Gaps and proposed timeline

Critical: Include strengths. If the TAD is purely critical, you'll demoralize the team when you share recommendations. Acknowledge good work explicitly.

Phase 2: Align (Days 31-60)

Week 5: Share and Align with CEO

Present the TAD to your CEO. The conversation should cover:

• Do they agree with your risk assessment?
• Are your priorities aligned with the business's next 12 months?
• What budget/headcount can you access for the strategic recommendations?
• What's the expectation for your first quarter's deliverables?

After this meeting, you should be able to articulate: "In my first 100 days, I will deliver X, Y, and Z, and begin working toward A and B."

Week 6: Quick Wins Execution

Execute 2-3 quick wins from your TAD. These should be:

• Visible to the team (so they see you taking action)
• Clearly beneficial (nobody argues they were unnecessary)
• Low risk (won't break anything if you're wrong)

Examples of good quick wins:

Quick Win	Timeline	Impact
Fix the slowest CI job	3-5 days	Saves 10 minutes per deploy x 15 deploys/day
Set up on-call rotation (if none exists)	1 week	Stops 2 AM pages going to the same person
Create an incident response runbook	3 days	Reduces MTTR, reduces stress
Implement automated staging deploys	1 week	Removes manual deployment bottleneck
Start weekly engineering all-hands (30 min)	0 days	Transparency, alignment, Q&A

Quick wins earn credibility. Credibility enables bigger changes later.

Week 7-8: Engineering Roadmap

Produce a 90-day engineering roadmap that balances:

• Product delivery (features the business needs)
• Technical investment (debt reduction, infrastructure, tooling)
• Team development (hiring, onboarding, skills growth)

I use a 70/20/10 split as a starting default:

• 70% product delivery
• 20% technical investment
• 10% team development

Present this roadmap to the team. Explain your reasoning. Ask for feedback. Adjust based on input. The goal isn't to have all the answers—it's to show that you have a plan and you're open to collaboration.

Phase 3: Accelerate (Days 61-100)

Week 9-10: Process Improvements

By now you've observed the development process for 8 weeks. You know where the friction is. Introduce 1-2 process improvements:

Problem Observed	Process Improvement	Expected Impact
PRs sit for 2+ days	Review SLA (24-hour turnaround) with buddy system	60% reduction in review time
Unclear priorities mid-sprint	Sprint goal + daily async check-in	30% fewer context switches
Production incidents with no learnings	Blameless post-mortems with action items	Recurring incidents reduced 50%
Architecture debates that never resolve	Lightweight RFC process	Decisions made 3x faster

Important: Introduce process that solves pain the team already feels. Never introduce process prophylactically ("we might need this someday"). If the team doesn't feel the pain, the process will be resented and ignored.

Week 11-12: Hiring Acceleration

If you have open roles (you almost certainly do), your hiring process should be operational by now:

• Job descriptions written and posted
• Interview rubric defined and calibrated
• Interview panel trained on structured interviewing
• Hiring manager (you or an EM you've hired) actively sourcing

CTO hiring priorities in the first 100 days:

Priority	Role	Why Now
1	Engineering Manager (if team > 12)	Frees you from people management to focus on strategy
2	Senior engineer in weakest domain	Reduces bus factor, accelerates that area
3	Platform/DevOps engineer (if none exists)	Unblocks developer productivity

Week 13-14: Establish Cadences

By day 100, you should have these recurring meetings established:

Cadence	Frequency	Attendees	Purpose
1:1s with direct reports	Weekly	You + each report	Coaching, unblocking, feedback
Engineering all-hands	Weekly (30 min)	All engineers	Transparency, wins, priorities
Technical leadership sync	Weekly (45 min)	You + tech leads	Architecture decisions, cross-team
CEO sync	Weekly (30 min)	You + CEO	Alignment, escalations
Sprint review/demo	Bi-weekly	Engineering + product	Celebrate shipped work
Retrospective	Bi-weekly	Teams	Continuous improvement

The 100-Day Scorecard

At day 100, assess yourself honestly:

Dimension	Strong	Adequate	Needs Work
Team trust	Engineers come to you with problems voluntarily	Engineers are professional but guarded	Engineers are avoiding you or withholding
Shipping velocity	Measurably improved (or maintained if it was good)	Stable	Declined during transition
CEO confidence	CEO proactively asks for your input on strategy	CEO is satisfied with updates	CEO is concerned about pace
Technical clarity	Architecture and roadmap documented, team aligned	Plan exists but incomplete	No written plan, direction unclear
Hiring progress	Active candidates in pipeline for critical roles	Job descriptions posted, some interest	Roles still undefined
Quick wins delivered	3-5 visible improvements shipped	1-2 improvements completed	Nothing tangible shipped yet

Mistakes New CTOs Make

Mistake 1: Rewriting everything immediately. Your predecessor's code works. It might not be beautiful, but it serves customers today. Resist the urge to rewrite until you deeply understand why things were built this way.

Mistake 2: Hiring a VP of Engineering in month 1. You don't know what you need yet. Hire a VPE after you understand the team, the culture, and the gaps. A wrong VPE hire costs 6-9 months and damages team trust.

Mistake 3: Promising the CEO a timeline before you've assessed. "We'll rebuild the platform in 6 months" sounds great in your first week. Six months later, when you're 40% done and the team is exhausted, it sounds like failure. Assess first, commit second.

Mistake 4: Ignoring the CEO's actual priorities. The CEO hired you to solve business problems through technology. If they need revenue features and you're spending 60% of capacity on infrastructure, you're misaligned regardless of technical correctness.

Mistake 5: Being invisible to the team. CTOs who disappear into strategy meetings and code reviews lose the team. Be present. Attend standups. Write code occasionally (but don't block others). Celebrate wins publicly.

The One-Page CTO Operating System

By day 100, you should have a one-page document that captures how you operate as a CTO:

• My role: [Technical strategy / People leadership / Execution oversight]
• How I make decisions: [Data-driven with team input / RFC-based / Time-boxed discussion]
• How I communicate: [Weekly all-hands / Written async updates / Open door policy]
• What I expect: [Ownership / Transparency / Continuous improvement]
• What you can expect from me: [Air cover / Clear priorities / Honest feedback / Growth investment]

Share this with your team. It eliminates ambiguity about your leadership style and gives people permission to hold you accountable.

Actionable Takeaways

1. Don't make major changes in month 1. Listen, assess, and document. Earn context before spending credibility.
2. Deliver quick wins in weeks 5-6. Build credibility through visible, uncontroversial improvements.
3. Produce a Technical Assessment Document by day 30. This becomes your strategic foundation for months 2-12.
4. Establish cadences by day 100. Regular communication rhythms are the operating system of a healthy engineering org.
5. Balance showing and doing. Show the team you can be strategic while proving you can still ship. Both build trust in different ways.

Your first 100 days as CTO set the trajectory for your next 3 years. Move too fast and you'll break trust. Move too slow and you'll lose momentum. The playbook above threads the needle—arriving with humility, building with intent, and accelerating with credibility. Follow it, adapt it to your context, and trust the process.