A return to two-pizza culture | All Things DistributedA return to two-pizza culture<br>June 30, 2026 &bull; 1830 words

When I joined Amazon, Jeff had an idea: no team should be so large that it couldn&rsquo;t be fed by two pizzas. In those early days, some teams were so small that one pizza would&rsquo;ve been enough to get the job done. But it was never really about feeding hungry engineers. We could&rsquo;ve just as easily said a “six sandwich team”, but sandwiches don&rsquo;t evoke the same imagery as pizza. Pizza is what you order when you and your peers are crowded around the whiteboard late into the evening.<br>We wanted to keep teams small enough so that everyone in the room knew what everyone else was working on, without requiring meetings. Each member of the team owned the product. You had the autonomy to make decisions with as little bureaucracy as possible. You were empowered to move fast, to experiment, and to not be afraid of failure. If the decision was reversible, you didn&rsquo;t need permission to make it. You made it, you learned from it, and if it was wrong, you reversed it. The cost of a wrong reversible decision is almost always lower than the cost of making that decision slowly.<br>As our customer base grew, so did the number of our teams. When you go from three services to over two hundred, you do not get to keep the same organizational structure. It’s simple physics: as systems grow, so does their entropy. Each service requires owners, and owners need to coordinate with the teams whose services they depend on. Org structures become layered, dependencies multiply, and approval cycles appear where none existed before. Suddenly, a team that used to own a problem end-to-end now needs alignment across multiple teams before they write a single line of code. At some moment, the inertia of any growing company begins to work against the very culture that made it successful. This doesn&rsquo;t necessarily mean the quality of the product will suffer, but unless you fight it, it means your speed of delivery will decrease.<br>Along with the two-pizza approach to manage team size, we used a unique approach to define our products—working backwards from the customer. I wrote about this back in 2006:<br>The Working Backwards product definition process is all about fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:<br>Start by writing the Press Release<br>Write a Frequently Asked Questions document<br>Define the customer experience<br>Write the user manual

We’ve achieved remarkable successes working backwards, and have solved real problems for millions of customers using feats of engineering that still amaze me to this day. Our teams are still sized around our two-pizza model. They still move fast and break things, but they wait until they have fully defined the problem and the entire business line clearly understands how they’ll solve it together.<br>But there’s a shift happening in our industry, and I keep hearing stories across Amazon that are challenging me to think a bit differently about the process of bringing products to life. If you look at the four steps above, what they have in common is deep thinking about the problem space, then writing about it. Getting the idea out of your head and onto paper is how you hone the idea. You poke holes in it, discover what you don’t know, and share it with your peers to arrive at a shared understanding of what will be built. It’s hard work to write a crisp document, and nearly impossible if you don’t have clarity of mind about the customer problem you want to solve. But there’s another very deliberate reason we use writing at Amazon: writing allows anyone to build a product because it doesn’t require you to know how to code. A product manager, a UI designer, a business analyst, anyone with a well-written idea and compelling argument could define what gets built next.<br>But what happens when anyone with an idea can sit down with a coding agent and produce a functional shell of a product in a single evening?<br>In late January 2025, a handful of our scientists were talking among each other and realized they&rsquo;d all been thinking about the same problem space independently. How do you give an agent memory that persists? How do you let multiple agents coordinate without a central bottleneck? How do you keep humans in control while the system scales? They needed an operating system for agents. They decided to get into a room together for a few days and see what they could come up with.<br>Thomas Delteil, who is a principal scientist on our Amazon Quick team, had been concerned by the pace at which good ideas were dying. The cycle of proposing an idea, waiting for discussion, building a proof of concept, benchmarking it, seeking visibility for it, then waiting again for the next round of approvals was killing ideas before they ever reached a single customer. So when the conversation turned to what they could...