Human brains can maintain only so many stable social relationships. Robin Dunbar proposed a ceiling: roughly 150 people. Beyond that, you know names and faces but cannot track who did what, who owes whom, or how everyone connects. The number comes from the correlation between neocortex size and group size across primates; humans sit at the high end. The 150 is not a hard wall — it varies with individual capacity and culture — but it predicts where coordination breaks down. Below the limit, gossip and norms suffice. Above it, you need hierarchy, roles, and formal process.
Dunbar's layers sit inside the 150: about 5 intimate contacts, 15 close friends, 50 good friends, 150 meaningful contacts. Each layer takes more cognitive load. Companies that stay under 150 can often avoid HR departments and org charts. Once they cross the threshold, miscommunication spikes and "we used to all know each other" becomes a refrain. The strategic implication: design teams and org units with the limit in mind. Split before you hit the ceiling, or accept that you will need structure to substitute for direct relationship tracking.
Military units, commune sizes, and effective workgroups across history cluster around 150–200. Dunbar's number explains why startups feel different at 20, 80, and 300. At 20, everyone is in one layer. At 80, you are approaching the edge. At 300, without deliberate design, the organisation runs on rumours and silos. The model does not say growth is bad. It says growth without redesign is costly. Scale requires replicating the small-group feel in pods, squads, or divisions that each sit under the cognitive limit.
Section 2
How to See It
Dunbar's number shows up when coordination quality drops as headcount crosses a band around 150. People stop knowing who is responsible. Decisions slow. New hires feel anonymous. Look for the point where "everyone used to be aligned" gives way to "we need a reorg."
Business
You're seeing Dunbar's Number when a company passes ~150 employees and introduces formal job descriptions, RACI matrices, and all-hands that no longer feel like a single room. The shift is not bureaucracy for its own sake — it is substituting process for the relationships that no longer scale. Teams that stay under 150 often delay or skip these structures.
Technology
You're seeing Dunbar's Number when open-source projects or internal platforms struggle once contributor count exceeds a few dozen. Maintainers can no longer remember who owns what. Communication moves from chat and casual contact to tickets and docs. The 150 limit applies to "people you can coordinate with" as much as to friends.
Investing
You're seeing Dunbar's Number when a portfolio company's execution quality degrades after a growth spurt. The CEO could previously align the whole team in a room. Post-150, alignment requires layers, and culture becomes something you "manage" rather than something everyone shares. Due diligence should ask how the org is structured relative to this threshold.
Markets
You're seeing Dunbar's Number when a brand or community loses coherence as it scales. Niche communities thrive at 100–200 members; beyond that, subcultures form and the "we" fragments. Platform design that assumes infinite scalability of trust often hits Dunbar-related limits in practice.
Section 3
How to Use It
Decision filter
"Before adding headcount, opening a new office, or merging teams, ask: are we already at or past the point where everyone can hold the network in their head? If yes, add structure first — clear ownership, smaller units, explicit norms — then add people."
As a founder
Keep teams and sub-units under ~150. Use the two-pizza rule or similar to cap meeting size, but also cap the size of the group that is supposed to "know each other." When you scale, replicate small units (squads, tribes, divisions) rather than one giant pool. Hire for managers who can maintain coherence within their Dunbar-sized unit. The mistake is growing headcount while assuming alignment will persist. It won't. Design the org so each person's "meaningful 150" maps to their actual working set.
As an investor
Use Dunbar's number to interpret execution risk at scale. Companies that have crossed 150 without explicit org design often have hidden coordination debt. Ask how the leadership team stays aligned with the front line, how many people report into a single manager, and whether culture is documented or lived. The best scaling companies treat 150 as a design constraint, not a surprise.
As a decision-maker
When forming task forces, committees, or project teams, keep the core coordination group under the limit. Large initiatives can have many contributors, but the subset that must understand each other's roles and relationships should stay small. Use hierarchy and clear interfaces so that each layer only needs to coordinate within its own Dunbar-sized band.
Common misapplication: Treating 150 as a magic number. The exact value varies; some studies suggest 100–250 depending on context and individual difference. The principle is the ceiling effect, not the digit. Use it to anticipate where coordination will break, not to justify a specific headcount cap.
Second misapplication: Ignoring the layers inside 150. The 5–15–50–150 structure means that even in a 50-person company, only a subset are in each other's "inner" layers. Design for the layer that matters for the decision at hand — intimate for trust, 15 for execution, 150 for culture.
Bezos institutionalised the two-pizza rule: no team should be so large that two pizzas cannot feed it. The rule is a proxy for Dunbar's number — keep coordination units small enough that people can know each other. Amazon's growth relied on replicating small, autonomous teams (two-pizza teams) rather than scaling one giant org. The result: many Dunbar-sized units under one company, with interfaces between them rather than one undifferentiated 150+ pool.
Netflix's culture of "context not control" and high talent density assumes that small, aligned teams can move fast. Hastings has emphasised keeping teams small and intentional so that everyone can operate from shared context. As Netflix scaled, the design was to preserve that dynamic within units rather than to assume one culture could stretch across thousands without structure.
Section 6
Visual Explanation
Dunbar's Number — Cognitive limit on stable social relationships (~150). Inner layers: 5 intimate, 15 close, 50 good friends. Beyond 150, coordination requires hierarchy and process.
Section 7
Connected Models
Dunbar's number sits at the intersection of organisation design, coordination, and scaling. The models below either define similar limits (span of control, two-pizza rule), describe how to scale past the limit (team of teams, hierarchy), or relate to the trust and network that the number constrains.
Reinforces
Span of Control
Span of control is the number of direct reports a manager can effectively oversee. It is usually cited as 5–10. Dunbar's number is the larger band of people one can hold in mind. Both imply that growth beyond a threshold requires adding layers and structure rather than just adding people to one flat group.
Reinforces
Two Pizza Rule
The two-pizza rule caps team size so that two pizzas feed the team — roughly 6–10 people. It is a practical application of keeping coordination units below the inner Dunbar layers. Small teams stay within cognitive limits; scaling happens by adding more such teams.
Leads-to
Team of Teams
Team of teams describes organising as a network of small, empowered units rather than one hierarchy. Each unit can sit under Dunbar's limit; the challenge is coordination between units. Dunbar's number explains why the units must stay small.
Leads-to
Hierarchical Organisation
Beyond 150, hierarchy is the standard way to preserve accountability and alignment. Each layer manages a Dunbar-sized (or smaller) set of reports. The model does not say hierarchy is bad — it says it becomes necessary once you pass the relationship ceiling.
Section 8
One Key Quote
"The figure of 150 seems to represent the maximum number of individuals with whom we can have a genuinely social relationship, the kind of relationship that goes with knowing who they are and how they relate to us."
— Robin Dunbar
The limit is about genuine social relationship — knowing who someone is and how they relate to you. That is the resource that runs out. Names in a directory or followers in a feed do not count. Strategy that assumes infinite scalability of "team" or "community" without redesign runs into this ceiling.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Design orgs with the limit in mind. The worst scaling failures happen when leadership assumes that what worked at 50 will work at 200. It won't. Once you cross the band around 150, alignment and trust need to be deliberately designed — smaller units, clear ownership, and rituals that substitute for "everyone knowing everyone."
Replicate small units instead of inflating one unit. The answer to growth is not one bigger team. It is more teams of the same cognitive size, with clear interfaces between them. Amazon's two-pizza teams and similar constructs are implementations of this. Each unit stays under the limit; the company scales by multiplication.
Use the layers. The 5–15–50–150 structure is a design tool. Who needs to be in your 5 (true trust)? Your 15 (execution alignment)? Your 150 (culture carrier)? Allocate communication and process to the right layer. Don't treat the whole company as one undifferentiated mass.
Investors should ask how the company handles the transition. When a portfolio company crosses 100–150 people, does it have an explicit org design? Are managers trained to run Dunbar-sized units? Companies that hit the limit without preparation often stall on execution or culture; those that plan for it scale more reliably.
Section 10
Summary
Dunbar's number is the cognitive limit on stable social relationships — about 150 people. Below it, groups can coordinate through direct relationship and norms; above it, hierarchy and process are required. The inner layers (5, 15, 50) define how much depth you can maintain. Founders and leaders should design teams and org units to stay under the limit and scale by replicating small units rather than by growing one unbounded group.
Practical organisational model for scaling coordination: small, empowered teams with shared context. Aligns with keeping each team under Dunbar-sized limits.
Amazon's principle that teams should be small enough to be fed by two pizzas — a direct application of constraining team size to preserve coordination and ownership.
Tension
Network Effects
Network effects reward scale: more users, more value. But the social layer that creates trust and coordination is bounded by Dunbar's number. Platforms that rely on "community" often hit a ceiling where the sense of belonging fragments; growth beyond that requires different design (e.g. subcommunities, algorithms).
Reinforces
Trust
Trust is built and maintained through repeated interaction and shared context — exactly what the inner Dunbar layers represent. Beyond 150, you cannot maintain that depth with everyone. Trust at scale requires institutionalised reliability (process, brand, contracts) rather than personal knowledge.
