5 ms·

I worked at Amazon on two-pizza teams. I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making

I worked at Amazon on two-pizza teams. I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making. Once you work on something that is big and complicated enough that it requires dozens of engineers, there HAS to be communication and coordination. Hopefully you have good managers (and high level ICs) because they are supposed to do a lot of the coordination so that it is easy for the engineering team to focus on engineering. A goal of independent two-pizza teams is to have the independent teams define how their individual pieces will interface and then the small teams can independently decide on implementation details. The two-pizza team concept is also about having a heuristic that tells you when to start looking into how to divide responsibilities between independent teams. I don't really get what this article is proposing. Never work on projects complicated enough to require lots of engineers and thus coordination? It is not realistic to deliver the complex projects that big companies need to do with a single small team doing everything. It will just never get delivered.

noir_lord 6y ago
> Hopefully you have good managers (and high level ICs) Looks at Jira and weeps.
- WJW 6y ago
  So many of the popular management techniques look at the output of well-trained, highly experienced and very motivated teams and think that if they can just replicate the outward characteristics of those teams, they'll get the productivity as well. Needless to say, the same practices with recent bootcamp graduates suffering under JIRA-inspired micromanagement from a manager who has zero training except "being a developer for three years" will not have the same output. It's cargo culting at its finest.
  - kislayverma 6y ago
    I agree. Looking at the "final practices" of a well-oiled team and just picking them up without any of the context about "why" they work "for that team" is half the reason no good idea (Agile, microservices, Jira) stays that way in software industry.
    - rtkaratekid 6y ago
      As an anecdote of this, I'm in an R&D department of a small company. I'm basically a team of one with an intern (which is its own challenge because he likes to be somewhat micromanaged). My manager just recently was finally convinced to shift from a waterfall module to something agile, except now it's just becoming a micromanagement tool... for a team of essentially 1.5. We had a conversation the other day in which I was given to understand that if we thought some documentation was finished, but had to go back and make a tweak with no more than 15 minutes spent on it, we should be creating a ticket in Jira to do so. I'm currently cursing all the people who've sold agile because this is insanity (imo). Feels good to get that off my chest haha.
      - noir_lord 6y ago
        I have multiple juniors but you just described my life and it makes me want to literally scream.
      - joopxiv 6y ago
        There's few things that are more mind boggling to me than a very rigid interpretation/implementation of agile.
        charwalker 6y ago
        That's literally not how it works too. Agile has a robust and rigid structure that you then pull from and adapt to make your team and processes better. Few teams have the same implementation. It's important to understand the full scale of agile practices and tools but do not try to do it 100%, that's not the idea at all.
      - SaltyBackendGuy 6y ago
        Just sounds like overkill for a team of 1.5.
  - joopxiv 6y ago
    I'll take that manager over one that has 20 years of experience but hasn't touched a line of code for the last 10.
    - derwiki 6y ago
      I’ve only had one manager that far removed from coding and he was amazing. What pitfalls are you referring to?
  - Scarblac 6y ago
    A manager that has experience with development? I wish. Our team of four (frontend development for our two main products) has a "team leader" (not included in the team), two "product managers" (one for each product) and a "director of IT" (our actual manager), none of which have a background in software development. They all have a background in our product's domain.
danielovichdk 6y ago
I think the author is refering to communication outside of the team. Sure, inside the team there is lots of communication, and the business is probably setting the stage on a quarterly scehdule or something along those lines?
- kislayverma 6y ago
  That is correct. Wen I am wrote about "communication overhead" I meant having to talk to other teams to get the work done. Talking within the team (including PM, stakeholders etc.) is, IMO, desirable to set the overall team vision and to keep everyone on the same page. I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.
  - redredrobot 6y ago
    At least when the approach works, I think the goal is to not have to have the teams aligned, instead giving them independent mandates that lead to the emergent behavior being what the business needs.
mytailorisrich 6y ago
Yes, it's not about reducing communication, it's about keeping the number communication channels and coordination manageable. The "two-pizza team" is like a squad/section in military organization. It's the sweet spot of having enough people to get things but not too many people so that communication and coordination starts to be a problem.
- redredrobot 6y ago
  Well put, I think this is very true.
michaelcampbell 6y ago
> I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making. The point of the article is that if you don't own a problem space you don't own the decision making; you require communication with other entities for their part of the decision. Requiring comms.
- redredrobot 6y ago
  But I don't really agree. If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces, you can make decisions about how to solve your subproblem quickly and independently. Also, process/culture decisions (e.g. code style, automated tooling, code review standards, update cadence, etc) become easier because you only need to come up with a solution that makes ~10 people happy instead of a solution that serves the needs of 100+ people.
  - jeastwood 6y ago
    > If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces I think that's where you and the other commentator are talking past each other. Amazon tends to have great managers and senior ICs that get the responsibility and technical divide right. My experiences outside Amazon unfortunately point towards this being hard to get right in the first instance, and really really hard to fix once it has gone wrong.
    - redredrobot 6y ago
      Yeah, that's a fair point.
  - toast0 6y ago
    These are all the same thing. Or at least, they all reinforce each other. You can make quick decisions because you don't have to communicate with a large group. You don't have to communicate with a large group because you own your space. You own your space because you have clear external interfaces. If the external interface needs to change (from your side or the other side), it requires external communication and is probably slow, so you (and the other side) try to get it right the first time and minimize changes.
AgloeDreams 6y ago
Same. The person who wrote this clearly never has a 16 person standup that lasts 45 minutes.
- spanhandler 6y ago
  "We do daily standups" But then actually it's people from multiple totally unrelated teams ignoring each other and taking turns talking at a manager, hoping same manager chooses to hover over someone else for the day and trying to ensure that happens by impressing them with a list of every little piddly thing they did yesterday that no-one on their own team even actually needs or wants to know about.
pdelgallego 6y ago
The Two-pizza team concept is a very small part on how Amazon works. A few others on top of my head. - Enable high-velocity decision making: Defining clear tenets that act as the north start for decision making at team level, and two-way doors thinking. - Establish how you measure success, and how does relate to the goals of the organisation. - Achieve team independency is a key factor, and having strong mechanisms such as the "away teams" concept, "communication is terrible" mental model and reducing cognitive overload by relying on platform teams - Nominating a single-threaded owner for programs and business outcomes. - Articulate how the organisation works across teams using mechanisms such as bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...
- closeparen 6y ago
  >"communication is terrible" My company has brought in a lot of Amazon people and ideas, but unfortunately we go this one backwards. "Communication is great." Managers are explicitly encouraged to structure projects to maximize cross-team and cross-org meeting hours.
  - pdelgallego 6y ago
    It is quite common to get communication wrong, even inside Amazon. It leads to design by committee, slow decision making, and increase team dependencies. I would love to hear your experience adopting Amazon mechanisms. Disclaimer: I work at Amazon. I help customers to adopt some of those mechanisms.

noir_lord 6y ago

> Hopefully you have good managers (and high level ICs) Looks at Jira and weeps.

WJW 6y ago
So many of the popular management techniques look at the output of well-trained, highly experienced and very motivated teams and think that if they can just replicate the outward characteristics of those teams, they'll get the productivity as well. Needless to say, the same practices with recent bootcamp graduates suffering under JIRA-inspired micromanagement from a manager who has zero training except "being a developer for three years" will not have the same output. It's cargo culting at its finest.
- kislayverma 6y ago
  I agree. Looking at the "final practices" of a well-oiled team and just picking them up without any of the context about "why" they work "for that team" is half the reason no good idea (Agile, microservices, Jira) stays that way in software industry.
  - rtkaratekid 6y ago
    As an anecdote of this, I'm in an R&D department of a small company. I'm basically a team of one with an intern (which is its own challenge because he likes to be somewhat micromanaged). My manager just recently was finally convinced to shift from a waterfall module to something agile, except now it's just becoming a micromanagement tool... for a team of essentially 1.5. We had a conversation the other day in which I was given to understand that if we thought some documentation was finished, but had to go back and make a tweak with no more than 15 minutes spent on it, we should be creating a ticket in Jira to do so. I'm currently cursing all the people who've sold agile because this is insanity (imo). Feels good to get that off my chest haha.
    - noir_lord 6y ago
      I have multiple juniors but you just described my life and it makes me want to literally scream.
    - joopxiv 6y ago
      There's few things that are more mind boggling to me than a very rigid interpretation/implementation of agile.
      - charwalker 6y ago
        That's literally not how it works too. Agile has a robust and rigid structure that you then pull from and adapt to make your team and processes better. Few teams have the same implementation. It's important to understand the full scale of agile practices and tools but do not try to do it 100%, that's not the idea at all.
    - SaltyBackendGuy 6y ago
      Just sounds like overkill for a team of 1.5.
- joopxiv 6y ago
  I'll take that manager over one that has 20 years of experience but hasn't touched a line of code for the last 10.
  - derwiki 6y ago
    I’ve only had one manager that far removed from coding and he was amazing. What pitfalls are you referring to?
- Scarblac 6y ago
  A manager that has experience with development? I wish. Our team of four (frontend development for our two main products) has a "team leader" (not included in the team), two "product managers" (one for each product) and a "director of IT" (our actual manager), none of which have a background in software development. They all have a background in our product's domain.

danielovichdk 6y ago

I think the author is refering to communication outside of the team. Sure, inside the team there is lots of communication, and the business is probably setting the stage on a quarterly scehdule or something along those lines?

kislayverma 6y ago
That is correct. Wen I am wrote about "communication overhead" I meant having to talk to other teams to get the work done. Talking within the team (including PM, stakeholders etc.) is, IMO, desirable to set the overall team vision and to keep everyone on the same page. I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.
- redredrobot 6y ago
  At least when the approach works, I think the goal is to not have to have the teams aligned, instead giving them independent mandates that lead to the emergent behavior being what the business needs.

mytailorisrich 6y ago

Yes, it's not about reducing communication, it's about keeping the number communication channels and coordination manageable. The "two-pizza team" is like a squad/section in military organization. It's the sweet spot of having enough people to get things but not too many people so that communication and coordination starts to be a problem.

redredrobot 6y ago
Well put, I think this is very true.

michaelcampbell 6y ago

> I never thought the two pizza team was about reducing communication, but more allowing faster independent decision making. The point of the article is that if you don't own a problem space you don't own the decision making; you require communication with other entities for their part of the decision. Requiring comms.

redredrobot 6y ago
But I don't really agree. If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces, you can make decisions about how to solve your subproblem quickly and independently. Also, process/culture decisions (e.g. code style, automated tooling, code review standards, update cadence, etc) become easier because you only need to come up with a solution that makes ~10 people happy instead of a solution that serves the needs of 100+ people.
- jeastwood 6y ago
  > If you are a small team solving a small part of a larger problem and you have done a good job of defining your external interfaces I think that's where you and the other commentator are talking past each other. Amazon tends to have great managers and senior ICs that get the responsibility and technical divide right. My experiences outside Amazon unfortunately point towards this being hard to get right in the first instance, and really really hard to fix once it has gone wrong.
  - redredrobot 6y ago
    Yeah, that's a fair point.
- toast0 6y ago
  These are all the same thing. Or at least, they all reinforce each other. You can make quick decisions because you don't have to communicate with a large group. You don't have to communicate with a large group because you own your space. You own your space because you have clear external interfaces. If the external interface needs to change (from your side or the other side), it requires external communication and is probably slow, so you (and the other side) try to get it right the first time and minimize changes.

AgloeDreams 6y ago

Same. The person who wrote this clearly never has a 16 person standup that lasts 45 minutes.

spanhandler 6y ago
"We do daily standups" But then actually it's people from multiple totally unrelated teams ignoring each other and taking turns talking at a manager, hoping same manager chooses to hover over someone else for the day and trying to ensure that happens by impressing them with a list of every little piddly thing they did yesterday that no-one on their own team even actually needs or wants to know about.

pdelgallego 6y ago

The Two-pizza team concept is a very small part on how Amazon works. A few others on top of my head. - Enable high-velocity decision making: Defining clear tenets that act as the north start for decision making at team level, and two-way doors thinking. - Establish how you measure success, and how does relate to the goals of the organisation. - Achieve team independency is a key factor, and having strong mechanisms such as the "away teams" concept, "communication is terrible" mental model and reducing cognitive overload by relying on platform teams - Nominating a single-threaded owner for programs and business outcomes. - Articulate how the organisation works across teams using mechanisms such as bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...

closeparen 6y ago
>"communication is terrible" My company has brought in a lot of Amazon people and ideas, but unfortunately we go this one backwards. "Communication is great." Managers are explicitly encouraged to structure projects to maximize cross-team and cross-org meeting hours.
- pdelgallego 6y ago
  It is quite common to get communication wrong, even inside Amazon. It leads to design by committee, slow decision making, and increase team dependencies. I would love to hear your experience adopting Amazon mechanisms. Disclaimer: I work at Amazon. I help customers to adopt some of those mechanisms.