Scaling Teams: When to Split, When to Hire a Manager

Org design is the most under-practiced skill in tech leadership. Most companies inherit their shape from history — early hires kept their reports as the company grew — and then wonder why information stops flowing at ~80 people. The fix is deliberate: choose spans, choose layers, and split or merge teams when the operating signals say so.

Spans, layers, and shape

Two numbers determine the shape of your org: span of control (reports per manager) and number of layers (CEO to IC). Get these right and information flows; get them wrong and you either drown managers or starve ICs of context.

Healthy spans by role type (rough guide; research varies)

Manager role	Healthy span	Why
Engineering Manager (senior team)	5–8	Deep 1:1s, technical context, growth coaching
Engineering Manager (junior team)	4–6	More coaching load per person
Sales Manager	6–10	Repeatable process, dashboards
Support / Ops Manager	8–15	Process-driven, shift-based
Senior Director / VP	4–7 (managers of managers)	Strategic load, fewer direct reports

5–8

Typical EM span

Below 4 = under-leveraged; above 9 = 1:1s die

5–7

Layers at ~1000 ppl

Each layer adds latency and distortion

~150

Dunbar number

Real ceiling on stable social knowledge per person

Layers are a tax, not a feature

Every extra layer adds communication latency, information distortion, and political surface area. Aim for the fewest layers that keep spans healthy. Amazon's 'two-pizza team' and Spotify's squad model are both attempts to flatten by splitting.

Signals a team is too big

1:1s being cancelled or shrinking to 15 minutes
Standup taking >15 minutes or splitting into side-channels
Manager can't name what each report shipped last week
Two distinct 'sub-cultures' or working styles within the team
Hand-offs between people in the same team feel like cross-team work
Decision-making slowing — meetings to schedule meetings
On-call or escalations consistently routed to 1–2 senior ICs

Three signals + a 3-month trend = split now

Don't wait for a crisis. By the time the team is openly dysfunctional you've already lost months of productivity and probably one or two senior people.

How to split cleanly

A repeatable team-split playbook

1
Define the cut
Split by surface area / ownership, not by personalities. ‘Checkout vs Catalog' beats ‘Anna's people vs Ben's people'.
2
Name the new charters
Each new team gets a 1-page charter: mission, ownership, success metrics, on-call surface. Written before the split announcement.
3
Pick managers first
Confirm who leads each new team before announcing membership. Avoid the political vacuum.
4
Place people based on work, then preference
Walk each person through what they'll own. Honor strong preferences where possible but be explicit when you can't.
5
Run for 90 days, then retro
Most splits need adjustment at the 90-day mark. Plan it in.

Hire a manager vs grow one

When to promote vs hire externally

Grow internally when…

Strong tech-lead candidate exists who wants the role
Team's domain is deep and external onboarding would be painful
Cultural continuity matters more than new playbooks
You have bandwidth to coach the new manager for 6+ months

Hire externally when…

No willing internal candidate, or the team has rejected the obvious ones
You need a new playbook (e.g., shipping speed, performance management)
Team has had multiple recent failures of internal promotion
Stage shift requires experience the company hasn't built yet

The ‘player-coach' trap

Promoting your strongest IC into management often loses you your strongest IC and gives you a mediocre manager. Make the new role real — drop the IC load to <30% within 6 months — or don't make the move.

Running a humane reorg

Write the ‘why' in one paragraph before anything else — if you can't, don't reorg
Pre-socialize with affected managers 2 weeks before broadcast
Announce in this order: managers → individuals 1:1 → team meetings → all-hands
Publish charters, manager assignments, and the FAQ on day 1
Hold an open Q&A within 48 hours
Commit to no further structural changes for 90 days (unless safety/legal)
Run a post-mortem at 90 days with the new managers

Reorgs cost ~1 quarter of velocity

Plan for it. Communicate the cost. The worst reorgs are the ones leaders pretend will be ‘seamless' — people aren't fooled, and trust erodes.

Anti-patterns

Reorging to solve a performance problem (have the conversation instead)
Creating teams around individuals you can't say no to
Splitting without changing on-call / ownership — the team is now ‘2 teams' on paper only
Hiring a senior manager into an unclear scope ‘to figure it out'
Stacking layers to create titles instead of widening spans
Quarterly reorgs — destroys trust and institutional memory
Reorg announcements with no charters or success metrics

References

Will Larson — An Elegant Puzzle (org design) — Lethain
Camille Fournier — The Manager's Path — O'Reilly
Spotify Engineering — Squads, tribes, chapters (and the retraction) — Spotify Engineering
Amazon — Two-pizza teams — AWS Executive Insights
McKinsey — Spans and layers research — McKinsey
Dunbar (1992) — Group size and social cognition — Journal of Human Evolution

Written by Pawan Joshi. Sources cited inline. Last updated 2026-05-17.