In the early 1990s, British anthropologist Robin Dunbar made a curious observation while studying primates.

He found a correlation between the size of a primate’s neocortex (the brain region handling social relationships) and the size of its social group.

Chimps, with smaller neocortices, lived in groups of ~50.

Gorillas: ~30.

Humans, with the largest neocortices, should be able to maintain stable social relationships with about…

150 people.

That’s it. Not 500. Not 1,000. 150.

And this number shows up everywhere throughout human history and modern organizations.

The Historical Evidence

Dunbar looked at anthropological data:

Hunter-Gatherer Tribes:

  • Average size: 100-200 people
  • Optimal: ~150

Neolithic Villages:

  • Agricultural settlements: 150-200 people
  • When they grew larger, they split

Roman Military:

  • The basic unit: Centuria = 100 soldiers (actually ~80)
  • Doubled to 160 with support staff
  • This structure lasted centuries because it worked

Hutterite Communities:

  • Religious farming communities
  • Average colony size: 90-120
  • Rule: Split when community reaches 150
  • They’ve been doing this successfully for 400+ years

Gore-Tex (W.L. Gore & Associates):

  • Manufacturing company, $3B+ revenue
  • Policy: No facility larger than 150 people
  • When a plant reaches 150, they build a new one
  • One of the most innovative companies in America

The pattern is clear: 150 is a natural limit for cohesive human groups.

Why 150?

Dunbar’s theory: Our brains can only maintain about 150 stable relationships.

A “stable relationship” means you know:

  • Who they are
  • How they relate to you
  • What your recent interactions were
  • Their social context

Beyond 150, relationships become superficial, formal, or forgotten.

The Social Layers:

Dunbar identified concentric circles of relationships:

5 people - Closest relationships (family, best friends) 15 people - Good friends (see regularly) 50 people - Close friends (casual socializing) 150 people - Meaningful relationships (you’d invite to your wedding) 500 people - Acquaintances (recognize face and name) 1,500 people - People you can recognize

But only 150 are stable, trust-based relationships.

What Happens Beyond 150?

When groups exceed Dunbar’s Number, cohesion breaks down:

1. Trust Erodes

Small groups: Trust is personal Large groups: Trust requires bureaucracy

Team of 50:
"I know Bob. He's reliable."

Team of 500:
"Who's Bob? Check his performance reviews."

2. Communication Overhead Explodes

Communication channels = n(n-1)/2

10 people: 45 channels
50 people: 1,225 channels
150 people: 11,175 channels
500 people: 124,750 channels

Beyond 150, you can’t maintain direct relationships. You need hierarchy, process, bureaucracy.

3. Informal Structures Fail

Small group:
"Hey, let's just ask Alice, she knows."

Large group:
"Submit a ticket. We'll route it through the proper channels."

4. Subgroups Form

Beyond 150, the group fractures into tribes:

  • Sales vs Engineering
  • Frontend vs Backend
  • Office A vs Office B

These subgroups often work against each other.

5. Rules Replace Relationships

Small company:
"Use good judgment"

Large company:
427-page employee handbook

Modern Examples

Startups That Hit the Wall:

Many startups thrive until ~150 employees, then struggle:

  • Communication slows
  • Culture dilutes
  • Early employees feel disconnected
  • “It doesn’t feel like the early days anymore”

This isn’t failure. It’s hitting Dunbar’s Number.

Amazon’s Two-Pizza Rule:

Jeff Bezos famously said teams should be small enough to feed with two pizzas (~8-10 people).

Why? Trust, communication, and cohesion break down in larger teams.

Spotify’s Squad Model:

  • Squads: 6-12 people (autonomous teams)
  • Tribes: Collection of squads, max ~150 people
  • Chapters: Cross-squad groups by specialty

The 150-person tribe limit is deliberate, based on Dunbar’s research.

Military Units:

Modern militaries still use ~150-person units:

  • US Army Company: 100-200 soldiers
  • Marine Corps Company: 150-200 Marines

Why? Cohesion under stress requires personal relationships.

In Software Engineering

Tech companies repeatedly rediscover Dunbar’s Number:

The Startup Scaling Crisis

Stage 1 (10-50 people):
- Everyone knows everyone
- Informal communication works
- Fast decision-making
- High trust

Stage 2 (50-150 people):
- Communication gets harder
- Need some process
- Still mostly trust-based
- Subgroups forming

Stage 3 (150-500 people):
- Dunbar's Number exceeded
- Formal processes required
- Bureaucracy emerges
- Trust becomes transactional
- "It's not like it used to be"

Engineering Team Breakdown

Team of 10:
- Everyone knows the codebase
- Ad hoc collaboration
- Fast iteration

Team of 50:
- Need code owners
- PRs take longer
- Some siloing

Team of 200:
- No one knows the whole system
- Teams stop talking to each other
- Politics emerge
- "Not my problem" mentality

Open Source Projects

Core contributors often ~50-150
Beyond that:
- Need formal governance
- Hierarchical decision-making
- BDFL (Benevolent Dictator for Life)
- Or: Project forks/dies

Remote Work Challenges

Remote teams hit Dunbar limits faster:
- Harder to build relationships
- No hallway conversations
- Trust develops slower
- Dunbar Number effectively lower

How to Scale Beyond 150

You can’t avoid Dunbar’s Number. But you can design around it:

1. Divide into Smaller Units

Don't: One 500-person engineering org
Do: Five 100-person divisions
- Each has autonomy
- Each has identity
- Cross-division coordination via APIs/contracts

2. Maintain Small Teams

Amazon: Two-pizza teams
Spotify: Squads of 6-12
Gore-Tex: Facilities of <150
Key: Small team = high trust

3. Use Hierarchy (But Wisely)

Beyond 150, you need:
- Clear reporting structures
- Defined decision-making authority
- Formal communication channels
But: Keep front-line teams small

4. Build Intentional Culture

Small companies: Culture emerges
Large companies: Culture requires active maintenance
- Written values
- Rituals
- Storytelling
- Explicit onboarding

5. Create Cross-Functional Pods

Instead of: Frontend team, Backend team, QA team
Try: Product pods with all functions
Each pod <150 people (preferably <50)
Pods coordinate through APIs

6. Accept That It Will Change

0-50: Family
50-150: Tribe
150-500: Organization
500+: Corporation

Each stage requires different:
- Communication
- Decision-making
- Culture maintenance
- Leadership style

The Unintended Consequences

When you ignore Dunbar’s Number:

1. Culture Dilution

Early employees: "It's not the same company"
New employees: Never experienced the original culture
Result: Culture is whatever happens, not what you intended

2. Empire Building

Managers judged by headcount
Incentive: Grow team beyond optimal
Result: Bloat, inefficiency, politics

3. Communication Breakdown

Too many people to know personally
Result: Email, Slack, meetings to coordinate
Overhead: 50%+ of time

4. Innovation Slowdown

Small team: "Let's try this!"
Large team: "We need to get buy-in from 7 teams"
Result: Risk aversion, slowness

5. Us vs. Them

Subgroups form beyond 150
Each optimizes for itself
Result: Internal competition, not collaboration

The Deeper Lesson

Dunbar’s Number reveals a fundamental constraint: Human brains haven’t evolved for large-scale societies.

For 200,000 years, humans lived in groups of ~150.

We’ve built civilizations of millions, but our social brain hasn’t scaled.

We compensate with:

  • Hierarchy
  • Bureaucracy
  • Rules
  • Technology

But these are workarounds, not solutions.

The natural human organization is ~150 people.

Everything larger requires artificial structures.

The Programmer’s Perspective

As engineers, we scale systems all the time:

  • Databases
  • Servers
  • Networks

But organizations don’t scale like code.

You can’t just “add more people” and expect linear productivity.

Brooks’s Law: “Adding manpower to a late software project makes it later.”

Why? Communication overhead, coordination, Dunbar’s Number.

The best engineering organizations accept this:

  • Keep teams small
  • Clear ownership
  • Loose coupling between teams
  • Treat teams like microservices (APIs, not shared state)

You can have 1,000 engineers. But structure them as ten 100-person divisions, not one 1,000-person org.

Scaling people isn’t like scaling servers.

Key Takeaways

  • ✅ Humans can maintain ~150 stable relationships
  • ✅ Groups beyond 150 require formal structures, hierarchy, bureaucracy
  • ✅ Trust, communication, and cohesion break down beyond 150
  • ✅ Solution: Divide into smaller autonomous units
  • ✅ Organizations don’t scale like code; design for human limits

Gore-Tex has a simple rule: When a facility reaches 150 people, build a new one.

Not because they want to. Because they have to.

Beyond 150, they’d need:

  • HR policies
  • Formal communication
  • Bureaucracy
  • Hierarchy

Instead, they keep facilities small. And it works.

The next time your company hits 150 people and things start feeling different—that’s not a bug.

That’s Dunbar’s Number.

You can’t fix it by hiring a VP of Culture or writing better Slack guidelines.

You fix it by dividing.

Because 150 isn’t a suggestion.

It’s a biological limit.

And no amount of process will change the size of your neocortex.