The Ringelmann Effect: The Math of Why Big Teams Ship Less

60-Second Summary

Ringelmann's rope data fits a clean curve: per-person output ≈ initial × (group size)^−0.15 across most coordination tasks.
The drop has two parts: motivation loss (social loafing) and coordination loss (process overhead).
Two-pizza teams (Bezos, ~6–8 people) are the largest size where coordination loss stays under ~25%.
Above 9–10 people, you are mathematically losing more to coordination than you gain from headcount.
Brooks' Law ('adding people to a late project makes it later') is the engineering corollary.

Add a 9th person to your team and you do not get 9 people's output. You get something closer to 6.5 — and you've slowed the original 8 down. The Ringelmann curve has known this for 110 years. Most companies still ignore it.

The curve

100%

per-person output, group of 1

~85%

group of 3

~74%

group of 5

~50%

group of 8 (Ringelmann's original)

Steiner (1972) decomposed Ringelmann's loss into two parts: motivation loss (people pulling less because they can hide) and coordination loss (people pulling at the wrong angle, at the wrong time, on the wrong rope). Both grow with group size. Motivation loss is fixable with visibility; coordination loss is fixable only with smaller teams.

Two-pizza teams, explained

Jeff Bezos' 'two-pizza team' rule (any team that can't be fed by two pizzas is too big) is widely treated as folklore. It is actually the Ringelmann curve. At 6–8 people, coordination overhead is ~20–25% — annoying but survivable. At 10+ people, it doubles. Amazon's internal data, later confirmed by Apptio and Atlassian studies, shows defect rate per engineer rises sharply once teams cross 9.

Team size	Coordination overhead	What it looks like
2–3	<10%	One Slack channel, one decision-maker, ships daily
4–6	~15%	Standups under 10 min, async-friendly, low ceremony
7–9	~25%	Standups bloat to 20 min, sub-tribes form, RFCs emerge
10–15	~40%	Need a dedicated PM/EM just to coordinate, velocity flat
16+	>50%	Mathematical certainty of split or stagnation

Brooks' Law

“Adding manpower to a late software project makes it later.”
— Fred Brooks, The Mythical Man-Month (1975)

Brooks discovered the engineering version of Ringelmann while running IBM's OS/360 project: ramping new hires onto a late team costs more time in mentoring and coordination than the new hires save in output. Every CTO eventually re-derives this the painful way.

Designing team sizes that don't collapse

Default team size: 5 ± 1. This is the sweet spot for almost every knowledge work task.
If a team needs to grow past 8, split it before you hire, not after.
Define each split by clear ownership boundary, not by 'specialty' (no 'frontend team' / 'backend team' — owners of outcomes, not technologies).
Track 'merge requests per engineer per week' over time. If it drops as headcount rises, you've hit Ringelmann.

FAQ

Frequently asked questions

Does this apply to creative work?

Even more so. Diehl & Stroebe (1987) showed brainstorming groups produce 30–40% fewer ideas than the same number of people working alone, then combining results.

What about huge sales teams?

Sales is naturally individual-output, so loafing matters more than coordination loss. But pod structures (5–8 reps per manager) consistently beat 15-person sales rooms.

What if our team is too big right now?

Don't fire — split. Re-clarify ownership, give each pod its own metric, dissolve the umbrella standup.

Takeaways

Per-person productivity drops with team size in a known, measurable curve.
5–7 is the design sweet spot; 9+ is mathematically losing money.
Split before you hire the 9th person.