A return to two-pizza tradition


Where’s the Pizza?

Once I joined Amazon, Jeff had an thought: no workforce ought to be so massive that it couldn’t be fed by two pizzas. In these early days, some groups had been so small that one pizza would’ve been sufficient to get the job completed. But it surely was by no means actually about feeding hungry engineers. We might’ve simply as simply mentioned a “six sandwich workforce”, however sandwiches don’t evoke the identical imagery as pizza. Pizza is what you order whenever you and your friends are crowded across the whiteboard late into the night.

We needed to maintain groups sufficiently small so that everybody within the room knew what everybody else was engaged on, with out requiring conferences. Every member of the workforce owned the product. You had the autonomy to make choices with as little paperwork as doable. You had been empowered to maneuver quick, to experiment, and to not be afraid of failure. If the choice was reversible, you didn’t want permission to make it. You made it, you discovered from it, and if it was flawed, you reversed it. The price of a flawed reversible resolution is sort of at all times decrease than the price of making that call slowly.

As our buyer base grew, so did the variety of our groups. Whenever you go from three companies to over 2 hundred, you don’t get to maintain the identical organizational construction. It’s easy physics: as programs develop, so does their entropy. Every service requires homeowners, and homeowners must coordinate with the groups whose companies they depend upon. Org constructions turn into layered, dependencies multiply, and approval cycles seem the place none existed earlier than. Instantly, a workforce that used to personal an issue end-to-end now wants alignment throughout a number of groups earlier than they write a single line of code. At some second, the inertia of any rising firm begins to work in opposition to the very tradition that made it profitable. This doesn’t essentially imply the standard of the product will endure, however until you combat it, it means your velocity of supply will lower.  

Together with the two-pizza method to handle workforce dimension, we used a novel method to outline our merchandise—working backwards from the client. I wrote about this again in 2006:

The Working Backwards product definition course of is all about fleshing out the idea and attaining readability of thought of what we’ll in the end go off and construct. It sometimes has 4 steps:

  1. Begin by writing the Press Launch
  2. Write a Ceaselessly Requested Questions doc
  3. Outline the client expertise
  4. Write the person handbook

We’ve achieved outstanding successes working backwards, and have solved actual issues for tens of millions of consumers utilizing feats of engineering that also amaze me to at the present time. Our groups are nonetheless sized round our two-pizza mannequin. They nonetheless transfer quick and break issues, however they wait till they’ve totally outlined the issue and all the enterprise line clearly understands how they’ll clear up it collectively.  

However there’s a shift occurring in our business, and I maintain listening to tales throughout Amazon which are difficult me to assume a bit in a different way in regards to the technique of bringing merchandise to life. Should you take a look at the 4 steps above, what they’ve in frequent is deep fascinated about the issue house, then writing about it. Getting the thought out of your head and onto paper is the way you hone the thought. You poke holes in it, uncover what you don’t know, and share it along with your friends to reach at a shared understanding of what is going to be constructed. It’s arduous work to write down a crisp doc, and almost unimaginable in case you don’t have readability of thoughts in regards to the buyer drawback you need to clear up. However there’s one other very deliberate cause we use writing at Amazon: writing permits anybody to construct a product as a result of it doesn’t require you to know the way to code. A product supervisor, a UI designer, a enterprise analyst, anybody with a well-written thought and compelling argument might outline what will get constructed subsequent.

However what occurs when anybody with an thought can sit down with a coding agent and produce a purposeful shell of a product in a single night?

In late January 2025, a handful of our scientists had been speaking amongst one another and realized they’d all been fascinated about the identical drawback house independently. How do you give an agent reminiscence that persists? How do you let a number of brokers coordinate with out a central bottleneck? How do you retain people in management whereas the system scales? They wanted an working system for brokers. They determined to get right into a room collectively for just a few days and see what they might give you.

Thomas Delteil, who’s a principal scientist on our Amazon Fast workforce, had been involved by the tempo at which good concepts had been dying. The cycle of proposing an thought, ready for dialogue, constructing a proof of idea, benchmarking it, in search of visibility for it, then ready once more for the following spherical of approvals was killing concepts earlier than they ever reached a single buyer. So when the dialog turned to what they might construct in the event that they stopped ready for permission, Thomas spent all the evening utilizing Kiro to construct the primary prototype of what would turn into Amazon Fast Desktop. When he demoed it the following day, the primary query from the workforce was “how do I get this on my laptop computer proper now?” and the second was “what can I assist with?” Inside hours of first seeing it, the mission had an proprietor for the exercise feed, an proprietor for reminiscence, an proprietor for the information graph, and an proprietor for the agentic harness.

Inside every week, Swami Sivasubramanian, our VP of Agentic AI, noticed the prototype and gave the workforce his full assist. Three engineers joined. By the second week, they’d a software program growth supervisor and some extra engineers, reaching a roughly even cut up between science and engineering. They had been deliberate about not scaling too quick. Every one who was introduced on was chosen as a result of they’d a selected talent, they usually needed to adapt to a tradition that was an entire departure from how the broader group operated. They had been anticipated to personal an issue and ship with autonomy, and possession meant the identical factor it has at all times meant at Amazon: you construct it, you personal it. 

Leo Ohannesian, the product supervisor recruited to affix the Fast workforce 5 days into the trouble, had spent years working in organizations that began with a PRFAQ, would undergo evaluation cycles, safe funding, assign homeowners, and set timelines. On this early workforce, there was none of that. Switching to a mannequin the place a small group of senior folks had been totally trusted to make the proper choices produced a velocity he’d by no means skilled in his profession.

A giant driver of what made this tempo doable was that each particular person on the workforce used the product as their major AI assistant from day one. Thomas was constructing it the way in which he needed an assistant to be, and something he didn’t like, he mounted. Everybody on the workforce operated the identical method. They didn’t go away tough edges for a designer to easy out later or file a ticket for a frontend engineer to select up within the subsequent dash. Should you seen one thing was flawed when you had been utilizing it, you owned it, and also you mounted it. Each code evaluation got here with a video of the expertise as a result of reviewing the code in isolation tells you nothing about whether or not the product feels proper to make use of. This was a deliberate inversion of how the workforce had labored earlier than, the place you’d benchmark first and determine the expertise later. Right here, the rule was: don’t benchmark something till you’re pleased with the expertise you’ve.

Clare Liguori, a senior principal engineer who led the event of Kiro, spoke about her expertise at my re:Invent keynote final yr and not too long ago wrote about this similar sample. Her remark is that when constructing a prototype takes days, not months, it makes extra sense to prototype earlier than writing. Her workforce began utilizing their IDE full-time from the second the primary prototype labored, and developed it every day based mostly on what they really wanted.

Writing remains to be as necessary as ever, and it ought to be you doing the writing, not your AI. Writing forces you to assume clearly and confront gaps in your logic. What has modified is that writing is not the one strategy to make an thought tangible. Coding brokers are compressing the time between defining the issue and having one thing actual in our fingers to guage. It’s time to amend the way in which we take into consideration the method that’s introduced us this far. You’ll study extra in a single night of constructing than in two weeks of writing about what you assume will occur. Solely after you’ve hung out with the prototype, used it the way in which a buyer would, and developed an actual understanding of what it could actually and can’t do, do you start the writing course of. The doc you produce after constructing is essentially higher than the one you’d have written earlier than, as a result of it’s not grounded in your assumptions. 

So how can we amend Working Backwards? When you’ve conviction in regards to the buyer drawback however have real uncertainty about whether or not your method will work, you begin by constructing a prototype. Then you definately use it the way in which a buyer would. You break issues, you discover the gaps your instinct missed, then you definitely share it with just a few colleagues, and if there’s pleasure round what you’ve constructed, you write the doc. Having one thing tangible to click on by as you write modifications the standard of the doc. You’re not describing one thing you’ve solely imagined in your head. You’re describing one thing that now exists and has been pressure-tested, and your writing will mirror that.

The Fast Desktop workforce is not a handful of individuals in a convention room. They’ve grown to a number of hundred engineers, scientists, designers, and product managers. That’s the pure trajectory of a product that a whole bunch of hundreds of individuals now use day-after-day. Each workforce that grows previous a sure threshold faces the identical gravitational pull towards the overhead I described earlier. The way in which you combat that’s permitting your groups the liberty to function as a group of two-pizza groups, every with clear possession and the autonomy to make reversible choices with out asking permission. You combat it by maintaining the suggestions loop quick: construct, use, study, iterate. You combat it by hiring people who find themselves uncomfortable after they don’t personal their drawback end-to-end, and by giving them the instruments to behave on that discomfort. 

Two pizzas had been at all times about possession tradition, and the instruments have caught as much as the tradition. What made the Fast Desktop workforce profitable is similar factor that has at all times produced the very best work I’ve seen at Amazon: a small group of people that trusted one another, owned the issue finish to finish, and acted on their conviction.

Now, go construct!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *