Playbook
AdvancedHRFounderCEO

Dunbar's Number and Refactoring Team Topologies: The 5/15/50/150 Rule of Scaling

Anthropology says humans cap out at 150 stable relationships — and 50, 15, and 5 are also magic numbers. Why your team feels broken at 23 people, 52 people, and 153 people, and the refactor pattern that fixes it.

10 min read Updated 2026-05-21
60-Second Summary
  • Robin Dunbar (1992) proved humans can sustain ~150 stable relationships, with sub-tiers at 5, 15, 50.
  • Teams and orgs collapse predictably as they cross each threshold — not because of bad management, but because of cognitive ceilings.
  • Apply Team Topologies: split before you hit the threshold, not after.
  • Amazon's 'two-pizza team' (~5–9 people) maps cleanly to the inner Dunbar circle.
  • HR's job is to schedule team refactors as proactively as engineering schedules code refactors.

Almost every founder describes the same set of crises: it broke at 8, broke again at 25, broke spectacularly at 50, and the wheels came off at 150. They blame their hiring, their tooling, their offsite. Dunbar would say: stop blaming yourself. You hit a biological ceiling.

The 5/15/50/150 hierarchy

Dunbar, 1992 — replicated across hunter-gatherer societies, Roman military centuries, Hutterite settlements, Gore-Tex factories, and modern tech orgs.
LayerSizeRelationship qualityOrg analogue
Support clique~5Daily, deep, total trustPod / squad / 'two-pizza team'
Sympathy group~15Weekly, high contextTeam / chapter
Affinity group~50Monthly, recognisableDepartment / tribe
Active network~150Quarterly, name + faceBusiness unit / company

What breaks at each threshold

  • Crossing 5–9: pair-programming and informal sync stop working; you need a daily standup.
  • Crossing 15: you need a tech lead and explicit ownership boundaries.
  • Crossing 50: tribal knowledge becomes a liability; you need an org-wide handbook.
  • Crossing 150: nobody knows everyone; politics emerges as a side-effect of cognitive limits, not character.
150
Dunbar's number
Hill & Dunbar, Human Nature, 2003
+33%
communication overhead growth per 50-person increment
Brooks' Law extended, Putnam 2010
9
max productive team size in Amazon 'two-pizza' rule
Amazon engineering norms

The team refactoring playbook

  1. At 80% of any Dunbar threshold, plan the split. Do not wait until you hit it.
  2. Split along value streams (see the Conway article), not along seniority or geography.
  3. Each new sub-unit owns its full stack: hiring, on-call, roadmap, comp recommendations.
  4. Preserve weak ties — cross-team rituals (hack weeks, demo days, internal conferences) keep the 50/150 layer alive.
  5. Re-measure team health (psychological safety, eNPS, citizenship) 60 days after the split. Expect a temporary dip, then improvement.
Refactor cadence
  • 5–9: keep as is
    Two-pizza team, no formal structure needed
  • 10–15: add a tech lead
    Explicit ownership, one daily standup
  • 20–50: split into 2–3 sub-teams
    Independent sprints, shared rituals
  • 50–150: form a tribe with a director
    Chapter leads, handbook, demo days
  • 150+: spin a new business unit
    Independent OKRs, dedicated platform support

Takeaways

  • Team breakage at certain sizes is biology, not bad management.
  • Refactor teams proactively, not reactively.
  • Pair Dunbar (the people math) with Team Topologies (the system math) for clean scaling.
Written by Pawan Joshi. Sources cited inline. Last updated 2026-05-21.