Scaling a team from 5 to 25 engineers is one of the most common growth challenges for an EM, and one of the most common interview questions. The transition is non-linear — a 5-person team and a 25-person team are different organizations. The structures, communication patterns, and your role as manager all change.
The inflection points
Three key transitions in this growth path:
- 5 to 8 engineers: you can still be in every standup. Communication is verbal and ambient. Your role is hands-on coding + team lead.
- 9 to 14 engineers: you can no longer be in every standup. You hire leads. Communication shifts to written. Your role is delegate + amplify.
- 15 to 25 engineers: you split into sub-teams with their own leads. You manage managers (or lead-ICs). Your role is strategy + organization design.
The 5-to-8 transition
At this size, your team is intimate. Mistakes:
- Holding the team back by being a single point of context
- Being in every meeting — you become a bottleneck
- Failing to write things down (verbal context evaporates as you grow)
What to do:
- Designate a tech lead even if formally unassigned
- Begin writing decisions and rationales (RFCs, design docs)
- Create on-call rotation if you have not yet
The 9-to-14 transition
You feel the strain here. Mistakes:
- Trying to attend every standup or design review
- Hiring without a coherent team structure plan
- Not promoting your strongest IC to lead
What to do:
- Promote 1–2 ICs to leads. Give them concrete responsibilities — code review for a sub-area, sprint planning, on-call coordination.
- Split daily standup into smaller groups
- Build a shared knowledge base — Notion, Confluence, internal wiki
- Run skip-levels — your direct reports cannot tell you everything
The 15-to-25 transition
The team is now an organization. Mistakes:
- Trying to scale the same operational rhythm
- Avoiding the split into sub-teams because it feels political
- Hiring more managers without clarifying scope and decision rights
What to do:
- Split into 2–3 sub-teams of 5–9 engineers each
- Hire or promote sub-team leads — formal manager titles or staff-level ICs
- Define inter-team interfaces — what each team owns, what depends on others
- Establish a leadership cadence — your weekly meeting with sub-team leads
- Run quarterly planning, not just sprint planning
The communication-pattern shift
At 5: you are in every conversation.
At 25: you are in roughly 5% of conversations. The other 95% happen via your leads, in written docs, and async tools. Your skill at writing memos, structuring meetings, and asking the right questions becomes more important than your skill at writing code.
Hiring planning
Plan the headcount in chunks. A common pitfall is to ramp from 8 to 20 in one quarter and overwhelm the existing team’s capacity to onboard. Better:
- Hire 2–3 per quarter
- Pause if onboarding is suffering
- Onboarding bandwidth is your binding constraint, not budget
Frequently Asked Questions
When should I hire my first manager?
Around team size 12–15. Earlier and there is not enough management work for them; later and you are overwhelmed.
Should I split by feature area or by engineering layer (frontend/backend)?
Mostly by feature area — keeps full-stack ownership and reduces handoffs. Layer-based splits make sense at 50+ engineers.
How do I avoid silos as we grow?
Cross-team rotations, shared tooling investment, regular cross-team demos, and a culture of opening PRs across team boundaries.