Hacker News Reader

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, ...

>"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.

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.

> Hopefully you have good managers (and high level ICs)

Looks at Jira and weeps.

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.

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.

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.

I have multiple juniors but you just described my life and it makes me want to literally scream.

There's few things that are more mind boggling to me than a very rigid interpretation/implementation of agile.

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.

Just sounds like overkill for a team of 1.5.

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.

I’ve only had one manager that far removed from coding and he was amazing. What pitfalls are you referring to?

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.

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.

Well put, I think this is very true.

> 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.

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.

> 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.

Yeah, that's a fair point.

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.

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?

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.

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.

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

"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.