8 ms·

Independence, autonomy, and too many small teams

214 points by kislayverma 6y ago

qznc 6y ago
Another issue in big companies: There are obvious inefficiencies as autonomous teams do redundant work. Some things should be centralized (eg payroll) but others not (eg design). Where to draw the line? For example, should autonomous teams create their own build tool chains?
- undro 6y ago
  This is the exact dilemma described in "High Output Management." Corporate organization is the art of deciding what to centralize and what to decentralize.
scribu 6y ago
The post makes a good case for why it's a bad idea to split a business problem into slices. Even though you have multiple small teams, they still need to closely coordinate with each other. But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
- thablackbull 6y ago
  > Even though you have multiple small teams, they still need to closely coordinate with each other. That's what a competent manager/management is for though.
  - smitty1e 6y ago
    #DingDingDing And perhaps the Product Owner vacuum is filled in the sequel mentioned above. The other point I was awaiting was documentation. Thank you to the one who at least threw a ransom note into the wiki. My software archaeology project would be impossible otherwise.
  - qznc 6y ago
    Not if management implies non-technical. Maybe an architect role would describe it better.
- kislayverma 6y ago
  I'm still writing it :)
- huffmsa 6y ago
  It's a bad idea when the slices aren't independently achievable. The military analog is the fire team (3-4 ppl) or the squad (5-14 ppl), depending on how hungry they are and what the current theater demands. Squads can be assigned multiple discreetly accomplishable objectives. Each squad is assigned to secure a different building on a street, for example. No one squad is necessarily codependent on the success of the other squads to meet it's own objective, but when you pull back a level, overall organizational success (securing the neighborhood, winning the fight in the city, winning the war) is dependent on the success of all of the squads. The article argues, and I agree, that as a company grows, it's easy to shift from discrete squads to assembly line squads. Eg data ingestion => data transformation => data delivery. Platoon / company level objectives, not squad level ones. I have the analogies, but not necessarily and better solutions.
- rapht 6y ago
  > The post makes a good case for why it's a bad idea to split a business problem into slices. Why it's a bad idea is indeed demonstrated. But why it happens in practice is not just to obey the "small team" mantra. It's also because as organizations and products mature, the law of diminishing returns kicks in: once easy gains have been made, achieving more gains requires tackling more complex problems - either because they are actually more complex in themselves, or because of the environment has become more complex. > Even though you have multiple small teams, they still need to closely coordinate with each other. > But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck? That complexity actually means that whatever the way you organize, you're going to have more people involved. That's when you need good managers - what I call a good manager is not only competent to manage their own team, they're also good at making their team play in a more global picture without necessarily having a boss telling them to do so.
  - pico303 6y ago
    These are great points. I disagree with a lot of this article, because it oversimplifies the problem without considering things like this. Another related problem it forgoes discussing is the idea of planning. Once these problems get harder, the need for people to sit down and design a solution grows, sometimes exponentially. Yes, you need good communication, but you also need something to communicate and agree on. How many small teams in big orgs have even a simple design doc to work from?
easymodex 6y ago
The term "two-pizza" teams is always weird to me, like how can you get anything done with only 2 people on the team.
- chrisseaton 6y ago
  Pizzas in the US are pretty huge - they’re not like a classic pizza for one person as in Italy. I think a two-pizza team is up to about sixteen people.
  - bengale 6y ago
    Thats a big pizza.
    - chrisseaton 6y ago
      Yes two pizzas cut into eight each getting a very large slice.
    - huffmsa 6y ago
      16" pizza. You won't get a whole meal out of it, (16 total slices, 400in², 25in² per slice), but you'll fuel everyone for a few hours.
      - rzzzt 6y ago
        Metric-land reporting in: it is possible to finish a 32 cm pizza on your own (12.6"), but the 45 cm ones are definitely multiplayer material (17.7").
        randallsquared 6y ago
        Well, "thin crust" vs "deep dish" is a pretty huge difference, too. Pizza Hut has or had a "personal pan pizza" that's 15cm or so and considered a meal by itself.
        6y ago
redredrobot 6y ago
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.
DonHopkins 6y ago
Too many "pineapple" team members!
xvector 6y ago
All this discussion is doing is making me crave pizza and making it mighty hard to stay on my diet...
stef-13013 6y ago
https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month
lilcodedummy 6y ago
I don't really agree overall. Yes I understand a "two pizzas" team isn't perfect and does introduce new problems comparatively to whats its replacing, but when you look at the alternative which you call the "Autonomous team mission" you have a even worse set of problems.
- jnwatson 6y ago
  I'm imagining a dozen tiger teams all with write access to all the code repos, all with potentially non-aligned goals. That sounds like chaos to me.
jeremiahlee 6y ago
This is similar to my experience at Spotify, where I had similar takeaways: https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/
ChrisMarshallNY 6y ago
I feel that it really all comes down to good first-level management, and retaining engineers longer than 18 months (see "good management," above). I don't think there's any "silver bullets." Humans, are, well...human, and that means there's a lot stuff like emotions, personal motivations, ambition, self-doubt/confidence, team dynamics, etc. That requires managers that don't just follow buzzwords, but understand the humans they lead, and act as shields between the employees and upper managers that aren't very good at managing humans. Armies run on their sergeants. The Captains, Majors and Colonels are necessary to implement strategy, and convert into tactics, but if you can't keep your teams trained, focused, and motivated at the sharp end of things, the finest generals in the world won't be able to take on a playground full of toddlers with water pistols. But then, that's just my experience and opinion. YMMV.
maps7 6y ago
My ideal setup: Small teams that own and are responsible for products. Teams expose any information they need to share via APIs (including data for reports) Teams consume any information they need via other team's APIs. My experience: Teams that have 9-12 people on them, all working on different things/products, people external to the team completing some tasks that the team can't do, struggles to prioritize work since there is so many work streams coming into the team, members moving from one team to another, work moving from one team to another
- jshawl 6y ago
  My experience with this has been that when teams dissolve, new apis are created on top of the existing apis to avoid making changes to the original api. Debugging a production issue now involves a lot of finger pointing about which API is working correctly, and which one needs "the fix".
lnsru 6y ago
Maybe there are too many managers, that should be elsewhere. Because management is money and glory and this attracts wrong kind of people. And then all the adventures and problems with management start. Engineers, on other hand, with technical experience and some charisma are hard to find. These are doing well as solo entrepreneurs.
- pjmlp 6y ago
  Not every country way of doing things is that rewarding for solo entrepreneurs and if one doesn't want to be dragged into management they need to be willing to fight against it at every opportunity, because on most companies it is not natural not wanting to be promoted.
pm 6y ago
The OP is describing Conway's Law, and shows that half the battle is being able to define the problem space in a way that minimises communication and maximises utility. As such, it could be inferred that beginning with a monolithic organisation, and splitting off a new team at the appropriate time when a useful problem space had been defined could be a possible best practice, assuming the organisation was flexible enough. Food for thought, at least.
- kislayverma 6y ago
  That is well put, and I'm going steal some of those words in the follow-up I'm writing. I essentially feel that teams should grow when tech and process initiatives have led to creation of a whole new problem space that can be explored independently. Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
  - pm 6y ago
    Thanks! Indeed, it's the interfaces that are hardest to define. I don't know a good heuristic to determine it I'm afraid - everything I've ever done was on intuition.
- hinkley 6y ago
  I think in general we underestimate the power of the B-tree, and this is but another example.
bitwize 6y ago
The problem described in the article is one the industry has developed a solution for: SAFe, which is explicitly designed to help small teams align their goals and yeah I can't finish this with a straight face.
- jrott 6y ago
  Haha SAFe when you want the worst of all worlds around how to setup software development teams. More seriously SAFe is trying to solve a real problem but to actually solve it involves much deeper organizational change because of Conway's law then most people are comfortable with.
beaker52 6y ago
At the company I work at, we're definitely not autonomous. If as a team we have a goal, as a dev, I don't know what it is. We have roadmapped (read: itineraried) work items, basically handed to our team to produce. Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work. Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it. But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_. Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.
- cygned 6y ago
  > Well, as devs, we have specific feature requirements > Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management. I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?
  - waheoo 6y ago
    I actually prefer a systems lifetime as the 4th dimension. Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)
marcinguy 6y ago
Great article. Looking for some bright minds, agile minds opinions how one should structure and how should Security Team work in an agile organization (100 devs). Where I agree with the article, for software dev, I am not sure if this will be applicable to Security Teams. Security Team ideally should deliver "security" of the company, however team cannot do it alone, we rely on other teams (devs for code, devops for infra), employees (phishing) and also need to collaborate a lot. How would you tackle Security and Security Team in agile organization? Thanks,
- allendoerfer 6y ago
  I think a company cannot run only on teams delivering features. There will always be some functions like HR, legal or sales. I think security fits in there nicely, it is quite similiar to compliance. A security team is not delivering security by itself, it is more like an HR department trying to prevent workplace harassment or a legal team trying to prevent GDPR violations. You might also think of it not as a team at all, when you are consulting for other teams, you are delivering features as part of that team.
- inerte 6y ago
  At a higher level Agile is about delivering value end-to-end as soon as possible, repeated a lot of times. The iterative part is important, because you're supposed to be measuring and learning based on past deliverables. I don't know how your company organizes the security teams, but both at Yahoo and now at GoDaddy the security folks delivered a lot of software. Code scanners, patches rollout, monitoring, etc... I agree you can't exactly deliver phishing protection, but for example I've seen fake phishing emails being sent by executives, and then the security team measures if employees are taking the bait. You do that every once in a while, measuring if things are improving or not. Maybe there are other angles you can use to approach how you measure the value your team delivers.
mannykannot 6y ago
The basic premise behind two-pizza teams, at least as given here, is flawed. While it is true that if a task requires limited communication, a small team could complete it quickly, most significant tasks require more than a little communication, in which case, adopting a structure that limits it is counter-productive. If you have a small team whose members all have a deep understanding of the goal, the strategy for achieving it, where the problems will be, and what trade-offs are possible, then they can achieve a lot with the minimal necessary communication, but you do not get any of that for free just by making small teams - that would just be cargo-culting the issue.
shay_ker 6y ago
> What might have been a “Data Delivery Team” charged with delivering fresh data to customers unfortunately becomes “Data ingestion Team”, “Data processing Team” and “Data Release Team” (real world example). This split is eerily similar to Backend, UI, Ops, which is the very thing the author criticized earlier in the post. It sounds like the teams they ended up with just weren't cross-functional teams. There's another tell, too: "Data-Delivery". What does that even mean? From my perspective, I have zero clue. There's likely a dozen different ways to slice that up into discrete sets of user experiences of features. And then you can organize cross-functional teams around those experiences, like: reliability, visualizations, integrations, etc. Of course, things aren't always that clean. The real world is much more murky.
- kislayverma 6y ago
  >It sounds like the teams they ended up with just weren't cross-functional teams. You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here. "Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.
  - shay_ker 6y ago
    I'm interpreting the core issue as two pizza team == organized around OKRs Whereas the better way to think about it is two pizza team == cross-functional, lean teams Seems like an issue around semantics
annoyingnoob 6y ago
Do you mean to tell me that 9 women cannot have a baby in a month?
- MattGaiser 6y ago
  "But we need that baby in a month. How many women/expensive consultants do you need?"
  - jasonm23 6y ago
    3 years later, all the consultants and contract workers have moved on to different jobs at different companies. The sponsors in the enterprise client have all moved on. No one even knows the team was supposed to produce a baby.
    - contingencies 6y ago
      A middle manager makes their career out of being present at the time, publishing their distilled wisdom in a best-selling tome, translated in 50 languages: Business at the speed of bacteria.
deleted 6y ago
[deleted]
ukj 6y ago
The observation that this pattern emerges recursively is totally valid. Just as we refactor code and add layers of abstraction, so we refactor org structures when certain teams become hotspots. The crux of the matter is that as organisations scale up different teams have different "runtime complexity" (if you will). Scaling up input 2x produces 2x more work for some teams and 100x more work for other teams. And then we have ourselves the "how do we scale workloads?" discussion on our hands again. If your workload is stateless - you scale it horizontally (more humans). If you workload is stateful you scale it vertically. I don't know how to scale humans vertically.
jkingsbery 6y ago
I like this article a lot, it's a pretty good summary of the problem. > Most developers, especially in larger organizations, complain about meetings, I would quibble with this though - I think this depends a lot on your manager, your project, and some other things. I've been part of start-ups that have a daily standup that lasted over an hour and involved everyone in the company (~20 people), and the time in my career I had the fewest meetings was when I worked for Dow Jones (not a FAANG, but also not a small company). My experience working for a few different start-ups is that start-ups have as many meetings, they just tend to be more ad-hoc, less formal, and might not always involve a formal Outlook Calendar invitation.
JamesBarney 6y ago
> The concept of the “two pizza”/”autonomous” team arose from attempts to minimize communication between multiple teams and empowering a single team to be in complete control of delivering customer value. > Before this idea gained popularity, the most common way of organizing teams was in terms of Backend, UI, DBA, Ops etc.. Building any feature required a lot of communication, collaboration, and alignment between all these groups. I always thought this was called cross-functional and saw the term way before anyone started talking about two pizza/autonomous teams.
Milank 6y ago
I remember when we were expecting our first child, we went through a 'parenting school' - a course where all kinds of doctors, psychologists, nurses, nutritionists, etc. came to teach us, future parents, about parenthood. Since it's not maths, a lot of them had different views on different things, which confused people. Until one day, one future mother, all anxious (if you're a parent, you'll understand the psychological state of expecting a first baby in the next month or two) asked almost angrily: "You people give us conflicting advises, what should we do? How do we do good when even you don't agree what's good between each other???" The answer was simple: "We give you all views, all options. It's up to you which one you think is right and good for your kid. That's what parenting is. That's why we are all different people." Same thing works for companies. Leadership shapes the company. There is no one-size-fit-all strategy. What works for one company, doesn't work for another. Two pizza team size can work somewhere. Somewhere else something else will. People tend to look for manuals, instructions on how to do things, expecting that someone will write it all down and they just need to do what's written. From time to time, we get to hypes about something (check under microservices for example), everyone use it because it's popular, fancy, buzz word. Without thinking - do we really need this? It's like an epidemic (or pandemic?) of paper pushers, no one wants to take responsibility. To take action. And there is no responsibility if you do things as it's written in the manual, right? Best methodology is - work with your team. Talk to the team. Know how they breathe. And they will tell you what to do, how to organise them, which methodology to use. "Take care of your people and they will take care of your business."
yeswecatan 6y ago
I'm actually going through this at my current job. We have a team of 8 where some report to essentially the head of the team and some report to me, a "lead", who reports to the head. This makes absolutely no sense to me. I'm hearing that things are setup this way because having 7 direct reports is too many. Even if we ignore the weird org chart, having say two teams of four doesn't make sense to me if everybody is working on the same things. Can someone please explain if I'm thinking of this the right way or not?
- blahbhthrow3748 6y ago
  7 direct reports actually seems fine if this person's role is primarily management. If they're also doing some combination of tech lead/product stuff they may want fewer reports to free up time for non-management activity. Delegating some subset of direct reports seems less like it's about product or technical direction and more about aggregating and filtering management concerns. Presumably the whole team still works on the same thing and plans their work together, it's just that you do half the 1:1s, deal with what you can, and kick things up the chain if you can't.
  - yeswecatan 6y ago
    I guess I'm jut having difficulty defining what my team does vs. others that are on the same larger team. There's also a weird extra level on the org chart where ICs on my team and ICs on the head of the team are on different levels on paper.
- dbish 6y ago
  7 direct reports is very normal for a manager. One thing to dig into is whether they think 7 direct reports is too many for you (as opposed to anyone) and they just don't want to say it directly. This could be because they think you are spending too much time on IC tasks (coding) and won't be able to handle that many, you're too junior (recently started managing), or there are other issues going on with you or the other lead that your senior management hasn't been explicit about. You can do this constructively by asking more about what they'd be looking for to show that you could handle that scope and how to set goals/improve to get there.
Reimersholme 6y ago
I wish I had read the last to sentences first; "How can we scale our teams to deliver on more and more ambitious goals while retaining their autonomous nature? I will offer some opinions on this in the next post." So the whole meat of the article I expected is nowhere to be found.
SV_BubbleTime 6y ago
When I was at Amazon, it was full of two pizza teams. Seems like a good enough strategy to me. I don’t know that necessarily cuts down on “this meeting should’ve been an email”. And I would often walk past conference rooms to see the TV showing four remote meetings of other two person teams. Which means in that meeting was a ten pizza meeting, IDK if that was the plan.
rustybolt 6y ago
Weird term, pizzas are usually too small to feed someone. Or do they have giant pizzas in the US?
- goldenchrome 6y ago
  Standard pizzas from any chain in the US are about 12” diameter with 8 slices. A pizza can feed 2-3 people comfortably.
  - rustybolt 6y ago
    That's about the same as in Europe. I can't eat a pizza for dinner, I will be hungry after it, and I'm not even very big (about 6 foot, which is below average, and < 160 lbs)... (Maybe because I sport more than average?)
    - goldenchrome 6y ago
      A 12" cheese pizza has about 2000 calories. A 6' tall 160 lb man who does vigorous exercise 5+ times a week needs 2500-3000 calories per day to maintain weight. So if you're still hungry it's because you didn't eat much else all day. Or you're training like an Olympian. Or you're on your way to getting fat. Or European pizzas are low in calories.
dr-detroit 6y ago
Oof I was just fantasizing about downsizing from my 6 pizza team. Its like people go out of their way to be hard to work with.
Lammy 6y ago
I'd prefer to be on a "zero pizza" team, as in a team that doesn't get pulled into crunch-time at all.
bilater 6y ago
This is exactly what I saw at Amazon. 6 teams working on the same thing, massive communication overhead/hoops to go through to get accesses, too many PMs bickering and trying to get buy in from other stakeholders which slowed down the whole process.
chaosbutters314 6y ago
two-pizza teams makes no sense. I eat 2 pizzas myself, so is every individual a team at a company?
elric 6y ago
If you're interested in team sizing, dynamics and communication streamlining, you might be interested in the book Team Topologies by Matthew Skelton. It's an (admittedly opinionated) approach that attempts to solve some common issues with (software and ops) teams.
ipi 6y ago
Really like the article. How do you approach a reverse situation. Where you are working with a small team and there are lot of moving pieces. I work for a small org which builds and maintains their own in-house software. It's not a single product, more of a duct tape of tools. Given a team size of 10 people and ~50 projects, like a bunch of cli tools, web applications, desktop applications, written by many people and passed down legacy stuff, how would one organise the team and drive the development effort.

214 points by kislayverma 6y ago

qznc 6y ago

Another issue in big companies: There are obvious inefficiencies as autonomous teams do redundant work. Some things should be centralized (eg payroll) but others not (eg design). Where to draw the line? For example, should autonomous teams create their own build tool chains?

undro 6y ago
This is the exact dilemma described in "High Output Management." Corporate organization is the art of deciding what to centralize and what to decentralize.

scribu 6y ago

The post makes a good case for why it's a bad idea to split a business problem into slices. Even though you have multiple small teams, they still need to closely coordinate with each other. But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?

thablackbull 6y ago
> Even though you have multiple small teams, they still need to closely coordinate with each other. That's what a competent manager/management is for though.
- smitty1e 6y ago
  #DingDingDing And perhaps the Product Owner vacuum is filled in the sequel mentioned above. The other point I was awaiting was documentation. Thank you to the one who at least threw a ransom note into the wiki. My software archaeology project would be impossible otherwise.
- qznc 6y ago
  Not if management implies non-technical. Maybe an architect role would describe it better.
kislayverma 6y ago
I'm still writing it :)
huffmsa 6y ago
It's a bad idea when the slices aren't independently achievable. The military analog is the fire team (3-4 ppl) or the squad (5-14 ppl), depending on how hungry they are and what the current theater demands. Squads can be assigned multiple discreetly accomplishable objectives. Each squad is assigned to secure a different building on a street, for example. No one squad is necessarily codependent on the success of the other squads to meet it's own objective, but when you pull back a level, overall organizational success (securing the neighborhood, winning the fight in the city, winning the war) is dependent on the success of all of the squads. The article argues, and I agree, that as a company grows, it's easy to shift from discrete squads to assembly line squads. Eg data ingestion => data transformation => data delivery. Platoon / company level objectives, not squad level ones. I have the analogies, but not necessarily and better solutions.
rapht 6y ago
> The post makes a good case for why it's a bad idea to split a business problem into slices. Why it's a bad idea is indeed demonstrated. But why it happens in practice is not just to obey the "small team" mantra. It's also because as organizations and products mature, the law of diminishing returns kicks in: once easy gains have been made, achieving more gains requires tackling more complex problems - either because they are actually more complex in themselves, or because of the environment has become more complex. > Even though you have multiple small teams, they still need to closely coordinate with each other. > But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck? That complexity actually means that whatever the way you organize, you're going to have more people involved. That's when you need good managers - what I call a good manager is not only competent to manage their own team, they're also good at making their team play in a more global picture without necessarily having a boss telling them to do so.
- pico303 6y ago
  These are great points. I disagree with a lot of this article, because it oversimplifies the problem without considering things like this. Another related problem it forgoes discussing is the idea of planning. Once these problems get harder, the need for people to sit down and design a solution grows, sometimes exponentially. Yes, you need good communication, but you also need something to communicate and agree on. How many small teams in big orgs have even a simple design doc to work from?

easymodex 6y ago

The term "two-pizza" teams is always weird to me, like how can you get anything done with only 2 people on the team.

chrisseaton 6y ago
Pizzas in the US are pretty huge - they’re not like a classic pizza for one person as in Italy. I think a two-pizza team is up to about sixteen people.
- bengale 6y ago
  Thats a big pizza.
  - chrisseaton 6y ago
    Yes two pizzas cut into eight each getting a very large slice.
  - huffmsa 6y ago
    16" pizza. You won't get a whole meal out of it, (16 total slices, 400in², 25in² per slice), but you'll fuel everyone for a few hours.
    - rzzzt 6y ago
      Metric-land reporting in: it is possible to finish a 32 cm pizza on your own (12.6"), but the 45 cm ones are definitely multiplayer material (17.7").
      - randallsquared 6y ago
        Well, "thin crust" vs "deep dish" is a pretty huge difference, too. Pizza Hut has or had a "personal pan pizza" that's 15cm or so and considered a meal by itself.
        6y ago

redredrobot 6y ago

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.

DonHopkins 6y ago

Too many "pineapple" team members!

xvector 6y ago

All this discussion is doing is making me crave pizza and making it mighty hard to stay on my diet...

stef-13013 6y ago

https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month

lilcodedummy 6y ago

I don't really agree overall. Yes I understand a "two pizzas" team isn't perfect and does introduce new problems comparatively to whats its replacing, but when you look at the alternative which you call the "Autonomous team mission" you have a even worse set of problems.

jnwatson 6y ago
I'm imagining a dozen tiger teams all with write access to all the code repos, all with potentially non-aligned goals. That sounds like chaos to me.

jeremiahlee 6y ago

This is similar to my experience at Spotify, where I had similar takeaways: https://www.jeremiahlee.com/posts/failed-squad-goals/ https://www.jeremiahlee.com/posts/failed-squad-goals/

ChrisMarshallNY 6y ago

I feel that it really all comes down to good first-level management, and retaining engineers longer than 18 months (see "good management," above). I don't think there's any "silver bullets." Humans, are, well...human, and that means there's a lot stuff like emotions, personal motivations, ambition, self-doubt/confidence, team dynamics, etc. That requires managers that don't just follow buzzwords, but understand the humans they lead, and act as shields between the employees and upper managers that aren't very good at managing humans. Armies run on their sergeants. The Captains, Majors and Colonels are necessary to implement strategy, and convert into tactics, but if you can't keep your teams trained, focused, and motivated at the sharp end of things, the finest generals in the world won't be able to take on a playground full of toddlers with water pistols. But then, that's just my experience and opinion. YMMV.

maps7 6y ago

My ideal setup: Small teams that own and are responsible for products. Teams expose any information they need to share via APIs (including data for reports) Teams consume any information they need via other team's APIs. My experience: Teams that have 9-12 people on them, all working on different things/products, people external to the team completing some tasks that the team can't do, struggles to prioritize work since there is so many work streams coming into the team, members moving from one team to another, work moving from one team to another

jshawl 6y ago
My experience with this has been that when teams dissolve, new apis are created on top of the existing apis to avoid making changes to the original api. Debugging a production issue now involves a lot of finger pointing about which API is working correctly, and which one needs "the fix".

lnsru 6y ago

Maybe there are too many managers, that should be elsewhere. Because management is money and glory and this attracts wrong kind of people. And then all the adventures and problems with management start. Engineers, on other hand, with technical experience and some charisma are hard to find. These are doing well as solo entrepreneurs.

pjmlp 6y ago
Not every country way of doing things is that rewarding for solo entrepreneurs and if one doesn't want to be dragged into management they need to be willing to fight against it at every opportunity, because on most companies it is not natural not wanting to be promoted.

pm 6y ago

The OP is describing Conway's Law, and shows that half the battle is being able to define the problem space in a way that minimises communication and maximises utility. As such, it could be inferred that beginning with a monolithic organisation, and splitting off a new team at the appropriate time when a useful problem space had been defined could be a possible best practice, assuming the organisation was flexible enough. Food for thought, at least.

kislayverma 6y ago
That is well put, and I'm going steal some of those words in the follow-up I'm writing. I essentially feel that teams should grow when tech and process initiatives have led to creation of a whole new problem space that can be explored independently. Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
- pm 6y ago
  Thanks! Indeed, it's the interfaces that are hardest to define. I don't know a good heuristic to determine it I'm afraid - everything I've ever done was on intuition.
hinkley 6y ago
I think in general we underestimate the power of the B-tree, and this is but another example.

bitwize 6y ago

The problem described in the article is one the industry has developed a solution for: SAFe, which is explicitly designed to help small teams align their goals and yeah I can't finish this with a straight face.

jrott 6y ago
Haha SAFe when you want the worst of all worlds around how to setup software development teams. More seriously SAFe is trying to solve a real problem but to actually solve it involves much deeper organizational change because of Conway's law then most people are comfortable with.

beaker52 6y ago

At the company I work at, we're definitely not autonomous. If as a team we have a goal, as a dev, I don't know what it is. We have roadmapped (read: itineraried) work items, basically handed to our team to produce. Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work. Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it. But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_. Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.

cygned 6y ago
> Well, as devs, we have specific feature requirements > Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery. That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management. I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?
- waheoo 6y ago
  I actually prefer a systems lifetime as the 4th dimension. Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)

marcinguy 6y ago

Great article. Looking for some bright minds, agile minds opinions how one should structure and how should Security Team work in an agile organization (100 devs). Where I agree with the article, for software dev, I am not sure if this will be applicable to Security Teams. Security Team ideally should deliver "security" of the company, however team cannot do it alone, we rely on other teams (devs for code, devops for infra), employees (phishing) and also need to collaborate a lot. How would you tackle Security and Security Team in agile organization? Thanks,

allendoerfer 6y ago
I think a company cannot run only on teams delivering features. There will always be some functions like HR, legal or sales. I think security fits in there nicely, it is quite similiar to compliance. A security team is not delivering security by itself, it is more like an HR department trying to prevent workplace harassment or a legal team trying to prevent GDPR violations. You might also think of it not as a team at all, when you are consulting for other teams, you are delivering features as part of that team.
inerte 6y ago
At a higher level Agile is about delivering value end-to-end as soon as possible, repeated a lot of times. The iterative part is important, because you're supposed to be measuring and learning based on past deliverables. I don't know how your company organizes the security teams, but both at Yahoo and now at GoDaddy the security folks delivered a lot of software. Code scanners, patches rollout, monitoring, etc... I agree you can't exactly deliver phishing protection, but for example I've seen fake phishing emails being sent by executives, and then the security team measures if employees are taking the bait. You do that every once in a while, measuring if things are improving or not. Maybe there are other angles you can use to approach how you measure the value your team delivers.

mannykannot 6y ago

The basic premise behind two-pizza teams, at least as given here, is flawed. While it is true that if a task requires limited communication, a small team could complete it quickly, most significant tasks require more than a little communication, in which case, adopting a structure that limits it is counter-productive. If you have a small team whose members all have a deep understanding of the goal, the strategy for achieving it, where the problems will be, and what trade-offs are possible, then they can achieve a lot with the minimal necessary communication, but you do not get any of that for free just by making small teams - that would just be cargo-culting the issue.

shay_ker 6y ago

> What might have been a “Data Delivery Team” charged with delivering fresh data to customers unfortunately becomes “Data ingestion Team”, “Data processing Team” and “Data Release Team” (real world example). This split is eerily similar to Backend, UI, Ops, which is the very thing the author criticized earlier in the post. It sounds like the teams they ended up with just weren't cross-functional teams. There's another tell, too: "Data-Delivery". What does that even mean? From my perspective, I have zero clue. There's likely a dozen different ways to slice that up into discrete sets of user experiences of features. And then you can organize cross-functional teams around those experiences, like: reliability, visualizations, integrations, etc. Of course, things aren't always that clean. The real world is much more murky.

kislayverma 6y ago
>It sounds like the teams they ended up with just weren't cross-functional teams. You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here. "Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.
- shay_ker 6y ago
  I'm interpreting the core issue as two pizza team == organized around OKRs Whereas the better way to think about it is two pizza team == cross-functional, lean teams Seems like an issue around semantics

annoyingnoob 6y ago

Do you mean to tell me that 9 women cannot have a baby in a month?

MattGaiser 6y ago
"But we need that baby in a month. How many women/expensive consultants do you need?"
- jasonm23 6y ago
  3 years later, all the consultants and contract workers have moved on to different jobs at different companies. The sponsors in the enterprise client have all moved on. No one even knows the team was supposed to produce a baby.
  - contingencies 6y ago
    A middle manager makes their career out of being present at the time, publishing their distilled wisdom in a best-selling tome, translated in 50 languages: Business at the speed of bacteria.

deleted 6y ago

[deleted]

ukj 6y ago

The observation that this pattern emerges recursively is totally valid. Just as we refactor code and add layers of abstraction, so we refactor org structures when certain teams become hotspots. The crux of the matter is that as organisations scale up different teams have different "runtime complexity" (if you will). Scaling up input 2x produces 2x more work for some teams and 100x more work for other teams. And then we have ourselves the "how do we scale workloads?" discussion on our hands again. If your workload is stateless - you scale it horizontally (more humans). If you workload is stateful you scale it vertically. I don't know how to scale humans vertically.

jkingsbery 6y ago

I like this article a lot, it's a pretty good summary of the problem. > Most developers, especially in larger organizations, complain about meetings, I would quibble with this though - I think this depends a lot on your manager, your project, and some other things. I've been part of start-ups that have a daily standup that lasted over an hour and involved everyone in the company (~20 people), and the time in my career I had the fewest meetings was when I worked for Dow Jones (not a FAANG, but also not a small company). My experience working for a few different start-ups is that start-ups have as many meetings, they just tend to be more ad-hoc, less formal, and might not always involve a formal Outlook Calendar invitation.

JamesBarney 6y ago

> The concept of the “two pizza”/”autonomous” team arose from attempts to minimize communication between multiple teams and empowering a single team to be in complete control of delivering customer value. > Before this idea gained popularity, the most common way of organizing teams was in terms of Backend, UI, DBA, Ops etc.. Building any feature required a lot of communication, collaboration, and alignment between all these groups. I always thought this was called cross-functional and saw the term way before anyone started talking about two pizza/autonomous teams.

Milank 6y ago

I remember when we were expecting our first child, we went through a 'parenting school' - a course where all kinds of doctors, psychologists, nurses, nutritionists, etc. came to teach us, future parents, about parenthood. Since it's not maths, a lot of them had different views on different things, which confused people. Until one day, one future mother, all anxious (if you're a parent, you'll understand the psychological state of expecting a first baby in the next month or two) asked almost angrily: "You people give us conflicting advises, what should we do? How do we do good when even you don't agree what's good between each other???" The answer was simple: "We give you all views, all options. It's up to you which one you think is right and good for your kid. That's what parenting is. That's why we are all different people." Same thing works for companies. Leadership shapes the company. There is no one-size-fit-all strategy. What works for one company, doesn't work for another. Two pizza team size can work somewhere. Somewhere else something else will. People tend to look for manuals, instructions on how to do things, expecting that someone will write it all down and they just need to do what's written. From time to time, we get to hypes about something (check under microservices for example), everyone use it because it's popular, fancy, buzz word. Without thinking - do we really need this? It's like an epidemic (or pandemic?) of paper pushers, no one wants to take responsibility. To take action. And there is no responsibility if you do things as it's written in the manual, right? Best methodology is - work with your team. Talk to the team. Know how they breathe. And they will tell you what to do, how to organise them, which methodology to use. "Take care of your people and they will take care of your business."

yeswecatan 6y ago

I'm actually going through this at my current job. We have a team of 8 where some report to essentially the head of the team and some report to me, a "lead", who reports to the head. This makes absolutely no sense to me. I'm hearing that things are setup this way because having 7 direct reports is too many. Even if we ignore the weird org chart, having say two teams of four doesn't make sense to me if everybody is working on the same things. Can someone please explain if I'm thinking of this the right way or not?

blahbhthrow3748 6y ago
7 direct reports actually seems fine if this person's role is primarily management. If they're also doing some combination of tech lead/product stuff they may want fewer reports to free up time for non-management activity. Delegating some subset of direct reports seems less like it's about product or technical direction and more about aggregating and filtering management concerns. Presumably the whole team still works on the same thing and plans their work together, it's just that you do half the 1:1s, deal with what you can, and kick things up the chain if you can't.
- yeswecatan 6y ago
  I guess I'm jut having difficulty defining what my team does vs. others that are on the same larger team. There's also a weird extra level on the org chart where ICs on my team and ICs on the head of the team are on different levels on paper.
dbish 6y ago
7 direct reports is very normal for a manager. One thing to dig into is whether they think 7 direct reports is too many for you (as opposed to anyone) and they just don't want to say it directly. This could be because they think you are spending too much time on IC tasks (coding) and won't be able to handle that many, you're too junior (recently started managing), or there are other issues going on with you or the other lead that your senior management hasn't been explicit about. You can do this constructively by asking more about what they'd be looking for to show that you could handle that scope and how to set goals/improve to get there.

Reimersholme 6y ago

I wish I had read the last to sentences first; "How can we scale our teams to deliver on more and more ambitious goals while retaining their autonomous nature? I will offer some opinions on this in the next post." So the whole meat of the article I expected is nowhere to be found.

SV_BubbleTime 6y ago

When I was at Amazon, it was full of two pizza teams. Seems like a good enough strategy to me. I don’t know that necessarily cuts down on “this meeting should’ve been an email”. And I would often walk past conference rooms to see the TV showing four remote meetings of other two person teams. Which means in that meeting was a ten pizza meeting, IDK if that was the plan.

rustybolt 6y ago

Weird term, pizzas are usually too small to feed someone. Or do they have giant pizzas in the US?

goldenchrome 6y ago
Standard pizzas from any chain in the US are about 12” diameter with 8 slices. A pizza can feed 2-3 people comfortably.
- rustybolt 6y ago
  That's about the same as in Europe. I can't eat a pizza for dinner, I will be hungry after it, and I'm not even very big (about 6 foot, which is below average, and < 160 lbs)... (Maybe because I sport more than average?)
  - goldenchrome 6y ago
    A 12" cheese pizza has about 2000 calories. A 6' tall 160 lb man who does vigorous exercise 5+ times a week needs 2500-3000 calories per day to maintain weight. So if you're still hungry it's because you didn't eat much else all day. Or you're training like an Olympian. Or you're on your way to getting fat. Or European pizzas are low in calories.

dr-detroit 6y ago

Oof I was just fantasizing about downsizing from my 6 pizza team. Its like people go out of their way to be hard to work with.

Lammy 6y ago

I'd prefer to be on a "zero pizza" team, as in a team that doesn't get pulled into crunch-time at all.

bilater 6y ago

This is exactly what I saw at Amazon. 6 teams working on the same thing, massive communication overhead/hoops to go through to get accesses, too many PMs bickering and trying to get buy in from other stakeholders which slowed down the whole process.

chaosbutters314 6y ago

two-pizza teams makes no sense. I eat 2 pizzas myself, so is every individual a team at a company?

elric 6y ago

If you're interested in team sizing, dynamics and communication streamlining, you might be interested in the book Team Topologies by Matthew Skelton. It's an (admittedly opinionated) approach that attempts to solve some common issues with (software and ops) teams.

ipi 6y ago

Really like the article. How do you approach a reverse situation. Where you are working with a small team and there are lot of moving pieces. I work for a small org which builds and maintains their own in-house software. It's not a single product, more of a duct tape of tools. Given a team size of 10 people and ~50 projects, like a bunch of cli tools, web applications, desktop applications, written by many people and passed down legacy stuff, how would one organise the team and drive the development effort.