Amazon runs on "two-pizza teams": if two pizzas can't feed the team, it's too big. It sounds like a cute rule. The productivity data behind it is not cute at all. Across hundreds of projects, small teams consistently shipped faster, cheaper, and with dramatically fewer defects than large ones.
Key Takeaways
- Research on 491 projects found teams of 3–5 people the most productive, with the shortest schedules and lowest cost (QSM/Putnam).
- Adding staff cut schedule ~30% but raised cost 350% and defects 500% in one analysis of 390 applications (QSM).
- The cause is coordination overhead and the extra defects big teams generate.
- Amazon's "two-pizza team" rule is this research turned into a napkin heuristic.
What the Data Says
Doug Putnam analyzed 491 completed projects and found that for medium-sized systems, teams of three to five people hit the highest productivity, the shortest schedule, and the lowest cost (QSM/Putnam). Bigger wasn't better; it was worse on every axis that matters. A separate look at 390 applications drove it home: adding staff shortened the schedule by about 30%, but cost rose 350% and the larger teams produced 500% more defects. On small projects, large teams cost three times more and delivered twice the defects; on large projects, four times the cost and three times the defects (empirical findings on team size).
Those defects aren't a side note; they're the mechanism. More people generate more bugs, which trigger more find-fix-retest cycles, which eat the schedule savings the extra headcount was supposed to buy.
| Small team (3–5) | Large team | |
|---|---|---|
| Productivity | Highest | Lower |
| Cost | Lowest | 3–4x higher |
| Defects | Fewest | 2–3x more |
| Coordination | Simple | Heavy |
Why Small Teams Win
It comes back to communication. A team of 5 has 10 communication channels; a team of 12 has 66. Every added person multiplies the coordination and the surface area for misunderstanding, and past a point the team spends more time syncing than shipping. Small teams also have clearer ownership, tighter feedback, and less diffusion of responsibility. Amazon's two-pizza rule is a shorthand for keeping a team below the size where coordination starts eating the gains.
A Concrete Version
A founder staffs a big initiative with a single 14-person team to "move fast." Standups run 40 minutes, the planning doc has twelve opinions in the margins, and two engineers quietly build the same thing because coordination slipped. Reorganize into three focused teams of four to five, each owning a clear slice, and the same people ship faster, because each team is back under the coordination ceiling. Nothing changed but the shape.
The Honest Counterpoint
"Small teams win" has limits. Some problems are genuinely too big for five people, and the answer there isn't one giant team; it's several small teams with clean interfaces between them, the whole idea behind Team Topologies. And a team can be too small: a solo developer or a pair carries real bus-factor risk. The research doesn't say fewer people is always better. It says there's a sweet spot around three to five per team, and the failure mode most companies actually hit is teams that are too big, not too small.
What This Means for Hiring
The lesson isn't "hire fewer engineers." It's "hire the right ones and keep teams small." A small team of strong senior engineers will out-ship a large team of mixed ability, because you get the output without the coordination tax, which is why we focus on senior, rigorously vetted placements rather than volume. When you do need more capacity, add it as another small, focused team, not by inflating one team past the coordination ceiling. See available engineers.
Frequently Asked Questions
What's the ideal software team size?
Research on 491 projects found three to five people most productive, with the shortest schedules and lowest cost. Amazon's "two-pizza team" rule captures the same idea.
Why are large teams less productive?
Communication channels grow with the square of team size, and large teams generate more defects, which trigger more rework. One analysis found large teams cost 3–4x more and shipped 2–3x the defects.
How do I scale beyond five people?
Don't inflate one team; split into several small teams with clear ownership and clean interfaces between them. That keeps each team under the coordination ceiling.
Can a team be too small?
Yes. A solo developer or pair carries bus-factor risk, one person leaving can stall the work. The sweet spot is roughly three to five, but the more common mistake is teams that are too big.
The Bottom Line
The two-pizza rule isn't folklore; it's what the productivity data shows. Teams of three to five ship faster, cost less, and produce fewer defects than large ones, where coordination overhead and extra bugs cancel out the added headcount. Keep teams small, and scale by adding teams, not bodies.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
