The first time I heard the two-pizza rule quoted back to me in a planning meeting, it was being used to justify keeping a team at four people while they owned three production services, an on-call rotation, and a compliance audit deadline. Someone had read that Amazon likes teams small enough to be fed by two pizzas, and had decided that meant smaller is always better. The four engineers were drowning. Two pizzas would have been a cruel joke; those four could barely feed a backlog.
I have run engineering orgs in regulated payments for long enough to have strong feelings about this rule, and most of them are complicated. The rule is not wrong. It is just quoted by people who have never thought about what actually makes a team small, and who mistake headcount for the thing that matters.
What the rule was actually solving
The two-pizza idea was never really about pizza, and it was never really about six people versus eight. It was Bezos trying to kill the meeting. He was attacking coordination cost: the tax you pay every time a decision needs more heads to nod before it moves. When a team is small, that tax is low. Everyone fits in one conversation, everyone holds the same context, and you do not need a program manager whose entire job is keeping fourteen people pointed the same direction.
That is the real target. Not size for its own sake, but the number of communication paths. A team of five has ten pairwise links between people. A team of ten has forty-five. The cost does not grow with headcount; it grows with headcount squared. Once you see it that way, the pizza is just a rough proxy for "small enough that the graph of who-talks-to-whom stays sane."
So when I evaluate a team today, I do not count people first. I count how many decisions require a meeting, how many Slack threads sprawl across three channels before anything ships, and how often an engineer says "I was blocked waiting to hear back from someone." Those are the symptoms the rule was written to prevent. Team size is one cause among several.
The number was never the point
I have seen a genuinely great team of nine, and I have seen a dysfunctional team of four. The four-person team failed because two of them were juniors who needed constant review, one was a staff engineer who kept getting pulled into other teams' incidents, and the fourth was the only person who understood the ledger reconciliation code. On paper it was a two-pizza team. In practice it was one and a half engineers with three full-time distractions.
Meanwhile the nine-person team worked because it had a clear owner, tight interfaces, and a habit of splitting into pairs that could move without asking permission. They were technically over the line. Nobody cared, because the coordination cost was low regardless of the raw count. The rule tells you nothing about either of these teams until you look at how the work is actually shaped.
Headcount is the input people can measure, so it is the input people optimize. That is exactly why it is the wrong one to fixate on.
The scope has to fit too
Here is the part the rule leaves out entirely, and the part that burned my four-person team. You can staff a team perfectly and still crush it if the scope it owns is too large to hold in a shared mental model. Two pizzas of people cannot own eight pizzas of surface area.
In payments this shows up constantly, because the domains are unforgiving. A team that owns card authorization, settlement, chargebacks, and merchant onboarding is not one team no matter how few people you put on it. Those are four different failure modes, four different sets of regulators to satisfy, and four different 2am pages. The engineers cannot hold all of it in their heads at once, so they context-switch, and context-switching in a domain where a mistake means real money moving to the wrong place is where incidents come from.
When I inherited that overloaded team, the fix was not hiring. It was cutting scope. We moved chargebacks and disputes to a separate team, drew a hard API contract between them, and suddenly the original four had a job they could actually reason about. They shipped more in the next quarter than they had in the previous three combined, with the same people.
Cognitive load is the real constraint
The framing that finally made this click for me came from the Team Topologies people, who argue that a team's real limit is cognitive load, not headcount. A team can only own as much as it can hold in its collective head. Everything else is noise on top of that one constraint.
Once you accept that, the design questions change. You stop asking "how many people" and start asking things that actually predict outcomes:
- How many distinct domains does this team have to be expert in? More than two and you are asking for shallow knowledge everywhere.
- How many other teams must it coordinate with to ship a normal feature? If the answer is more than two or three, the boundaries are wrong, not the size.
- How much of the codebase does a new hire need to understand before they can be trusted on call? If that is six months, the team owns too much.
- How often does the team get interrupted by work that is not theirs? Every interruption is scope you did not draw on purpose.
None of those questions mention pizza. All of them predict whether a team will thrive better than a raw count ever will. I would take a team of eight with low cognitive load over a team of four with high load every single time, and it is not close.
The on-call math nobody mentions
There is a floor to team size that the two-pizza crowd rarely talks about, and it is dictated by the pager. If a team owns a production service with a 24/7 obligation, you need enough people to run a humane rotation. My rule is you do not put anyone on a rotation shorter than one week in six. That means a minimum of five or six engineers before you even discuss feature work, because someone is always on leave, someone is always ramping, and someone always quits at the worst possible time.
I watched a three-person team try to hold a critical payments service once. The rotation was one week on, one week off, forever. Within four months one of them burned out and left, which made it one week on, one week off for the survivors, which is a resignation letter waiting to be written. We had optimized for a small team and accidentally engineered attrition. The two-pizza rule, taken literally, would have applauded us right up until the team ceased to exist.
So my floor is not "as small as possible." It is "small enough to coordinate cheaply, large enough to survive its own operational load." Those two constraints usually meet somewhere between six and nine people for a team with real production duties. Below six you are fragile. Above nine you are paying the coordination tax whether you feel it yet or not.
When smaller genuinely wins
I do not want to sound like I am against the rule, because for a whole class of work it is exactly right. Early-stage products, prototypes, anything where the biggest risk is moving too slowly rather than breaking something expensive: put three sharp people on it and get out of their way. Speed of learning beats operational resilience when you have nothing in production to protect yet.
The mistake is applying that same instinct to a mature, regulated, load-bearing system and expecting it to hold. The thing that makes a three-person prototype team fast, the total absence of process and coordination, is the exact thing that gets you a compliance finding when the system is moving other people's money. Context determines whether small is a feature or a liability. The rule pretends context does not exist.
Splitting is harder than growing
Teams do not stay the right size on their own. Scope creeps in quietly. A service the team owns gets a new integration, then a new region, then a compliance requirement, and one day you look up and the standup runs forty minutes because there are twelve people and nobody can hear about all of it. The two-pizza rule is at its most useful here, as a tripwire: when you feel the standup getting long, the size is telling you something.
But splitting a team is genuinely painful, which is why people avoid it until it is overdue. You have to draw a line through a codebase and a set of relationships that grew together, decide who goes where, and accept that some knowledge only one person holds is about to become a dependency across a new boundary. I have split teams too late more often than too early, and every time the cost of waiting was higher than the cost of the awkward transition would have been. The signal I trust most is when engineers start specializing informally, when two of them only ever touch the settlement code and the others never do. That informal split is the org telling you where the real seam is. Draw the boundary there before the pager forces you to.
How I actually size a team now
My process is boringly practical. I start from the scope, not the people. I write down every service, domain, and obligation I want a team to own, and I ask whether one group of engineers can genuinely hold all of it in their heads and stay expert. If not, the scope is wrong, and no amount of clever headcount math fixes a bad boundary.
Then I size to that scope with the on-call floor in mind, and I add a margin for the fact that people take vacations and have lives. I would rather run a team at seven that can absorb a surprise than a team at five that shatters the first time someone is out for a week. The efficiency you gain from cutting that margin is imaginary; you pay it back with interest the first bad month.
The last check is the coordination one. If shipping a routine change requires sign-off from three other teams, I have not built a two-pizza team, I have built a bottleneck with good PR. That is a boundary problem masquerading as a size problem, and I have learned to smell the difference.
Order the pizza, keep the thinking
If you are going to keep the two-pizza rule in your head, keep it as a question rather than an answer. Not "is this team small enough to feed with two pizzas," but "does this team's scope fit in the heads of the people I have, and can they survive owning it at 2am." The pizza was always a stand-in for those harder questions, and somewhere along the way people started ordering the pizza and skipping the thinking. Feed your teams whatever you like. Just make sure you sized them for the work, the pager, and the regulators, and not for a metaphor about lunch.