Bezos Two-Pizza Teams
Bezos's two-pizza rule: any team should be small enough to be fed by two pizzas. The number isn't the point — the principle is that team size scales communication overhead exponentially while output scales linearly (or worse). At 6-8 people, a team can move with one shared brain. At 15+ people, the team spends most of its energy coordinating with itself. Amazon evolved the principle into 'single-threaded teams' (later 'single-threaded leadership'): one team, one leader, one mission, end-to-end ownership of one customer outcome. Bezos credited two-pizza teams as the structural innovation that lets Amazon ship Type 2 decisions at startup velocity at $600B+ in revenue. Communication channels grow as n*(n-1)/2 — a 6-person team has 15 connections, a 12-person team has 66, a 24-person team has 276. Each new person added past 8 adds more friction than throughput.
The Trap
Companies copy the team size and miss the autonomy. A two-pizza team that needs 5 sign-offs for any decision is just a regular team in a smaller room. The actual lever is end-to-end ownership: the team must own the customer outcome, the metric, the budget, and the technology stack. When teams own only their slice (eng team here, design team there, PM team somewhere else), you've recreated the dependency hell that two-pizza teams were designed to escape. The other trap: leaders who 'shrink' teams without changing the work — same scope of project, fewer people, same coordination overhead because half the work depends on other teams.
What to Do
Apply the principle in three steps: (1) Cap team size at 8-10 people. If a team needs more, split it into two teams with separate missions. (2) Give each team a SINGLE clearly-named customer outcome (e.g., 'reduce checkout abandonment' not 'work on the checkout team'). (3) Audit dependencies — if a team can't ship without 3 other teams' approval, the team isn't autonomous and the size is irrelevant. The hardest step is (4): give each team a budget and the authority to make Type 2 decisions without escalation. If every decision still routes through the VP, you have small teams but central decision-making — the worst of both worlds.
Formula
In Practice
Bezos introduced two-pizza teams at Amazon around 2002 as the company crossed 5,000 employees. By 2020, Amazon had thousands of two-pizza teams operating across AWS, retail, devices, and Prime Video. Each team owns a specific customer outcome end-to-end. AWS's structure of microservice teams (each owning a single service from architecture to on-call) is the canonical implementation. AWS ships ~3,000 features per year as a result — more than most $1B+ companies ship in a decade. Source: 'Working Backwards' by Colin Bryar and Bill Carr (2021).
Pro Tips
- 01
When a team grows past 10, the right move is almost always to split it — not to add a coordinator. Adding a coordinator solves the symptom (too many meetings) but preserves the dependency. Splitting forces clean ownership boundaries.
- 02
Give each two-pizza team ONE primary metric. Not three, not five — one. When a team has multiple metrics, leadership negotiates priorities for them and autonomy collapses. One metric = the team can decide tradeoffs themselves.
- 03
Single-threaded leadership matters more than team size. Amazon's 2014 evolution (from two-pizza teams to single-threaded leaders) recognized that the leader's attention is the rate-limiter. A leader split across 3 missions is the bottleneck, regardless of team size.
Myth vs Reality
Myth
“Two-pizza teams only work for engineering”
Reality
Amazon applies the principle across functions: marketing teams, recruiting teams, finance teams. The principle is about coordination overhead, not engineering specifically. A 15-person marketing team coordinating across 4 product lines has the same dysfunction as a 15-person eng team — too many channels, too much reconciliation, no one owns the outcome.
Myth
“Smaller teams ship slower because each person has more work”
Reality
The opposite. Per-person output is HIGHER on small teams because coordination overhead is lower. Brooks's Law from 1975 (adding manpower to a late project makes it later) is the same mechanism: each new person adds more channels than throughput past a point. Small teams ship faster despite (because of) less manpower.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Scenario Challenge
You're VP of Engineering. You have a 14-person team building the company's core platform. Velocity is dropping and meetings have ballooned. The team is asking for 4 more engineers. What's the right move?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
Optimal Team Size for Autonomous Execution
Software product teams; Brooks's Law and Amazon two-pizza dataOptimal (Two-Pizza)
5-8 people
Workable
9-12 people
Coordination-Heavy
13-20 people
Dysfunctional
> 20 people
Source: Brooks, The Mythical Man-Month + Amazon (Working Backwards)
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Amazon Web Services
2006-Present
AWS is structured as thousands of two-pizza teams, each owning a single microservice end-to-end: architecture, deployment, on-call, customer support. The team that built S3 owns S3 — they decide what to ship, when, and how. Type 2 decisions never leave the team. Type 1 decisions (architectural shifts, new pricing models) escalate. The result: AWS ships ~3,000 features per year and operates with the velocity of a startup at $90B+ in revenue.
Estimated Two-Pizza Teams
5,000+
Features Shipped/Year (AWS)
~3,000
AWS Revenue (2024)
$90B+
% of Decisions Made Inside Team
~95% (per S-team)
AWS proves the principle scales infinitely. The structure isn't 'small company that grew' — it's a $90B business that ships like a startup because the unit of execution is a 6-8 person team with full ownership of a customer outcome.
Spotify
2012-2018
Spotify popularized 'squads' (8-person two-pizza-style teams) and 'tribes' (collections of squads). The model worked beautifully at $300M revenue. As Spotify scaled past 1,000 engineers, the squad model broke down — squads owned features but depended on shared platforms, infra, and data teams. Engineers reported in interviews that squads spent 40-60% of time on cross-squad coordination, not feature work. Spotify quietly evolved past the pure squad model around 2018. The lesson: small teams alone aren't enough — you need true end-to-end ownership.
Squad Size
~8 people
Engineering Headcount (2018)
~1,800
Cross-Squad Coordination Time
40-60% (per internal interviews)
Model Evolved
~2018
Spotify's experience is the canonical warning: small teams without genuine autonomy recreate the coordination problem at the inter-team level. The two-pizza principle requires ownership AND size, not size alone.
Decision scenario
The Growing Team Decision
You're VP of Product. Your flagship product team is 14 people: 8 engineers, 3 designers, 2 PMs, 1 data scientist. The CEO has approved hiring 6 more people. Your team lead wants to add them all to the existing team.
Current Team Size
14 people
Current Communication Channels
91
Approved Hires
6
Velocity Trend
Declining
Decision 1
If you add 6 to the existing team you'll have 20 people and 190 communication channels (109% increase from current). If you split into two teams of 10 you'll have 45 + 45 = 90 channels total. The decision is whether to optimize for 'one team identity' or 'execution velocity.'
Add all 6 to the existing team — keep the team identity, the rituals, and the shared contextReveal
Split into two 10-person teams: identify two distinct customer outcomes, give each team a clean slice, name single-threaded leaders, distribute the 6 new hires across both teams✓ OptimalReveal
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Bezos Two-Pizza Teams into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Bezos Two-Pizza Teams into a live operating decision.
Use Bezos Two-Pizza Teams as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.