The fundamental misunderstanding in Team Topologies

TurtleSec
1
@patigallardo.bsky.social
Turtle
Sec
The fundamental misunderstanding in
Team Topologies

TurtleSec
2
Content warning:
I really don't like this book

TurtleSec
3
I have 2 threads on Mastodon
with close to 200 posts in them
on exactly what
I don't like about this book

TurtleSec
4
"I posit that this book is [a] result of
a bunch of folks
who are personally
struggling to understand
how anything is ever built
by anyone."
Past Patricia, May 23, 2024, Mastodon

TurtleSec
5
The fundamental misunderstanding in
Team Topologies
NDC OSLO 2025
Patricia Aas
Turtle
Sec

TurtleSec
6
whoami? Patricia Aas
Programming in C++, C, Kotlin, Java, TypeScript, JavaScript, Python…
Everything from React to assembly, for 25 years.
Built browsers, physical products, webapps, APIs, backends, build syﬆems…
Previously : Vivaldi, Cisco Systems, Knowit, Opera Software
Currently : TurtleSec
Pronouns: she/they
Turtle
Sec
In the past few months I've done
assembly, Kotlin, C++, C and React
I'm not saying this to brag
I'm saying this to say:
I know how to ship products

TurtleSec
7
What is the fundamental thesis of the book?
A) The optimal architecture is micro services
B) We can force an organization to produce micro
services by re-org'ing it and restricting
communication

TurtleSec
8
Conclusion, Team Topologies
"In other words, restructuring teams and facilitating (or
potentially deliberately limiting) communication between
teams"

TurtleSec
9
Chapter 2, Team Topologies (similar quote in the conclusion)
"A simple way to restrict communications is to move two
teams to different parts of the ofﬁce, different ﬂoors, or even
different buildings."

TurtleSec
10
Chapter 2, Team Topologies
"[M]any-to-many communication [like a chat] will tend to
produce monolithic, tangled, highly coupled, interdependent
systems"

TurtleSec
11
FYI
Using "monolithic" as a synonym for anything they don't like
is pervasive throughout the book.

TurtleSec
12
"Fast ﬂow requires restricting communication between teams"

TurtleSec
13
TurtleSec
This is ﬁne?
13

TurtleSec
14
"We need to look for unexpected communication and address
the cause"

TurtleSec
15
UX pattern: Pave the paths

TurtleSec
16
Quick Recap

TurtleSec
17
Re-Org the Re-Org
Stream, platform,
enabling, complicated
Smallest unit, 5 or 8 or 9
or 15 people
Cybernetics
(Kubernetes for people)
Collaboration, XaaS,
facilitating
Code, docs, versioning,
wiki, chat, status
"Inverse Conway
Maneuver"
Team Types
Team Type
Types
Comms

TurtleSec
18
@patigallardo.bsky.social 18
TurtleSec
Before we can begin,
we need to strip away Other People's Thoughts

TurtleSec
19
Most of the book is quoting other people
and/or listing up common practice
Because of this, 90% reads like an attempt at a textbook
for folks who don't know anything about tech organizations.
However, their own ideas are hiding in there,
and they are harmful
Other People's Thoughts?

TurtleSec
20
Most of the book is regurgitating Other People's Thoughts
That could belong in a text book for a university course
What is actual original thought in the book?
20
These little guys are the only Original Thoughts in the book
But they play a crucial role in the tiny Original Thought in there
Unfortunately, not even they are fully Original
TurtleSec
What are Original Thoughts?

TurtleSec
21
So let's name them
Dunbar's
Number
Conway's
Law
"The Spotify
Model"
Cognitive
Load
Re-Org
No talking
You can't handle thinking
No talking
Architecture by Re-Org
No talking
You can't handle people
No talking
"[...] something must be wrong if
the teams are communicating."

TurtleSec
22
Problem?
Mis-characterization
Conway's Law TurtleSec

TurtleSec
23
Example:
Conway: "Because the design which occurs ﬁrst is almost never the best possible,
the prevailing system concept may need to change. Therefore, ﬂexibility of
organization is important to effective design."
Team Topology: "Conway's law tells us that we need to understand what software
architecture is needed *before* [their emphasis] we organize our teams"
They constantly misrepresent what Conway said

TurtleSec
24
Conway's Law
"[O]rganizations which design systems (in the broad sense used here) are
constrained to produce designs which are copies of the communication structures
of these organizations."
Wikipedia article on Conway's Law
What is "Conway's Law"?

TurtleSec
25
"The basic thesis of this article is that organizations which design systems (in the
broad sense used here) are constrained to produce designs which are copies of the
communication structures of these organizations. We have seen that this fact has
important implications for the management of system design. Primarily, we have
found a criterion for the structuring of design organizations: a design effort should
be organized according to the need for communication.
This criterion creates problems because the need to communicate at any time
depends on the system concept in effect at that time. Because the design which
occurs ﬁrst is almost never the best possible, the prevailing system concept may
need to change. Therefore, ﬂexibility of organization is important to effective
design."
How Do Committees Invent?, Melvin E. Conway, 1968
What did Conway actually say in that article?

TurtleSec
26
● "a design effort should be organized according to the need for communication"
● "the need to communicate at any time depends on the system concept in effect at
that time"
● "the design which occurs ﬁrst is almost never the best possible"
● "the prevailing system concept may need to change"
● "ﬂexibility of organization is important to effective design"
How Do Committees Invent?, Melvin E. Conway, 1968
Important points Conway makes

TurtleSec
27
Problem?
Mis-understanding
Cognitive Load TurtleSec

TurtleSec
28
This paper coined the term, and it has zero relation to how it is used in the book.
Cognitive Load is basically the effort it takes to think about how to solve a problem,
rather than just trying stuff.
Instead the book uses the term as a thinly veiled condescension, implying that
team members are just not capable of understanding Big Things. It also gets used
as an excuse to split up teams or hinder communication.
Cognitive Load During Problem Solving: Effects on
Learning, John Sweller, 1988

TurtleSec
29
Dunbar's Number TurtleSec
Problem?
Mis-application

TurtleSec
30
"This number was ﬁrst proposed in the 1990s by Robin Dunbar, a British
anthropologist who found a correlation between primate brain size and average
social group size. By using the average human brain size and extrapolating from
the results of primates, he proposed that humans can comfortably maintain 150
stable relationships." Wikipedia, Dunbar's Number
Dunbar's Number is made up

TurtleSec
31
● 5 people: close personal relationships [family, close friends]
● 15 people: deep trust [probably still family and close friends]
● 50 people: mutual trust [probably some work colleagues?]
● 150 people: people whose capabilities we can remember [colleagues,
acquaintances]
Even if it wasn't, it wouldn't be your team members

TurtleSec
32
Paraphrased
Dunbar's number says we can only trust 5 people deeply*
Psychological Safety** concludes that trust is critical for team excellence***
Therefore team excellence requires a team size of 5-9 people.
Why 9? Because Amazon and something about 2 pizzas.
Later they say 8. No reason provided.
Problem: Dunbar's number is unusable, psychological safety has nothing to do
with team size, and the size of 2 pizzas is not science.
Typical problematic reasoning
Common throughout the book

TurtleSec
33
Problem?
Mis-interpretation
"The Spotify Model" TurtleSec

TurtleSec
34
I joke that this book is what would happen if "The Inverse Conway Maneuver" and
the Spotify blog posts had a baby.
However:
1. Spotify didn't use "The Spotify Model"
2. They had really bad results from when they tried
3. They were trying to solve a problem you don't have: Hyper Scaling a Tech Org
https://www.jeremiahlee.com/posts/failed-squad-goals/
Even Spotify didn't do The Spotify Model

TurtleSec
35
TurtleSec
There are more architectures than "monolith" and "micro service"
The fact that they don't know that, is a Big Problem

TurtleSec
36
Is the optimal architecture micro services?
This is just silly.
The optimal architecture for your system
depends on your circumstances.
You know your system better than anyone.

TurtleSec
37
Can we force an organization to produce microservices by
restricting communication?
Probably.
But:
A) Organizations can produce microservices without force
B) Restricting communication is harmful

TurtleSec
38
Conceptually, what
is this book?
38
TurtleSec

TurtleSec
39
TurtleSec
What if…
We took
everything ever
written about
software dev,
shook it a bit,
and copy pasted
it into a book?
This book is
clearly an
Introduction to
Modern Tech
Orgs for
Managers

TurtleSec
40
Anyone who needs to read this book
to understand How Tech Orgs Work,
does not have the requisite knowledge
to perform any kind of re-org.

TurtleSec
41
TurtleSec
If we force
people to stop
talking to each
other,
while making
sure their
products have to
collaborate,
what would they
build?

TurtleSec
42
TurtleSec
Team API: are you made of money?

TurtleSec
43
TurtleSec
How do you Get Good?

TurtleSec
44
TurtleSec
You Know Me
Getting shit done in an
org is all about the
people you know.

TurtleSec
45
TurtleSec
Who me?
The people that like
you, because you show
up for them.

TurtleSec
46
Show up?
Help your colleagues,
outside your team, when
they need a hand.

TurtleSec
47
Answer
When they know you, they
will call you.

TurtleSec
48
DIY
If they can't do Thing, they
might be able to guide you
doing Thing.

TurtleSec
49
Cheat code for being effective,
and actually getting shit done in an org
Help people

TurtleSec
50
TurtleSec
How do we Get Good?

TurtleSec
51
Wha have we learned?
51
TurtleSec
Agile
User Experience
Product Management
To build good thin s:
we need to tal to others
DevOps
To build thin s fas :
we need to tal to eac other

TurtleSec
52
TurtleSec
Good Talk.
The problem isn't that we talk
too much
It is that we don't talk enough
with the right people

TurtleSec
53
Empathy.
People don’t «develop»
empathy.
The normal mechanism is:
we empathize with the
people we know.

TurtleSec
54
TurtleSec
Hang out?
Get to know your users
Watch them use the
product
Show you care

TurtleSec
55
Trust that your people will do
what they need to do
to Get Shit Done
As the kids say: Let 'em cook TurtleSec
55

TurtleSec
56
We will need to change the system
To change it, we have to understand it
TurtleSec
56

TurtleSec
57
We should talk more.
We should draw out the system.
We should know what others are doing.
TurtleSec

TurtleSec
58
- But I don't wanna.
- Me neither, friend.
But I want to be good at this.
TurtleSec

TurtleSec
59
TurtleSec
You don't need small talk
You just need to help people
Be interested.
Care about them.
All of them.

TurtleSec
60
TurtleSec
Truth is: we don't know.
It seems to be about creating stuff
that is valuable to someone
It's messy, it's beautiful and it is
fundamentally very human
How does one create great products?

TurtleSec
61
TurtleSec
People say fail fast,
but that misses why:
People don't know
what they want.
But they sure as hell know:
This ain't it.

TurtleSec
62
You want to make something great?
Make something shit fast.
TurtleSec
And show it to people.
They will tell you exactly how it sucks.

TurtleSec
63
TurtleSec
And then repeat, again and again.
You need feedback to Get Good.

TurtleSec
64
And one day, seemingly by magic.
You'll make something they love.
TurtleSec

TurtleSec
65
TurtleSec
The 3 ways to
make a product
1. Force or pay them
2. Make it useful or fun
3. Make it addictive

TurtleSec
66
TurtleSec
I don't know much.
But I know this:
It will involve talking to
people.
So many people.

TurtleSec
67
Anyone who needs to read this book to understand How Tech Orgs Work,
does not have the requisite knowledge to make anyone good at this.
TurtleSec

TurtleSec
68
There isn't a magic button
Dunbar's
Number
"Conway's
Law"
"The Spotify
Model"
Cognitive
Load
Fantasy
Condescension
Force
Superstition
Building great stuff is
work.

TurtleSec
69
This book is yet another cargo cult.
Yet another Agile coaching promise.
You don't need anyone to tell you what you need.
You know.
Collectively.
You know.

TurtleSec
70
TurtleSec
Just ask.
We need to stop
treating our highly
skilled colleagues like
children.

TurtleSec
71
Turtle
Sec
Thank you!

TurtleSec
72
Questions?
Photos from pixabay.com and Wikipedia
Patricia Aas, TurtleSec
Turtle
Sec

The fundamental misunderstanding in Team Topologies

More Related Content

What's hot

Similar to The fundamental misunderstanding in Team Topologies

More from Patricia Aas

Recently uploaded

The fundamental misunderstanding in Team Topologies