
Independence, autonomy, and too many small teams - kislayverma
https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/
======
beaker52
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.

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

~~~
devtul
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!)

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

~~~
jkarneges
> I hate "sprint"

Me too. It sounds exhausting.

~~~
undro
Uncle Bob has the best quote on this subject (in _Clean Agile_ ): "A software
project is a marathon, and in a marathon you don't want to sprint."

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

~~~
pdelgallego
The Two-pizza team concept is a very small part on how Amazon works. A few
others on top of my head.

\- Enable high-velocity decision making: Defining clear tenets that act as the
north start for decision making at team level, and two-way doors thinking.

\- Establish how you measure success, and how does relate to the goals of the
organisation.

\- Achieve team independency is a key factor, and having strong mechanisms
such as the "away teams" concept, "communication is terrible" mental model and
reducing cognitive overload by relying on platform teams

\- Nominating a single-threaded owner for programs and business outcomes.

\- Articulate how the organisation works across teams using mechanisms such as
bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...

~~~
closeparen
>"communication is terrible"

My company has brought in a lot of Amazon people and ideas, but unfortunately
we go this one backwards. "Communication is great." Managers are explicitly
encouraged to structure projects to maximize cross-team and cross-org meeting
hours.

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

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

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

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

------
jeremiahlee
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/)

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

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

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

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

~~~
test1235
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?

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

~~~
feteru
C'mon, don't leave us hanging how big was the pizza?

~~~
paulmooreparks
The "large" would have been called "medium" back in the States. I guess
"small" would be "personal".

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

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

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

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

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

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

------
stef-13013
[https://en.wikipedia.org/wiki/The_Mythical_Man-
Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)

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

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

~~~
MattGaiser
"But we need that baby in a month. How many women/expensive consultants do you
need?"

~~~
jasonm23
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
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_.

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

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

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

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

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

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

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

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

------
qznc
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
This is the exact dilemma described in "High Output Management." Corporate
organization is the art of deciding what to centralize and what to
decentralize.

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

~~~
goldenchrome
Standard pizzas from any chain in the US are about 12” diameter with 8 slices.
A pizza can feed 2-3 people comfortably.

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

------
DonHopkins
Too many "pineapple" team members!

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

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

