What Is a Two-Pizza Team?
A two-pizza team is a small, long-lived group equipped to fully own software for a specific business capability. The term was popularized by Amazon to describe its software organization, and it carries a deceptively simple name for a set of principles that go well beyond headcount.
The moniker comes from the rule that a team should be no larger than two pizzas can feed. In practice, this usually lands between five and eight people, though some experienced leaders put the practical upper bound closer to fifteen. The core idea behind keeping the group small is cohesion: smaller teams form tighter working relationships and communicate more naturally.
Outcome Orientation Over Activity Orientation
Size alone doesn’t make a two-pizza team effective. Just as important is the team’s focus. These teams are outcome oriented, not activity oriented. Rather than organizing along skill lines like databases, testing, or operations, they take on every responsibility needed to support their customers. That includes figuring out what users need, turning ideas into working software, and iterating as those needs evolve.
This structure minimizes hand-offs between teams, which shortens cycle-time — the span between a feature idea and code running in production. A true two-pizza team also deploys and monitors its own software, and takes direct responsibility for production outages, including off-hours support. That principle is often summarized as “you build it, you run it.”
Long-Lived Business Capability Teams
Because they center on a customer need, two-pizza teams are meant to be durable. They are business capability centric: as long as the capability remains active, the team keeps supporting and enhancing it. This stands in contrast to project-oriented teams, which disband once software is declared “done.” Two-pizza teams treat their work as a long-lived product, which is why they are often called product teams.
Maintaining that breadth of skills and ownership doesn’t happen in a vacuum. Two-pizza teams thrive when supported by a well-constructed software platform. Smaller organizations may lean on commercial offerings like a cloud platform; larger organizations often build internal platforms to make cross-team collaboration easier. Team Topologies offers a useful framework for thinking about the kinds of teams and interactions needed here, referring to these groups as stream-aligned teams.
Teams don’t operate in isolation. To be effective, business-capability-centric teams must expose their capabilities to peers, typically through thoughtfully designed APIs. This responsibility is easy to overlook, but if neglected it leads to rigid information silos.
Organizational Impact on Architecture
Organizing people around business capabilities has a direct effect on software structure, thanks to Conway's Law. Components built by two-pizza teams need well-controlled interactions with their peers, with clear APIs between modules. This line of thinking heavily influenced the rise of microservices, though that’s not the only viable approach. Well-structured components inside a monolithic runtime can often be a better fit.
