The CTO's First 100 Days at a Growth-Stage Startup

Day 1: You Inherit Everything

You walk into a growth-stage startup as the new CTO. The previous technical lead left. The codebase has 18 months of technical debt. The team of 12 engineers is shipping features but morale is low. The CEO expects you to "fix engineering" while maintaining feature velocity. Welcome to the job.

The biggest mistake new CTOs make: trying to change everything at once. The second biggest: not changing anything for months while "learning the landscape."

Days 1-14: Listen and Map

Week 1: Understand the people
  → 1:1 with every engineer (30 min each)
    Questions:
    - "What's the biggest thing slowing you down?"
    - "What would you fix if you had a week with no deadlines?"
    - "What's working well that I shouldn't change?"
    - "Who's the person you go to when you're stuck?"
  
  → 1:1 with every stakeholder (product, sales, support)
    Questions:
    - "What do you need from engineering that you're not getting?"
    - "When engineering ships something, is it what you expected?"
    - "Where do you feel we're falling behind competitors?"

Week 2: Understand the systems
  → Map the architecture (whiteboard session with senior engineers)
  → Review the deployment process (watch a deployment happen)
  → Read the last 10 incident reports
  → Check the monitoring dashboards (if they exist)
  → Review the last quarter's sprint velocity and predictability

The Assessment Framework

Score each area 1-5 (1 = critical, 5 = healthy):

People:
  [ ] Team morale and retention risk
  [ ] Skill gaps vs. what's needed
  [ ] Hiring pipeline quality
  [ ] Management layer effectiveness

Process:
  [ ] Deployment frequency and reliability
  [ ] Incident response maturity
  [ ] Sprint predictability (estimate vs. actual)
  [ ] Code review quality and turnaround

Technology:
  [ ] System reliability (uptime, error rates)
  [ ] Technical debt severity
  [ ] Security posture
  [ ] Scalability headroom

Product:
  [ ] Feature delivery speed
  [ ] Quality of shipped features
  [ ] Alignment with business goals
  [ ] Customer-facing bug rate

Days 15-30: Quick Wins

Don't wait 100 days to show impact. Fix the obvious stuff immediately:

Common quick wins (pick 2-3):
  → Fix the deployment pipeline if it takes > 30 minutes
  → Add monitoring/alerting if it doesn't exist
  → Unblock the team's top complaint from 1:1s
  → Cancel unnecessary meetings (protect maker time)
  → Establish a clear on-call rotation if there isn't one
  → Fix the one bug that support complains about daily

Why quick wins matter:
  → Builds credibility with the team ("this person actually does things")
  → Builds trust with the CEO ("engineering is improving")
  → Shows your leadership style through action, not presentations

Days 30-60: Set the Foundation

Now you have enough context to make structural changes:

Engineering principles (write these down, share them):
  → Example: "We ship small changes frequently, not big changes rarely"
  → Example: "We measure everything before optimizing anything"
  → Example: "We build for the next 12 months, not the next 5 years"
  
  Keep it to 5-7 principles. More than that and nobody remembers them.

Technical strategy (1-page document):
  → Where are we today? (honest assessment)
  → Where do we need to be in 12 months?
  → What are the 3 biggest technical risks?
  → What investments do we need to make?
  → What trade-offs are we making and why?

Team structure:
  → Are teams organized around products or technologies?
  → Do teams have clear ownership boundaries?
  → Is the team/manager ratio sustainable (5-8 per manager)?
  → Do we need to hire? For what roles specifically?

Days 60-90: Execute the Plan

Priority 1: Reliability
  → If the system is unstable, nothing else matters
  → Invest in monitoring, alerting, and incident management
  → Set an SLA target and track it weekly

Priority 2: Developer productivity
  → CI/CD pipeline improvements
  → Local development environment setup
  → Documentation for onboarding

Priority 3: Technical debt reduction
  → Pick the ONE area causing the most pain
  → Allocate 20% of sprint capacity to tech debt
  → Track and celebrate progress

Priority 4: Hiring (if needed)
  → Define the roles you actually need
  → Build a hiring process that respects candidates' time
  → Your first 2-3 hires set the culture — choose carefully

Days 90-100: Reflect and Adjust

Check yourself:
  → Did morale improve? (re-run the pulse survey)
  → Is deployment frequency up?
  → Is incident count down?
  → Does the CEO feel informed and confident?
  → Do engineers feel heard?
  → Are you spending time on strategy or just firefighting?

Adjust:
  → What assumptions from Week 2 were wrong?
  → What's taking longer than expected?
  → Where do you need help (hire, consultant, advisor)?
  → What should you stop doing?

The Communication Cadence

With the CEO: Weekly 30-min 1:1
  → Engineering health metrics
  → Progress on key initiatives
  → Risks and asks (budget, hiring, timeline changes)

With the team: Biweekly all-hands (30 min)
  → What shipped, what's next
  → Celebrate wins publicly
  → Be transparent about challenges

With individual engineers: Weekly or biweekly 1:1s
  → Career growth conversations
  → Remove blockers
  → Give and receive feedback

With product: Weekly planning sync
  → Upcoming priorities
  → Technical constraints and trade-offs
  → Shared understanding of timeline

The first 100 days set the trajectory for your entire tenure. Listen before you prescribe. Fix the obvious before tackling the complex. Build trust through action, not authority. And remember: you were hired to improve things, not to prove you're the smartest person in the room.