Independence, autonomy, and too many small teams(kislayverma.com)
kislayverma.com
Independence, autonomy, and too many small teams
https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/
181 comments
> 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?
> 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?
Johanna Rothman, in 'Manage It', suggests these dimensions to what we usually think of as the 'triangle': features, quality, schedule, cost, team size, team members, and resources (infra, sw, etc...)
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.)
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.)
To be honest, most "deadlines" are really just cost boundaries in the first place.
If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
> No one ever stops to ask whether we're having the impact we anticipated
"Signs you’re working in a feature factory" sounds relevant to you. https://news.ycombinator.com/item?id=22335738
"Signs you’re working in a feature factory" sounds relevant to you. https://news.ycombinator.com/item?id=22335738
I think he knows he's working in a feature factory. What's hard is knowing what you can do to change it.
Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value.
What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.
Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value.
What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.
Both your comment and the article sound a bit like the inverse of the problem addressed by "Domain Driven Design".
In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.
But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.
I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?
In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.
But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.
I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?
No, this is not “agile”. This is what agile critics think agile is...
This is why I hate Agile. It's much harder to convince management that they won't be getting a pre-determined set of functionality by a certain date (we will have feature x,y and z developed by October 13th) than to convince a team to stop doing upfront planning and design. So almost every project I've been on that was "Agile" was actually waterfall sans upfront planning and design.
IMO, the core principle of agile is “early feedback means smaller corrective action”. Everything else is just process to achieve that without running afoul of the evil twin “noisy feedback means constant corrections hunting for the solution.”
Agile goes wrong when you don’t get and use good feedback.
You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.
Agile goes wrong when you don’t get and use good feedback.
You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.
My understanding about Agile is planning ahead for the next step instead of planning the whole project before starting and then hoping all your assumptions turns out true.
The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
I think the business concept missing from Agile is investment/ROI and risk. Until budgeting processes are also Agile, everyone will be operating on the idea that "we paid $x to get 'y', and now you aren't giving us 'y'. What the hell?"
Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
> I hate "sprint"
Me too. It sounds exhausting.
Me too. It sounds exhausting.
Right and the fundamental issue is that the next step in agile is an iteration which occurs over 1-4 weeks. But most companies "iterations" are quarterly or yearly. So every quarter or year the business plans and discusses what money they want to spend and what they want to spend it on. And quite reasonably executives are going to want to know what they are purchasing with that budget allocation.
I think this is where the "beyond budgeting" movement comes in.
See: https://bbrt.org/what-is-beyond-budgeting/
See: https://bbrt.org/what-is-beyond-budgeting/
The key in communicating is that you give a roadmap, but not put the date into the sand.
Following the idea of the iron triangle, with Agile we fix budget and time, but we keep the scope flexible, however, we estimate a scope and refine that along the way.
If you follow an iterative Agile approach like Scrum, given you know your velocity and you have a backlog in good shape, you can work from one milestone to the other.
Following the idea of the iron triangle, with Agile we fix budget and time, but we keep the scope flexible, however, we estimate a scope and refine that along the way.
If you follow an iterative Agile approach like Scrum, given you know your velocity and you have a backlog in good shape, you can work from one milestone to the other.
I'm sure some upper management is fine with "we will work on these features and some of them will be done by December."
But in a lot of organizations upper management asks middle management when those features will be delivered so they can plan client communications or internal teams around that.
But in a lot of organizations upper management asks middle management when those features will be delivered so they can plan client communications or internal teams around that.
who said to skip upfront planning?
I don't know many agile teams that plan and design and estimate the next 3-6 months of work.
It's my understand that would not be considered agile.
It's my understand that would not be considered agile.
I think I just realized the crux of why some folks dislike agile but weren't able to express it and it has to do with the idea of what-is and what-isn't and how much dominance the "isn't" has over the owner of the belief.
If someone tries to get you to believe something and part of that belief is the active suppression of certain types of thought, and those types of thought are what actually make us intelligent. Then in some regards, agile is trying to make us less intelligent. It might be accidental, it might be unintended, but it is there. Agile attempts to create a social norm where certain thoughts are banned. Yet our ability to anticipate and predict the future is one of our largest defining traits.
There are some aspects of agile that have cult like qualities. I think agile has _improved_ many software teams and projects, esp with how those teams approach planning, but it is still important to be cognizant of thoughts that have been removed from view.
If someone tries to get you to believe something and part of that belief is the active suppression of certain types of thought, and those types of thought are what actually make us intelligent. Then in some regards, agile is trying to make us less intelligent. It might be accidental, it might be unintended, but it is there. Agile attempts to create a social norm where certain thoughts are banned. Yet our ability to anticipate and predict the future is one of our largest defining traits.
There are some aspects of agile that have cult like qualities. I think agile has _improved_ many software teams and projects, esp with how those teams approach planning, but it is still important to be cognizant of thoughts that have been removed from view.
I think we work at the same company.
Wow we must have worked at the same place. I could have written this description. I wonder how common it is.
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.
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.
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, ...
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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.
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.
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.
Food for thought, at least.
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.
Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
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.
I think in general we underestimate the power of the B-tree, and this is but another example.
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
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
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".
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.
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.
This is similar to my experience at Spotify, where I had similar takeaways: https://www.jeremiahlee.com/posts/failed-squad-goals/
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?
But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
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.
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.
> 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.
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.
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?
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?
I'm still writing it :)
> 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.
That's what a competent manager/management is for though.
#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.
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.
Not if management implies non-technical. Maybe an architect role would describe it better.
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."
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."
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.
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.
The term "two-pizza" teams is always weird to me, like how can you get anything done with only 2 people on the team.
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.
Thats a big pizza.
Yes two pizzas cut into eight each getting a very large slice.
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.
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").
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.
Aye, you go to Chicago and you're talking 1-2" of depth of mostly cheese on these pies. Literal pounds of pizza.
A pizza 2 inches deep? Surely there is another name for such a meal.
As far as I can tell [Chicago-style | deep dish] pizza[1] is uniquely specific in describing such a preparation. No obvious alternative Pie-, Tart-, or Flan-based descriptor showed up when casually searching.
[1]https://en.wikipedia.org/wiki/Chicago-style_pizza
[1]https://en.wikipedia.org/wiki/Chicago-style_pizza
> A pizza 2 inches deep? Surely there is another name for such a meal.
Yes, it's a tourist trap meal. We here in Chicago really do like deep-dish pizza, but many of the more famous brands exaggerate the thickness because it seems as though tourists prefer it that way. A typical Chicago resident isn't going to buy one like this more than once every few years, unless they have visitors that insist on it.
You eat it with a fork and knife. Despite the huge amount of cheese and sauce, a good one will have a really crunchy crust and it should be so good that you consider it one of the best parts of the pizza.
The flavor/preparation/ingredients are what make a good Chicago-style pizza and not the thickness. In more residential areas, you'll have pizza shops where the deep dish pizza is no more than 1 inch, which is really what a Chicago resident buys for themselves (but the thin crust is most definitely purchased more frequently).
Yes, it's a tourist trap meal. We here in Chicago really do like deep-dish pizza, but many of the more famous brands exaggerate the thickness because it seems as though tourists prefer it that way. A typical Chicago resident isn't going to buy one like this more than once every few years, unless they have visitors that insist on it.
You eat it with a fork and knife. Despite the huge amount of cheese and sauce, a good one will have a really crunchy crust and it should be so good that you consider it one of the best parts of the pizza.
The flavor/preparation/ingredients are what make a good Chicago-style pizza and not the thickness. In more residential areas, you'll have pizza shops where the deep dish pizza is no more than 1 inch, which is really what a Chicago resident buys for themselves (but the thin crust is most definitely purchased more frequently).
I nominate pound as the unit of pizza.
[deleted]
It depends. I'm not a big eater but I've at times ordered a 45 cm pizza. While I wouldn't finish it all at once, I'd probably finish it in half a day or so. Usually this was after not eating for at least 24 hours, or after enjoying a particular substance. It definitely did not leave me feeling happy in the longer term though.
> (16 total slices, 400in², 25in² per slice)
I think you did the math wrong?
Area is pi x r^2, which for a 16" pizza would be pi x 8^2 = pi x 64, which is right about 200in^2
A few of the pizza places around here offer 20" pizzas, which would be pi x 10^2, or pi x 100 = 314in^2, which is actually big enough to feed a couple people.
That said, whenever I read "two-pizza team" (a term I've never heard before), I assume that means 4-5 people at most.
I think you did the math wrong?
Area is pi x r^2, which for a 16" pizza would be pi x 8^2 = pi x 64, which is right about 200in^2
A few of the pizza places around here offer 20" pizzas, which would be pi x 10^2, or pi x 100 = 314in^2, which is actually big enough to feed a couple people.
That said, whenever I read "two-pizza team" (a term I've never heard before), I assume that means 4-5 people at most.
Parent post was talking about 2 pizzas. But you're right it's 200in² per pizza.
And a 2 pizza team is the number of people you can feed lunch to with 2 pizzas.
Most people would do 1-2 large slices for a lunch, so 4-8 maybe 10 people is a 2 pizza team.
About the same size range as a rifle squad.
And a 2 pizza team is the number of people you can feed lunch to with 2 pizzas.
Most people would do 1-2 large slices for a lunch, so 4-8 maybe 10 people is a 2 pizza team.
About the same size range as a rifle squad.
discordance(1)
so .. a pizza feeds up to 8 people ... is that the 'regular' size?
When Americans order a pizza, it's typically for a party of 8 people?
When Americans order a pizza, it's typically for a party of 8 people?
The first time I tried to order pizza delivery in Singapore, I asked my friends, "So, how big are the pizzas here?" The answer left me stumped: "Small is six slices and large is eight slices." I retorted that I could easily slice a 6cm pizza into 16 slices and that wouldn't feed us any more than their large pizza. They looked at me kind of funny.
Would it not be more useful to size a pizza in terms of diameter, not number of slices or how many people its supposed to feed? As you point out, a 6cm diameter pizza can be sliced into 16 pieces, but also some people just naturally eat more than others anyway.
C'mon, don't leave us hanging how big was the pizza?
The "large" would have been called "medium" back in the States. I guess "small" would be "personal".
Obviously they cut the pizza into sixths when they feel that they're not hungry enough for eight slices.
That's logic, that is.
That's logic, that is.
It definitely doesn't need to be a big crowd like that. 8 slices, maybe 3 or 4 people if it's a full meal (2 slices / person is probably typical). Leftover slices are good the next day too.
8 slices !== 8 people. Most people I know will eat 2 or 3 slices. You can also save leftover slices.
Only if it’s 8 children.
In Italy we have what we call "family pizzas" which are supposed to be pizzas that are large enough to feed a family. In practice it's double the mass of a normal pizza, so a two-pizzas team would be 4 people (or 2 particularly hungry devs).
In Finland we have family pizzas too, and then there is the extended family pizza, which allows a whole Nokia department to be a two-pizza team: https://translate.google.com/translate?sl=auto&tl=en&u=https...
Well, clearly Italians thrive with smaller software teams
syshum(1)
Two large pizzas feed sixteen people if they're all elderly or trying to strictly limit their calorie intake.
Two large pizzas feed three to four people if they're all under 30.
Two large pizzas feed three to four people if they're all under 30.
Yes id have said two pizzas is a team of 3-4. one veggie and one meat pizza doesn't go that far.
One with pineapple and one without.
Hmm, in my circles usually goes {1 cheese}, {1 cheese, 1 meat}, {1 cheese, 1 meat, 1 veggie}, {2 cheese, 1 meat, 1 veggie}...
I must admit that I hadn't considered vegans, so you might well need to take that into account.
I have generally noticed a "2 large slices" soft limit for people at my work place. Although, my team is generally quite fit and health conscious for folks in their mid 20s.
I'd say 2 pizzas for 6-8 people is totally fine assumption.
I'd say 2 pizzas for 6-8 people is totally fine assumption.
yes - at those bigger "pizza by the slice" joints anything more than 2 slices for lunch will be driven by pizza-induced greed and I definitely won't get any work done afterwards. At dinner post-work I can maybe put away 4 slices...
In the US these are called 'slice pies' which are enormous and not meant (usually) to be ordered whole.
Must be a regional thing; I've never heard the term "slice pie".
Almost all the by-the-slice places I've been to take slices from their large or extra-large pies. The only exception I can think of would be Pinup Pizza on the Las Vegas strip (30 inch diameter pie).
Almost all the by-the-slice places I've been to take slices from their large or extra-large pies. The only exception I can think of would be Pinup Pizza on the Las Vegas strip (30 inch diameter pie).
You'd be surprised to learn that there are many successful two-person companies.
I still always laugh when I read the phrase "personal pizza".
That's what non-US people would call "pizza".
That's what non-US people would call "pizza".
I've spent 14 of the past 18 years outside the US and not encountered that usage.
Perhaps "non-US people" is too broad a term.
Perhaps "non-US people" is too broad a term.
You have not encountered the term "pizza" to refer to a whole pizza, serving as 1 (large-ish) meal for 1 person?
That's really surprising to me, but interesting to hear!
That's really surprising to me, but interesting to hear!
I haven't. A whole pizza as a meal sounds like a task for teenager.
Fascinating. Over here (NL) whenever any group orders pizza's, the default is to just order one for yourself. At 'best' we might make a deal with another person to swap a quarter or half of the pizza. It's definitely not a 'group food' though.
EDIT: well, with the exception of the occasional event/party organizer, but that applies to all foods.
EDIT: well, with the exception of the occasional event/party organizer, but that applies to all foods.
Here (in TW), not only is a pizza a group food, but it's just a component in a meal with other group foods like chicken, fried potato balls, sausages, or noodles, etc.
In fact, US pizza chains struggled here until they started localizing and adding more foods to their menus!
In fact, US pizza chains struggled here until they started localizing and adding more foods to their menus!
In Brazil it's definitively a group thing, specially families. Friday night is pizza night in a lot of homes. I left Brazil 7 years ago so maybe some things have changed, but never once I have ordered a "smaller" pizza for personal consumption. They do exist here in the US, in some restaurants, or even takeout, so I suppose some people order them here.
Because our "pizza" is like three of your pizzas.
Yeah of course, but isn't that generally how it goes with food?
You don't go out to a restaurant and order a "personal salad" or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth).
I get it! It's just a funny idiosyncrasy :)
You don't go out to a restaurant and order a "personal salad" or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth).
I get it! It's just a funny idiosyncrasy :)
Not really. It's a size. You can get extra large, large, medium, small and personal. It's something like 16 in diameter for an extra large, 14 in for large, etc. The personal pizza is around 6 in.
> You don't go out to a restaurant and order a "personal salad"
You sort of do. There is a distinction between salads intended for the table to share, salads intended as a single person;s entree, and salads intended as a single person's accompaniment.
> or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth)
If I saw "personal lasagna" on a menu, I would expect something that was baked as a single portion. Otherwise, I would expect a portion cut out of a larger tray. Essentially, "personal" here is a reference to the size of the unit that was prepared and cooked and not merely the serving size.
Same with pizza. I expect a "personal pizza" to be a complete pizza that is reasonable for one person.
You sort of do. There is a distinction between salads intended for the table to share, salads intended as a single person;s entree, and salads intended as a single person's accompaniment.
> or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth)
If I saw "personal lasagna" on a menu, I would expect something that was baked as a single portion. Otherwise, I would expect a portion cut out of a larger tray. Essentially, "personal" here is a reference to the size of the unit that was prepared and cooked and not merely the serving size.
Same with pizza. I expect a "personal pizza" to be a complete pizza that is reasonable for one person.
[deleted]
Economies of scale, man.
Delivery guy ain't comin to deliver you a 7 inch diameter pizza (about ~17cm). But when they're dropping off 2+ large pizza then it becomes cost effective.
Plus i'm not ordering a single large pizza and eating it all -- cold breakfast pizza is also good, and will serve me all week.
Delivery guy ain't comin to deliver you a 7 inch diameter pizza (about ~17cm). But when they're dropping off 2+ large pizza then it becomes cost effective.
Plus i'm not ordering a single large pizza and eating it all -- cold breakfast pizza is also good, and will serve me all week.
Yeah, they are. They just take electric scooters with delivery boxes on the back since they don't have to take giant pizzas with them :).
Small, competent teams work well. Why do you find that incredible.
(disclaimer: it's my experience. Also, I've only worked for small companies on relatively small projects (a few man-months or man-years), things may be very different in large ones).
(disclaimer: it's my experience. Also, I've only worked for small companies on relatively small projects (a few man-months or man-years), things may be very different in large ones).
He is joking. A two pizza team is 6-8 members.
Indeed. Or when I'm particularly hungry, I need to work alone. That part actually might make sense; people (me) get hangry.
Anecdotally, there is a Russian word with the same spelling which means "a dumb person". There might be a coincidence...
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.
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.
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.
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.
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.
> 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.
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?
Can someone please explain if I'm thinking of this the right way or not?
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.
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.
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.
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.
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,
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,
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.
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.
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.
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.
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.
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.
Do you mean to tell me that 9 women cannot have a baby in a month?
"But we need that baby in a month. How many women/expensive consultants do you need?"
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.
The sponsors in the enterprise client have all moved on.
No one even knows the team was supposed to produce a baby.
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.
> 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.
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.
>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.
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.
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
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
[deleted]
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.
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.
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.
> 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.
> 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.
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.
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.
I'd prefer to be on a "zero pizza" team, as in a team that doesn't get pulled into crunch-time at all.
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.
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.
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.
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?
This is the exact dilemma described in "High Output Management." Corporate organization is the art of deciding what to centralize and what to decentralize.
Weird term, pizzas are usually too small to feed someone. Or do they have giant pizzas in the US?
Standard pizzas from any chain in the US are about 12” diameter with 8 slices. A pizza can feed 2-3 people comfortably.
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?)
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.
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.
Too many "pineapple" team members!
two-pizza teams makes no sense. I eat 2 pizzas myself, so is every individual a team at a company?
All this discussion is doing is making me crave pizza and making it mighty hard to stay on my diet...
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.