What is a two-pizza team?
Engineering culture and software practice
A two-pizza team is a small group, usually imagined as about six to ten people, that owns a clear product, service or mission with few dependencies on other teams. The name comes from an early-2000s rule attributed to Jeff Bezos at Amazon: if two pizzas cannot feed the team, it is too large. The serious idea is that coordination becomes harder as teams grow, so size, ownership and autonomy have to be designed together.
What this means
The pizza is a memorable measuring device, not a staffing formula. Two large pizzas can feed wildly different numbers of people depending on appetite, crust thickness and whether somebody ordered salad. The useful part of the idea is that a team should remain small enough for its members to understand one another's work, make decisions directly and coordinate without turning every change into a committee exercise.
Smallness alone does not create speed. A seven-person team that needs permission from four departments, depends on six other teams and cannot change the system it supposedly owns is merely a small queue. The two-pizza model works when a small team also has a bounded mission, the skills needed to fulfil it, authority to make ordinary decisions and clear interfaces with the rest of the organisation.
Why it matters
Coordination has a cost that is easy to underestimate because headcount is visible and communication overhead is not. With six people there are 15 possible pairwise relationships. With ten there are 45. With twelve there are 66. Real teams do not exercise every possible connection equally, but the arithmetic explains why adding people can create more meetings, hand-offs, status reporting and opportunities for misunderstanding.
That matters when a business forms a project team, a transformation group or an AI working group. Twelve senior people around a table may bring more expertise than six, but they also bring more calendars, constituencies and approval paths. A smaller working team with a clear decision-maker can often investigate, build and test something while a larger steering group is still finding a suitable Tuesday.
The model also changes how leaders think about organisation design. A firm of thirty people is already large enough to contain several small teams, even if the organisation chart pretends everybody is one happy family. The question becomes where to draw boundaries. Good boundaries let teams move independently. Bad ones create either constant cross-team coordination or isolated silos that optimise their own corner while making the whole business harder to operate.
How it works
Where the term came from
The rule is associated with Jeff Bezos and the early 2000s. Alan Deutschman's 2004 Fast Company profile is often cited as early press coverage of the management idea, although the surviving online version is truncated before the relevant passage. Fast Company published the maxim explicitly in 2006: a team too large to feed with two pizzas was too large. The neat phrase spread because it turned an abstract organisational problem into something anyone could picture.
The underlying reasoning is much older. Frederick Brooks's 1975 The Mythical Man-Month described how larger software efforts incur communication and coordination costs that do not rise neatly in proportion to headcount. J. Richard Hackman's later research on teams likewise emphasised bounded membership, clear direction, an enabling structure, organisational support and coaching. Neither body of work proves that eight people is a universally ideal team size.
The arithmetic is a warning, not a law
For a group of n people, there are n multiplied by n minus one, divided by two, possible pairs. Going from five people to ten therefore does much more than double the number of possible relationships. Each new person can bring useful capability, but also another set of assumptions, work in progress, dependencies and conversations.
Research by Bradley Staats, Katherine Milkman and Craig Fox found what they called the "team scaling fallacy". Across experiments and archival software-project data, people increasingly underestimated the labour required as teams became larger. That is useful evidence for coordination loss, but it should not be stretched into a universal claim that every small team beats every large one. Task type, expertise, familiarity, leadership, tools and how work can be divided all matter.
The sensible conclusion is not "six good, twelve bad". It is to treat team size as an engineering constraint. When a team grows, ask what new coordination burden arrives with each role and whether the extra capability justifies it.
Autonomy has prerequisites
A genuinely autonomous team needs a coherent piece of work to own. That might be an online booking service, an internal data product, a customer-onboarding process or a narrowly defined AI capability. Its members need access to the relevant users and information, authority over day-to-day choices, enough technical and operational skill to make changes, and a way to observe whether those changes work.
The boundary matters as much as the headcount. Teams move quickly when interactions with other teams are predictable. Published APIs, documented data contracts, service expectations and shared platform capabilities can turn repeated negotiation into routine interaction. A famous piece of technology folklore says internal teams were once ordered to communicate only through service interfaces, sometimes retold as an "API mandate". The exact wording and provenance of that story are uncertain, so it is better treated as folklore illustrating the principle than as a historical commandment.
A small team without useful interfaces spends its life arranging hand-offs. A small team without decision rights spends its life seeking permission. A small team missing a critical skill spends its life borrowing people. None of those is autonomy.
Small teams create costs of their own
Splitting work into small autonomous groups can duplicate effort. Several teams may build similar reporting, authentication, deployment or data-handling machinery because sharing it feels slower. Different conventions emerge. Knowledge becomes local. A change that crosses several boundaries can become an integration project.
This is why small-team models usually need strong common infrastructure. Platform capabilities, shared standards and well-maintained interfaces let teams avoid rebuilding plumbing while preserving freedom over the work that differentiates them. The balance is delicate: too little common support creates duplication; too much central control recreates the coordination bottleneck that small teams were meant to escape.
There is also a silo risk. Autonomy means being able to act without constant coordination, not being indifferent to everybody else. Teams still need common organisational goals, shared technical expectations, routes for knowledge exchange and mechanisms for handling work that genuinely spans boundaries.
Examples
A 30-person professional services firm wants to introduce AI into proposal writing. Its first instinct is a 14-person working group representing every department. Instead, it forms an illustrative six-person delivery team with a commercial owner, two regular proposal writers, someone responsible for information security and data handling, a technical practitioner and an operations lead. The wider group supplies constraints and feedback, but does not join every working session. The smaller team has a defined task: redesign one proposal workflow and test it.
An eight-person software team owns a retailer's stock-availability service. It can change the service, deploy it, monitor it and speak directly with the operational users who rely on it. Other teams consume its published interface rather than asking its developers to make bespoke changes for every request. Its small size helps because the ownership boundary is coherent, not because eight is a magical number.
A charity divides a growing digital function into three small groups but gives each one its own separate identity system, reporting conventions and data definitions. Local work initially speeds up, then cross-organisation changes become painful. The problem is not that the teams are too small. The organisation has mistaken independence for isolation and has underinvested in shared platform capabilities and interfaces.
Common misunderstandings
Misunderstanding: A two-pizza team must contain a particular number of people. Correction: the food metaphor deliberately gives a rough upper bound, not a scientifically established optimum. Six to ten is a common interpretation, but the right size depends on the work and the coordination it requires.
Misunderstanding: Smaller teams are automatically faster. Correction: a small team can be extremely slow when its members lack authority, skills, access or usable interfaces. Team size and autonomy have to be designed together.
Misunderstanding: A two-pizza team is another name for Brooks' law. Correction: it is not. Brooks' law concerns the danger of adding people to a late software project. The two-pizza idea concerns steady-state organisation: keeping ownership groups small enough that coordination remains manageable.
Misunderstanding: Autonomous teams should not need anybody else. Correction: autonomy reduces unnecessary dependencies rather than abolishing interdependence. Healthy organisations still share platforms, standards, knowledge and goals. The aim is to make cross-team interaction deliberate and predictable.
Risks and boundaries
The main risk is turning a memorable heuristic into numerology. Research supports the broad proposition that coordination losses grow with team size, but it does not establish one universal number at which teams become ineffective. A skilled twelve-person group with stable membership may outperform a chaotic group of six.
The opposite risk is fragmenting the organisation too aggressively. Small teams can produce duplicated systems, competing standards and local knowledge silos. Some work also genuinely needs broad representation, particularly when several business functions carry meaningful constraints. The answer is not to exclude those voices. It is to distinguish a working team from everybody who needs consultation, review or visibility.
What to do next
Start by giving the team one sentence of ownership. State what product, service, workflow or business problem it is responsible for and what decisions it can make without seeking further approval. If that sentence requires several "and also" clauses, the boundary may already be too broad.
Look at dependencies before headcount. Ask how many other groups the team must wait for to ship an ordinary change. Frequent hand-offs often matter more than whether the group contains seven people or nine.
For an AI initiative, use a small working group with the business knowledge, technical ability and risk awareness needed to test one defined workflow. Keep sponsors and interested departments informed, but do not turn every stakeholder into a permanent team member.
Finally, inspect what several teams repeatedly build or negotiate for themselves. Repeated plumbing is a clue that shared platform support, common standards or a clearer interface could preserve small-team autonomy without multiplying unnecessary work.
FAQs
How many people are in a two-pizza team?
There is no fixed number. Six to ten is a common shorthand, but the useful test is whether the group can coordinate directly and own a coherent piece of work.
Is a two-pizza team the same as an agile team?
No. Agile methods may favour small cross-functional groups, but the two-pizza idea is specifically about team size, ownership, autonomy and coordination overhead.
Why does communication get harder as teams grow?
Every added person creates potential new relationships and coordination needs. Possible pairwise connections increase much faster than headcount, although real teams do not use every connection equally.
Can a two-pizza team depend on a platform team?
Yes. Shared platform capabilities can reduce repeated work and help a small team remain autonomous in its own domain.
Does the model work in a small business?
Yes. A 30-person firm is already large enough to benefit from explicit ownership boundaries, even if employees still know one another personally.
How should the idea be used for an AI project?
Form a small team around one workflow or capability, give it the necessary business and technical skills, and keep wider stakeholders in review roles rather than putting everyone into the working group.