Sean Rivard-Morton

Management

Two Pizza Teams - Business Lore

Author

Sean

Date Published


Beyond Two Pizzas: Why Even Smaller Teams Build Better Software

The “two pizza team” is software engineering lore at this point. Popularized by Amazon, the idea is simple: if a team can’t be fed with two pizzas, it’s too big. In practice, that puts the ideal team size around 6 or 7 people—a small, autonomous group meant to move quickly and build independently.

It’s catchy. It sounds reasonable. And it’s wrong—at least now.

The two pizza team was a response to the bloat and bureaucracy of early 2000s enterprise engineering. But in 2025, we’re facing a different set of challenges. The industry has shifted. Our tools are better. Our expectations are higher. The friction isn’t in getting people to coordinate—it’s in having too many people in the first place.

It’s time to challenge the two pizza rule.


The Problem With Seven

Let’s start with a bit of math: in a team of n people, the number of communication paths is n(n-1)/2. That means:

A 3-person team has 3 paths.

A 5-person team has 10.

A 7-person team? 21.


That’s 21 potential lines of communication to maintain, clarify, and coordinate. And while not every path is “hot” all the time, the cognitive load scales with each new team member.


More people means more:


Status updates

Design reviews

Slack channels

Cross-checks before merging code


In short, it means more meta-work—the work around the work.

And then there’s the issue of ownership. In a 6–7 person team, roles tend to blur. Someone handles support tickets. Someone else starts acting like a PM. Someone picks up DevOps. But rarely is this clarified or intentional—it’s just a byproduct of team size. You end up with overlapping responsibilities, duplicated efforts, and slow decision-making.

Sometimes, a 7-person team functions more like three 2-person sub-teams plus one person who isn’t sure what they should be doing.


The Case for Even Smaller Teams

Let’s talk about the real sweet spot: 3 to 4 people.

Why smaller teams win:


1. Lower Coordination Overhead

With just a handful of people, everything becomes simpler:

You don’t need a meeting to align—conversations happen organically.

There’s no need for complex project tracking—everyone knows what’s going on.

Standups become 2-minute check-ins, not 30-minute updates.


2. Clear Ownership

Smaller teams naturally divide scope. You know who’s handling infrastructure, who’s owning the product direction, who’s maintaining quality. This clarity creates accountability and faster feedback loops.


3. Increased Trust and Shared Context

With fewer people, relationships deepen. Trust builds faster. There’s less miscommunication, and shared mental models emerge quickly. You’re not coordinating across silos—you’re co-creating in real time.


4. More Momentum, Less Drag

Small teams can afford to move fast without tripping over each other. Fewer blockers. Less waiting. More iteration. In an industry that prizes agility, small teams don’t just survive—they thrive.


But What About…

You might hear some objections. Here are the most common:

“What about resilience? You need more people for coverage.”

You don’t need more people—you need better systems. Redundancy can come from documentation, pair programming, and smart handoffs. Overstaffing to avoid gaps is just fear-driven design.

“Won’t people burn out with so much responsibility?”

Burnout doesn’t come from ownership—it comes from friction. Bureaucracy. Useless meetings. Wasted effort. Smaller teams can feel more energizing because they eliminate the noise and give people space to do meaningful work.

“Isn’t this premature optimization?”

If anything, it’s a correction. Most teams fail not because they had too few people—but because they had too many, doing too little, with too little clarity.


Culture Eats Capacity

Team size doesn’t exist in a vacuum. Small teams only work when the culture supports them. That means:

Trust in the team to make decisions.

Autonomy over how they work.

Alignment with company goals without micromanagement.

When companies grow, they often bloat teams to fix problems they should solve with clarity, not headcount. Culture should scale, not just coordination.


The Real Rule of Thumb

Two pizzas might have been a useful ceiling—but it shouldn’t be your target. In a world of better tools, remote-first workflows, and asynchronous collaboration, you can build more with less.

The most powerful teams today? They don’t need two pizzas.

They just need one.