The myth of Amazon’s 2-pizza teams

How Amazon dealt with problems that decreased team speed — and it was not the team sized that mattered the most.

How Amazon dealt with problems that decreased team speed — and it was not the team sized that mattered the most.

In their book “Working Backwards: Insights, Stories, and Secrets from Inside Amazon”, Amazon old-timers Colin Bryar and Bill Carr discuss the concept of “2-pizza teams”. The idea behind 2-pizza teams is that they should be small enough that they can be fed with two pizzas, with the goal to increase product development speed.

The phrase has become synonymous with Amazon’s approach to product development, but they reveal that Amazon doesn’t emphasize this any longer:

We all agreed at the outset that a smaller team would work better than a
larger one. But we later came to realize that the biggest predictor of a team’s success was not whether it was small (…)

The reason for this is that Amazon discovered that the size of the team wasn’t the main factor delaying initiatives — one of the key problem was dependencies on other teams:

To address team dependency issues, they mention that the normal businesses try to improve communication between teams, so they work more effectively. But Amazon went on the complete opposite direction. Communication between teams was considered a “bug” rather than a “feature”. They didn’t want to improve it, but eliminate it, so teams could move faster without dependencies.

In order to reduce dependency and inter-team communication needs, Jeff Bezos sent out the famous API mandate to the whole company:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!

Imagining getting an email from the CEO saying you will be fired if you don’t expose your APIs. I am pretty sure that was a very effective way to shift the culture 😅

This mandate was essential to the creation of AWS (APIs were already there and prepared to be exposed to the outside world), but the main goal was to reduce dependencies between teams. You didn’t need to talk to a team to interface with their features, you could just use their API. This had a significant effect in unblocking teams.

Another issue that contributed to slowing things down was decision dependency, in the form of leaders having to sign-off of stuff. Bryar and Carr wrote:

Many companies find themselves struggling against their own bureaucratic drag, which appears in the form of layer upon layer of permission, ownership, and accountability, all working against fast, decisive forward progress.

To combat this, Amazon introduced the concept of the “single-threaded leader” and “single-threaded teams”, which were leaders and teams who had a single area of responsibility. This approach ensured that each team had a clear leader who was fully accountable for its success and had no other distractions, which further increased the speed of product development. “The best way to fail at inventing something is by making it somebody’s part-time job”.

If you notice, it’s almost as if Amazon got the concept of microservices and introduced it in the organization structure. An example of a single-threaded leader responsibility would be the Amazon affiliates program or the digital books business, this last one with likely smaller single-threaded teams to further focus the product development work.

In conclusion, the 2-pizza teams get all the fame, but the real game changers for Amazon were reducing team dependencies and having single-threaded leaders/teams that had no other responsibilities. (tweet this)

This is a cautionary tale for product people trying to implement stuff that worked on other companies: sometimes it just didn’t really work, sometimes the company already moved on from it or the practice was never widespread (Hello, Spotify Model) and/or the practice requires an organizational culture that your company doesn’t share. It’s necessary to think about the principles behind a practice, instead of just blindingly following it.