With those team sizes, those pizza must either be huge, or Amazon is ridiculously "frugal", or less politely: cheap.
But it sure explains a lot. I never understood how AWS could both work reasonably well, and simultaneously be such an utter mess when it comes to how configuration looks, how the console UI acts, etc.
However, if the teams actually are as loosely coupled as claimed, valued accordingly with 2 pizzas for an up to 10 person team. If they then more or less all of them all have their own "P&L", then that's exactly what one would expect. Everyone doing what's necessary for their individual P&L, trying to avoid taking on any additional responsibility. Overarching concerns, and aspects mostly existing in the interface between teams will almost certainly be either ignored completely, or only given the very least amount effort necessary to keep up appearances.
I was working at Amazon when the 2-pizza team idea was introduced. A week or two later, we though "we're a 2-pizza team now, let's order some pizza". That when we found out that there was no budget for pizza, it was merely a theoretical concept. At the time the annual "morale budget" (for food and other items) was about $5 per person.
These days I think the morale budget is a bit higher; in 2013 there were birthday cakes once a month.
You've got to give respect to Amazon. In most companies you have the grunts, then the engineers. Google will shower engineers with benefits, but the guy driving the google maps car gets nothing (contractor), Facebook? Shower the engineers with benefits! Have to read through death threats daily? You. Get. Nothing! (Contractor). Amazon? Fuck you, you're all getting gruel.
Good point, I wonder why Amazon doesn't point this out whenever people give them a hard time about how the fulfillment center jobs suck. They could present themselves as paragons of egalitarianism.
On May 3rd, 1997 La Costeña of Mountain View, California created the world's largest burrito. The burrito weighed in at 4,456.3 pounds and was measured at 3,578 feet long. It was created at Rengstorff Park in Mountain View.
(So big they had to photograph it from an airplane!)
With a lot of small teams, you have each team producing components which are relatively good individually thanks to easy, flat, one to one communication and continuity of means and responsibility. The alternative is some degree of siloing which tends to cause significant overhead which can even result in an organization being completely blocked.
But it's not a perfect approach either. It's really hard to maintain consistency and you tend to have some degree of duplicated effort. This explains partly why AWS is so inconsistent in term of API and also why the console is so slow (and just unusable garbage past a certain size).
And it's not like there is no gradation in between individual teams acting alone and big silos. You could pretty much have something that tries to mix the better of both view, with some kind of lose central authority that is here to enforce stability, SLA, overall architecture and consistency of interfaces (both API and UI) but doesn't dictate which tools mut be used.
Are there any companies getting cross-team collaboration and prioritization right? I'd love to read more on how they approach it from a planning standpoint.
When I go to an Italian restaurant, I eat a whole pizza by myself. Size is roughly 30cm diameter. I can only assume that those two-pizza-team pizzas are either ginormous, or they're those American-style pizzas where eating more than 2 slices gives you an immediate heart attack.
You can safely assume since Amazon is a US company we're talking about US pizzas, where a single pizza serves 3-5 people. Also, it's typical with American pizza to serve sides such as salad, garlic bread, pasta, fries, etc. and beverages, dessert so "2 pizza" can be read as "2 pizza plus usual sides".
> Domino’s large pizzas are the perfect answer to feeding a hungry group. These 14-inch pizzas feed approximately three to five people
The pizzas that are ordered for a group in the US are generally 16-18 inches (40-45cm). They are usually not as thin-crusted as Italian-style pizzas are, and they usually have more cheese and toppings. Depending on toppings a complete pizza can be more than 4000 calories.
It's the SoC principle[1] applied to organisational design. It faces the same challenges as it does in software - strong/weak coupling. Leaky abstractions. Duplicate functionality. Hotspots.
It gets complex for all the same reasons too. Orchestration, communication, synchronisation, locking, race conditions, Byzantine failures.
I worked at HP after it had adopted the "functional" structure. I remember old timers who attribute the decline of HP (at least in part) to the abandonment of the divisional structure, which had been quite strong in the company.
I would hazard a guess that most tech companies that undergo such a transition likewise eventually suffer the same fate.
I have no real justification for this, but companies have a natural culture. One of the signs of a failing company is trying to adopt someone else's culture. So whilst Functional structures might work for some companies, if you work in a divisional company and management decides to make you "Functional" that sounds like a red flag to me.
Presumably there's a supervisor layer that looks for negative interactions? Like if you're optimising for picking rate and the facilities 2PT is optimising for energy saving then their change in facility temperature could be impacting your picking rate leading to overall poorer outcomes.
I've just started with AI/ML but the use of "fitness function" suggests the model here was a company as an AI.
Presumably they also have multiple 2PT with the same fitness functions so they can do "genetic" selection?
I've been at Amazon for 1 year, 8 months and 21 days (thank you Phonetool).
I'm a product manager, my career history is long and varied including 25 years of running my own companies. I was at first very concerned about the Two Pizza team concept, who's in charge, how do we optimize the application of people to effort? Being a programmer I had always looked to manage the separation of concerns in my designs. I just hadn't thought about it in the real world as a pattern that could work. To me, Amazon is a massive open-source project with many teams focused deeply on a handful of topics. We share data very openly, we share learnings, we share what we're planning to do and ask for input.
My opinion is that somewhere in the history of Amazon the executive team must have realized they could not make all the decisions, that they would become the bottleneck for growth. So instead of focusing on command and control as many companies have done, they focused on how to hire leaders and teach them to think critically, take risks, learn and improve. Amazon values seeking truth and if it's not fully known then where it makes sense take risks to learn and improve the known truth. If you read about our leadership principles[1] you'll see that they're in tension with each other, they're designed to make you think, the answer isn't given to you, the way you come to answers is taught instead. An example, Dive Deep vs Bias for Action, when do you stop digging into the problem and just take action? This tension helps you think about decisions you make that impact the outcome for our customers.
Another thing that often gets overlooked is the concept of "Single Threaded Owner". I'm an STO on a topic, that means I write and communicate the known truth and our strategy and plans, I participate in discussions around that topic, I talk to customers about it, I read industry news and leverage my own experience in that topic. Others know me as that STO and reach out to me with related topics if something makes sense to me in my topic area then I try to address it, if not I connect the person with another STO I think would be interested in their idea or problem. Success at Amazon is deeply driven by networking, we have an internal tool called Phonetool which allows you to quickly navigate the company and find people who are close to the topic you have in mind. I keep thinking it's like the six degrees of separation concept, if somebody doesn't know the topic they know someone who is closer to the topic, within a couple of emails you are in a conversation with someone on the other side of the company who is passionate, fired up and knows more about the topic than you thought could be known. They're excited to talk to you about their topic and teach you or learn from your new idea related to their area of focus.
When I first started someone told me "Don't worry if other people seem to be doing the same thing, over time the best effort will return results and the other ideas will fade and those people will find new ideas to chase". I've heard it said we would rather have two people working on a thing than none. This is a path to discovery. Amazon is very data-driven when you make a statement without data you had best be ready to debate it and explain why that is your position. I myself have a long career and sometimes I just have to say "because I've done it, been there done that". Which is fine but its also awesome when you can show data. I identified a pattern that was unhealthy based on my own experience, my team came up with some metrics we could collect to quantify the issue. Now we're sharing those metrics and people all around my team are rallying around the problem.
In my career, I've run my own companies, been in start-ups that raised money, sold companies to other companies and just about everything else you can imagine. This is the closest to feeling like a startup but with the resources to create great outcomes for customers at scale. It has its challenges as do all companies of more than one person, but many of the challenges are different than I've seen in the past. When in doubt you can always raise a leadership principle and everyone will jump in and talk about how that would apply to the situation we're dealing with. That's unique for me thus far in my career most companies I've worked for have their "values" painted on the walls and that's about as far as they go. I was at a startup where we tried to be very deliberate about our values but this is deeper, cuts across the entire org and everyone is passionate about discussing what they mean for them and how they apply them to their work.
To me what is most important in my career is learning and doing it with great people, so far I've got lots of both of those things applied to problems at a scale I wouldn't have in other companies.
> Success at Amazon is deeply driven by networking
I've seen this at other places. It created toxic politics and divisive cliques.
Without dragging it out too much, I'd think there needs to be a high level of accountability that can overpower strong consensus around low sources of truth and group think.
It would be great (and appreciated) to hear any opinions you have on this topic.
The decisions aren't made by the network. Decisions are driven by knowledge and data and a sense for how we are able to provide the best possible customer outcome.
It's not a "who you know.." sort of environment, but networking will make you more productive because somewhere, on planet earth, someone at Amazon, is thinking about that thing, you just thought of, and they're going to be super excited to compare notes and ideate with you!
I’ve been at Amazon 10 years and this post sums up a lot about what I like about Amazon as well.
Regarding 2PTs: the big thing here is that each 2PT owns services, and has complete operational and (usually) product responsibility for those services. “You build it, you own it.” There is still org level P&L but at the director/VP level and not at the 2PT level. Also there is only one middle manager level before the executive levels (7), which has a nice dampening effect on bureaucracy.
Finally, the working backwards culture has a lot of innovation opportunity. Many large divisions started with a low level employees vision doc.
> I'm an STO on a topic, that means I write and communicate the known truth and our strategy and plans, I participate in discussions around that topic, I talk to customers about it, I read industry news and leverage my own experience in that topic. Others know me as that STO and reach out to me
This is extremely interesting. In your view, does this work with the concept of "full stack teams" where members tend not to develop significant expertise in any one area and tend to be jack-of-all-trades?
"Full Stack" expertise has little to do with STO. To me an STO is on a broad topic such as "Owns this {thing}" etc. It's great to have varied experience because you can add that to the debate on what the right next action is.
Now all this said my job has quite a bit of technical details related to it and the fact that I've hacked stuff up and down the stack and ran companies while also having been a customer in this industry is super useful to my focus. In that respect, I would always encourage people to learn as much as they can and understand the customer's perspective as if you lived it every day.
Could you talk about the daily standup, appraisal, reward structures that make this happen.
Also...and this is the most important and slightly political question.. how do you hire or train for these 2PTL or STO ? do they come from engineering...or are they analysts/business backgrounds ?
STO's come from everywhere, this I love the most about Amazon. From the lowest levels to the highest levels of the organization, if you have an idea, can communicate with some passion and data, you can become an STO. We hire them, recruit them, and they're born of the fire in their belly about a topic. This is the key factor for success, as far as I can tell at Amazon we're all humans and every idea is treated with respect, and no matter the source, the idea could become our next massive customer offering. I have never seen that at other large companies. I hope that never dies here because, with that mindset, we will continue to deliver amazing customer experiences into the foreseeable future.
> Epilogue: This post describes Amazon as I knew it when I worked there 2004–2007. People who were there more recently tell me that since then, fitness functions themselves have been abandoned, although the ideas of accountability, autonomy and ownership are still core and very strong.
Let take it a step further and say it's about human nature. That is, individuals consider themselves as such in a small group. That is they feel personal accountability.
However, as the group grows your perception of where to place accountability shifts to the whole. Thwn group think kicks in and the value of collaboration degrades.
2PT works - at least for Amazon - because it so closely reflects human nature.
Eh. I think the division of the work is only secondary to the quality of its organization and planning, which is almost always done by one or two core people on each team, regardless of the team size. Even a 6 or 8 pizza team could be high-performing if the team members all cooperate very well and have the same ideas and expectations.
Meetings would take way too long, but who says we need daily meetings, or to have everyone there for them? You could have a nearly flat hierarchy, and if all team members took their own initiative to coordinate and perform work in a way that integrates well, you don't even need N-pizza teams. You just need people who take initiative.
This is very rare, I think, but it can be taught. If you're the leader of an organization, focus on teaching people how to be self-organizing, how to care about a whole product, how to anticipate, ask questions, offer help when it's not your job, and find alternative solutions to work problems (ex: "they told us we can't do that" "why?" "I don't know" often has an alternate solution that just isn't immediately apparent)
This seems like a very deliberate model - I imagine that a lot of companies accidentally end up with a divisional structure just based on how their company grows.
For those who have experience with this - what are the fitness functions for common infrastructure - i.e. things that are difficult to tie directly to P&L? For example, the teams maintaining the logging system or the release flags service? I would think there are two metrics you'd want to combine in some way: adoption and then SLOs.
Likewise, on the front-end there is probably a lot of cross cutting work to present a unified product to the customers - how does that work in this model?
If you can convert time into money, everything can be tied to the P&L.
SLOs and time-to-close and telemetry to measure process step times against milestones can all be converted into a shadow P&L, which you can compare against actuals.
I wonder how much more Amazon relies on written communication, over verbal. Even if teams are independent, they do interact with other Amazon teams, right? While there's always social value in some verbal and face-to-face time, it seems like if groups are independent, teams are gonna have to get good at writing things down, to avoid the madhouse.
I could have sworn I've read Amazon is notable for written communication, but I can't seem to quickly find the source. This seems like an important component of making small, independent teams work.
I think 6 to 10 is even be too large for most projects depending on how those people are allocated. If the project has go to people for certain areas of the project like configuration management, CI/CD, BDD test implementation or front end development then that size seems reasonable. But if each developer is expected to do everything then I'd say 4 to 5 person teams would be the max you'd want.
When teams grow beyond 4/5 the context of responsibility and interface surface area is usually too large for them to be fully locked in.
Judging from the confusion here, one could argue that the "two-pizza team" definition is also vague and meaningless - at least to an international audience.
Think how many slice a person typically eats at a team lunch in a professional setting. It's usually a few slices. A large pizza has around 8 slices, so with two pizzas, that covers 6-10 people. And that's what the article says.
How is this special or unusual in any way, except for the fitness function? But: "since then, fitness functions themselves have been abandoned". Leaving ... Nothing special?
Aren't all companies divided into smaller teams somehow?
Can we talk diameters? In the US at the big 3 pizza chains a "large" pizza is approximately 14" in diameter, usually cut into 8 slices. It should satisfy 2-4 adults.
It’s not just diameter - Italian pizza is thin and light, American pizza is deep and heavy. Hence why America moved towards “sharing” formats, because eating a whole dish is challenging for a single person.
There is thin crust vs Chicago deep dish and “Sicilian”. Some thin crus places are really thin.
There is also the matter of toppings. You can have traditional like four seasons, margherita, or you can have bbq chicken with eggs and potato topping.
Teams ought to be grouped on the same religious wavelength (for/against) regarding pineapple and anchovies. Diversity in this respect would be quite deleterious to morale.
That's too vague because American pizza includes thin crust, regular, stuffed-crust, and Chicago-style (thick, pan-style). You gotta be more specific when ordering. ;)
In Poland, when you order from pizza chains (as opposed to regular restaurants, which tend to have overpriced, undersized and undertopped "italian" pizzas), the "large" size circles around 40cm in diameter (which Google tells me is around 15.7"), cut into 8 pieces. Thickness varies, but you usually don't get very thin pizzas unless you ask specially for that option.
14" is closer to medium size, which depending on earlier meals may just about satisfy two adults, or leave them hungry. With four adults, I can only see it leaving them wanting another pizza.
I just checked one of the big chains. A single slice of plain cheese pizza is 295 calories. So an 8 slice "large" pizza would be 2,360 calories. Don't get me wrong, I've done it before, but that's a lot of food for an average adult.
Assuming that's accurate (I feel they may be overshooting here, but I guess it depends on the chain), that's little more than daily requirement for a single adult.
It matches my experience - I can keep myself fully fed for a whole day on a single large pizza. It also reinforces my point - such a pizza might suffice as a dinner for two, but will hardly satisfy more people.
That used to be true, but it has changed a bit over the years. One day in 2004, some team from Microsoft was supposed to visit for a long meeting. The Microsofties knew that they weren't going to get lunch at Amazon, so they ordered their own catered lunch to be delivered to the meeting room. Then they had to cancel for some reason, but the food was still delivered. Word got out and the Amazon employees on the 8th floor descended on the food like a swarm of locusts. They had never experienced free food at work before, nor would they ever experience it again.
Except for the time Steve Raichle showed up to promote his book, and set up some kind of barbeque equipment on the lawn behind the PacMed building, handing out free barbeque. People waited in line for more than 30 minutes, again because the concept of free food at work was totally unheard of.
But it sure explains a lot. I never understood how AWS could both work reasonably well, and simultaneously be such an utter mess when it comes to how configuration looks, how the console UI acts, etc.
However, if the teams actually are as loosely coupled as claimed, valued accordingly with 2 pizzas for an up to 10 person team. If they then more or less all of them all have their own "P&L", then that's exactly what one would expect. Everyone doing what's necessary for their individual P&L, trying to avoid taking on any additional responsibility. Overarching concerns, and aspects mostly existing in the interface between teams will almost certainly be either ignored completely, or only given the very least amount effort necessary to keep up appearances.