Every additional member adds strength and costs coordination – a team should be as small as the task allows.
If you make a team bigger, you get two things. You get strength: more working hours and additional skills. And you get costs: more coordination, less effort from each individual and thinner relationships. Both grow along with the team, but not at the same rate.
The team principle in detail
Four steps through the principle: understand, check, connect, apply. Open any topic to read more.
The explanationThe reason lies in the arithmetic.
- The reason lies in the arithmetic.
- The number of possible pairwise connections grows faster than the number of people: with n members there are n(n−1)/2.
- Four people have six connections; eight have twenty-eight.
- Every connection needs looking after.
- On top of that, in a larger group your own contribution is less noticeable, and you feel less supported.
Read closelyWhat the principle says – and what it doesn’t
Every increase in size is a trade-off. With each additional member, ask what they bring and what they cost everyone else.
- It does not say
- That small is always better. The rule is: as many as necessary, as few as possible. The load-bearing part of the core statement is “as the task allows.”
- Strictly speaking
- It names no fixed ideal number. Research finds no size that would be best for every team.
- Applies to
- Output per person, especially in tasks that require close coordination. Larger teams often achieve more in total – just less per person. When the work is easy to divide, a larger team can be faster.
The signs3 signs that the principle is at work · 3 that it is missing
- Everyone knows what the others are working on.
- Every contribution is visible.
- Decisions are made in the meeting, not afterward.
- In meetings a few people talk and the rest listen.
- Subgroups form.
- Effort and duration are routinely underestimated, and nobody notices when someone does less.
The research6 sources: 4 primary studies, 1 review, 1 meta-analysis · 1970–2012 · with research limitations
- low
- moderate
- high
Moderate – the first half of the statement is strongly supported and often replicated; the second is a design rule that follows from it but has not been shown to hold for every type of team.
- 1970J. Richard Hackman & Neil Vidmar
Size and task type both have strong and independent effects. Satisfaction is highest with four to five people; this size, however, is not the best-performing one.
- 1974Alan G. Ingham et al.
Rope pulling with pseudo-groups: performance drops even though nobody else is actually pulling – part of the loss is due to motivation, not coordination.
- 1986David A. Kravitz & Barbara Martin
Reconstruction of Max Ringelmann’s original 1913 paper (data from 1882–1887, pulling and pushing loads). Output per man: 1.00 alone, 0.93 in pairs, 0.85 in threes, 0.49 in a group of eight.
- 2012Jennifer S. Mueller
26 development teams with 238 members: in larger teams, individuals perform worse. The reason is “relational loss” – people feel less supported.
- 2012Bradley R. Staats, Katherine L. Milkman & Craig R. Fox
Two experiments and 594 software projects: the larger the team, the more the workload is underestimated.
- Larger teams often achieve more in total, and for project and management teams a meta-analysis even finds slightly better performance with more members (Greg L. Stewart).
- There is no fixed ideal number.
- Max Ringelmann’s figures come from a simple strength task and are some 140 years old; they can be applied to knowledge work only in principle.
Read more: what the research shows
Research calls these costs process losses: the gap between what a group could achieve and what it actually achieves. The best known is the Ringelmann effect. In the 1880s, Max Ringelmann measured how hard men pulled alone and together; David A. Kravitz and Barbara Martin reconstructed his work. Output per man fell with each additional man, dropping to about half in a group of eight. Alan G. Ingham and colleagues showed that part of the loss is due to flagging effort, not just to coordination. Jennifer S. Mueller found another reason in development teams: in larger teams, individuals feel less supported. Bradley R. Staats, Katherine L. Milkman and Craig R. Fox showed that the larger the team, the more the workload is underestimated.
The originFrom team research · not from John C. Maxwell
- 1970OriginFrom team research
Earliest source: J. Richard Hackman & Neil Vidmar
- 2001For comparison
John C. Maxwell’s The 17 Indisputable Laws of Teamwork contains no law on team size.
The related team principles01 Necessity · 16 Effort · 10 Communication · 05 Diversity
The principle is the counterweight to “Necessity” and is related to “Effort” and “Communication”.
The action steps5 steps: Start with the task, not with the list of people who are interested
- Start with the task, not with the list of people who are interested: What skills and how much working time does it need at a minimum?
- When planning, deliberately build in time for coordination – and the bigger the team, the more. Larger teams underestimate their workload more.
- Divide a large team into small units with a clear mandate if the task can be divided.
- In larger teams, make every contribution visible and make sure everyone has a fixed point of contact. That way you counter flagging effort and thinning relationships.
- Before you add new people to a late project, check whether bringing them up to speed costs more than it yields.
The questions for your team3 questions for your team conversation: If we were starting from scratch today, what is the minimum number of people our task would need?
- If we were starting from scratch today, what is the minimum number of people our task would need?
- How much of our time goes into coordination – and how much of that is due to our size?
- Who on the team makes contributions that the others cannot see?
Take time for one question at your next team meeting. Talk about it openly and note down what you take away from it.
The picture to rememberFive dots in a circle need only a few lines.
- Five dots in a circle need only a few lines.
- With every additional dot, the connections multiply into a tangle – until the team shrinks back to its clear, small shape.
What the Team Principle of Size looks like in practice
More People, More Delay
When IBM’s OS/360 operating system falls behind schedule, project manager Frederick P. Brooks Jr. adds more staff – and later concludes that this is exactly what made the delay worse. The first version ships on March 31, 1966, almost two years after the announcement; in 1975 this becomes Brooks’s Law in the book “The Mythical Man-Month.”
Two Pizzas Have to Be Enough
In the early 2000s, fast-growing Amazon is losing more and more time to coordination. The rule attributed to Jeff Bezos: no team should be so big that two pizzas can’t feed it – as a guideline, the company cites fewer than ten people.
Eight Pull Like Four
Between 1882 and 1887, the French agricultural engineer Max Ringelmann measures how hard men pull alone and together. If one person’s pulling force is set at 1.00, each person pulls 0.93 in a pair, 0.85 in a group of three and only 0.49 in a group of eight.
