![\"Where\u2019s](\"\/images\/wheres-the-pizza-header.jpg\")
<\/p>\n<\/p>\n
When I joined Amazon, Jeff had an idea: no team should be so large that it couldn\u2019t be fed by two pizzas. In those early days, some teams were so small that one pizza would\u2019ve been enough to get the job done. But it was never really about feeding hungry engineers. We could\u2019ve just as easily said a \u201csix sandwich team\u201d, but sandwiches don\u2019t evoke the same imagery as pizza.\u202fPizza is what you order when you and your peers are crowded around the whiteboard late into the evening.<\/p>\n
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.\u202fYou 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\u2019t 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.<\/p>\n
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\u2019s 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.\u202fOrg structures become layered, dependencies multiply, and approval cycles appear where none existed before.\u202fSuddenly, 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\u2019t necessarily mean the quality of the product will suffer, but unless you fight it, it means your speed of delivery will decrease.\u202f\u202f<\/p>\n
Along with the two-pizza approach to manage team size, we used a unique approach to define our products\u2014working backwards from the customer. I wrote about this back in 2006<\/a>:<\/p>\n 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:<\/p>\n Start by writing the Press ReleaseWrite a Frequently Asked Questions documentDefine the customer experienceWrite the user manual<\/p>\n We\u2019ve 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\u2019ll solve it together.\u202f\u202f<\/p>\n But there\u2019s 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\u2019t know, and share it with your peers to arrive at a shared understanding of what will be built. It\u2019s hard work to write a crisp document, and nearly impossible if you don\u2019t have clarity of mind about the customer problem you want to solve. But there\u2019s another very deliberate reason we use writing at Amazon: writing allows anyone to build a product because it doesn\u2019t 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.<\/p>\n 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?<\/p>\n In late January 2026, a handful of our scientists were talking among each other and\u202frealized they\u2019d 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.\u202fThey decided to get into a room together for a few days and see what they could come up with.<\/p>\n Thomas Delteil<\/a>, who is a principal scientist on our Amazon Quick team<\/a>, 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 build if they stopped waiting for permission, Thomas spent the entire night using Kiro<\/a> to build the first prototype of what would become Amazon Quick Desktop.\u202fWhen he demoed it the next day, the first question from the team was \u201chow do I get this on my laptop right now?\u201d and the second was \u201cwhat can I help with?\u201d Within hours of first seeing it, the project had an owner for the activity feed, an owner for memory, an owner for the knowledge graph, and an owner for the agentic harness.<\/p>\n Within a week, Swami Sivasubramanian<\/a>, our VP of Agentic AI, saw the prototype and gave the team his full support. Three engineers joined. By the second week, they had a software development manager and a few more engineers, reaching a roughly even split between science and engineering. They were deliberate about not scaling too fast. Each person who was brought on was selected because they had a specific skill, and they had to adapt to a culture that was a complete departure from how the broader organization operated. They were expected to own a problem and deliver with autonomy,\u202fand ownership meant the same thing it has always meant at Amazon: you build it, you own it.\u202f<\/p>\n Leo Ohannesian<\/a>, the product manager recruited to join the Quick team five days into the effort, had spent years working in organizations that started with a PRFAQ, would go through review cycles, secure funding, assign owners, and set timelines. On this early team, there was none of that. Switching to a model where a small group of senior people were fully trusted to make the right decisions produced a velocity he\u2019d never experienced in his career.<\/p>\n A big driver of what made this pace possible was that every person on the team used the product as their primary AI assistant from day one. Thomas was building it the way he wanted an assistant to be, and anything he didn\u2019t like, he fixed. Everyone on the team operated the same way. They didn\u2019t leave rough edges for a designer to smooth out later or file a ticket for a frontend engineer to pick up in the next sprint. If you noticed something was wrong while you were using it, you owned it, and you fixed it. Every code review came with a video of the experience because reviewing the code in isolation tells you nothing about whether the product feels right to use. This was a deliberate inversion of how the team had worked before, where you\u2019d benchmark first and figure out the experience later. Here, the rule was: don\u2019t benchmark anything until you\u2019re happy with the experience you have.<\/p>\n Clare Liguori<\/a>, a senior principal engineer who led the development of Kiro, spoke about her experience at my re:Invent keynote<\/a> last year and recently wrote<\/a> about this same pattern. Her observation is that when building a prototype takes days, not months, it makes more sense to prototype before writing. Her team started using their IDE full-time from the moment the first prototype worked, and evolved it daily based on what they actually needed.<\/p>\n Writing is still as important as ever, and it should be you doing the writing, not your AI. Writing forces you to think clearly and confront gaps in your logic. What has changed is that writing is no longer the only way to make an idea tangible.\u202fCoding agents are\u202fcompressing the time between defining the problem and having something real in our hands to evaluate. It is time to amend the way we think about the process that\u2019s brought us this far. You will learn more in one evening of building than in two weeks of writing about what you think will happen.\u202fOnly after you\u2019ve spent time with the prototype, used it the way a customer would, and developed a real understanding of what it can and cannot do, do you begin the writing process. The document you produce after building is fundamentally better than the one you would have written before, because it\u2019s no longer grounded in your assumptions.\u202f<\/p>\n So how do we amend Working Backwards? When you have conviction about the customer problem but have genuine uncertainty about whether your approach will work, you start by building a prototype. Then you use it the way a customer would. You break things, you find the gaps your intuition missed, then you share it with a few colleagues, and if there\u2019s excitement around what you\u2019ve built, you write the doc. Having something tangible to click through as you write changes the quality of the document. You\u2019re no longer describing something you\u2019ve only imagined in your head. You\u2019re describing something that now exists and has been pressure-tested, and your writing will reflect that.<\/p>\n The Quick Desktop team is no longer a handful of people in a conference room. They\u2019ve grown to several hundred engineers, scientists, designers, and product managers. That is the natural trajectory of a product that hundreds of thousands of people now use every day. Every team that grows past a certain threshold faces the same gravitational pull toward the overhead I described earlier. The way you fight that is allowing your teams the freedom to operate as a collection of two-pizza teams, each with clear ownership and the autonomy to make reversible decisions without asking permission. You fight it by keeping the feedback loop short: build, use, learn, iterate. You fight it by hiring people who are uncomfortable when they don\u2019t own their problem end-to-end, and by giving them the tools to act on that discomfort.\u202f<\/p>\n Two pizzas were always about ownership culture, and the tools have caught up to the culture. What made the Quick Desktop team successful is the same thing that has always produced the best work I\u2019ve seen at Amazon: a small group of people who trusted each other, owned the problem end to end, and acted on their conviction.<\/p>\n Now, go build!<\/p>\n","protected":false},"excerpt":{"rendered":"When I joined Amazon, Jeff had an idea: no team should be so large that it couldn\u2019t be…\n","protected":false},"author":2,"featured_media":528510,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[61,60,80],"class_list":["post-528509","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology","tag-ie","tag-ireland","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/528509","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/comments?post=528509"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/528509\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media\/528510"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media?parent=528509"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/categories?post=528509"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/tags?post=528509"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}