Scale an Engineering Team from 5 to 20
24 weeks · 5 milestones
Scale an engineering team from 5 to 20 people — the hardest management transition in software. The skills that made you effective at 5 will actively harm you at 20. Every milestone here is about replacing personal relationships with systems, and replacing your presence with documented authority.
Milestone map
Milestone map
0 of 5 done
Current milestone
Diagnose what breaks when you add headcount
2–3 weeks. The interviews take one week. Writing the document takes another. The most important bottleneck is usually the one that takes longest to name — build in time to sit with the findings before writing.
Before hiring anyone new, audit your current team's systems for what will break at 2x headcount. Interview every current team member individually — ask what slows them down, what information they cannot find, and what decisions they have to wait for. Write a scaling risk document that names the top five bottlenecks ranked by severity. This document becomes your hiring and process roadmap.
Proof required
Share your scaling risk document (minimum 500 words). It must name at least five specific bottlenecks with: what the current state is, what breaks when the team doubles, and what the proposed fix is. Share anonymised notes from your team interviews — at least one direct quote per person. Write 200 words on the bottleneck that surprised you most and why you did not see it before the audit.
What gets checked
- Five bottlenecks are named specifically — not 'communication could be better' but 'decisions about API design require my sign-off and I am the bottleneck for 6 engineers; at 12 engineers this blocks two squads simultaneously'
- Interview notes contain at least one direct quote per team member — paraphrases do not count; the actual words reveal what the team member was willing to say, not what the manager heard
- Proposed fix for each bottleneck is a system, not an event — not 'improve communication' but 'create an architecture decision record (ADR) process so API decisions are documented and do not require my real-time input'
Design the team structure for 20 engineers
Hire five engineers without lowering the bar
Build a team that works when you are absent
Deliver a major project through two sub-teams
Sign in to start this outcome and track your progress publicly.
Sign in to start this outcome →