Autonomous Teams:
Do We Really Want Them?
Eberhard Wolff
Head of Architecture
https://swaglab.rocks/
https://ewolff.com/
Slide 2
Slide 2 text
What Is Autonomy?
•Team works mostly independently.
•Team decides by itself.
Slide 3
Slide 3 text
Why Would We Want Autonomous Teams?
•Autonomy is no goal but a means.
•Does autonomy lead to “better” results?
Slide 4
Slide 4 text
Less Communication
•More autonomy = less coordination and
communication.
•Therefore, more time to deliver value.
•So probably better results
Slide 5
Slide 5 text
Self-determination
•Make decisions where most information is
available
•Teams set goals themselves
•Be creative in solving problems
•Better job satisfaction
•Probably better results
Slide 6
Slide 6 text
Discussion … often focus on tools &
technologies.
• Should the organization adopt
microservices?
• Serverless?
• Kubernetes?
Our research shows these are the wrong
questions to focus on.
Slide 7
Slide 7 text
What is important
is enabling teams
to make changes to their products or services
without depending on other teams or systems.
Slide 8
Slide 8 text
His [Sergey Brin’s] job
… was to get out of the way
if he felt his idea wasn’t the best.
You need to have confidence
in your people,
and enough self-confidence
to let them identify a better way.
Slide 9
Slide 9 text
Architecture Limits Autonomy
Big Ball of
Mud Partnership
Slide 10
Slide 10 text
Autonomy: A Goal for Architecture
•Big Ball of Mud: Everything depends on everything
•Each change might influence any part of code.
•Forces teams in partnership i.e. close collaboration.
•A well-structured system: impact of changes limited
•I.e. sound architecture is a prerequisite for autonomy.
Slide 11
Slide 11 text
Microservices
•Sound architecture:
change impacts only parts of system
•Microservices: part can be deployed independently
…and can use a different technology.
•i.e. more potential for autonomy
•Enabling autonomy this way is an important part of
my consulting.
Slide 12
Slide 12 text
Autonomy
Less
Communication
More
Productivity
Self-
determination
Architecture
Example: Google
Example:
Accelerate
Slide 13
Slide 13 text
Why Are We Still Struggling with Autonomy?
•Advantages are obvious.
•It makes no sense to explain them further.
•We are looking for explanations why we are
still not there yet.
•Explanation is the first step to actually reach
autonomy.
Slide 14
Slide 14 text
Like Air Crash Investigations
•Investigation looks for reasons
•Usually more than one
•Often humans
•Goal: Make sure it never
happens again
•E.g. change training
Slide 15
Slide 15 text
Management I The team is
successful!
How do they
actually work?
What if
success ends?
Can they be
even more
successful?
Slide 16
Slide 16 text
Management I
Team feels like
a black box.
Not sure what
they are really
doing
What is my
role?
Slide 17
Slide 17 text
Management I
Can you look at how
we work here?
Is the teams
successful?
I fail to see any
major problems.
Did you look at it in
detail?
Why would I?
Slide 18
Slide 18 text
Management
•Autonomy means less control.
•I.e. management will not know nor understand what
teams do.
•Can lead to insecurity
•You need to be able to live with insecurity.
Slide 19
Slide 19 text
Management II
…but what you
suggest will never
work with the
people here.
I am an
external
consultant.
How can you
trust your
people
enough?
Autonomy and stuff
is great.
Slide 20
Slide 20 text
Management
•Management must trust teams to do the “right” thing.
…and to speak up if something doesn’t work.
Slide 21
Slide 21 text
The Illusion of Control
•The desire to control things explain lots of behavior.
•Excessive planning and deadline “waterfall”
•Excessive architecture rules
•But things do change.
•This becomes obvious in your first IT project.
•But people still use these technique
•i.e. they get an illusion of control
Slide 22
Slide 22 text
Leap of Faith
Sabrina‘s stash @ Flickr
Slide 23
Slide 23 text
Leap of Faith
•Wikipedia:
“act of believing something that is unprovable”
•“risky thing a person does in hopes of a positive
outcome”
•Consider trusting people
•Yes, it appears to be risky.
Slide 24
Slide 24 text
Leap of Faith
•If you truly trust people, people will step up.
•If there is no QA,
developers will likely invest more effort into testing.
•I.e. less control might mean people take over more
responsibility.
Should Code Analysis be Mandatory for Teams?
•E.g. test code coverage, complexity metrics, bad code
patterns …
•Yes, predefined goals
•Yes, team sets goals themselves
•No
•Vote
Slide 27
Slide 27 text
Results from Technical Training
7%
59%
34%
No
Yes, team decides
Yes, predefined
goals
110 responses,
random attendees from a technical trainings
Slide 28
Slide 28 text
Goodhart’s Law
When a measure becomes a target,
it ceases to be a good measure
Slide 29
Slide 29 text
Goodhart’s Law: Test Coverage
•Test coverage: good measure for the quality of test.
•Higher: more parts of the code are executed,
so the test can catch more errors.
Slide 30
Slide 30 text
Goodhart’s Law: Test Coverage
•Set a test coverage goal
•Metric will be manipulated.
•E.g. focus on trivial parts of the code
•E.g. don’t check any results
•E.g. just make sure no exception is thrown
•….
Slide 31
Slide 31 text
Goodhart’s Law: Test Coverage
•Test coverage increases.
•But the tests won’t really catch more problems.
•Test coverage is not a good metric for the quality of
the tests any more!
Slide 32
Slide 32 text
Should Code Analysis be Mandatory for Teams?
•Yes, predefined goals
Goodhart’s Law will hit you
•Yes, team sets goals themselves
You are still enforcing standards
•No
True autonomy
Slide 33
Slide 33 text
My View
•Code analysis is a great!
•But: No, code analysis should not be mandatory.
•Teams should decide for themselves!
•I trust the teams to do the right thing.
•I don’t want to waste time checking on their metrics.
•Note: I might make it easy to do code analysis
i.e. provide an infrastructure and guidance.
Slide 34
Slide 34 text
But what if they
don’t deliver quality?
I will hold them
responsible.
But they might use
techniques they
please.
Mob / ensemble /
pair programming
Code reviews…
Slide 35
Slide 35 text
Results
•Technical people, too, seem to prefer control over
autonomy.
•Lack of trust?
•Confusing “good idea” with “must be enforced”?
Slide 36
Slide 36 text
Technology Stack: Another Example
•Should we standardize the technology stack?
•Pro: Team can best decide what the right tool is.
•Con: Will end in anarchy
•My take: “convergence hypotheses”
•A team has many benefits from using the same
technology
Slide 37
Slide 37 text
Technology Stack: Convergence Hypotheses
•Teams have benefits from using the same technology.
•Knowledge & infrastructure available
•They will have a bias to use the same technology
…unless there is a significant drawback
…and then a different technology is fine
…unless they irresponsible or irrational
…and then there is a different problem
Slide 38
Slide 38 text
Technology Stack: Problems
•Sometimes teams use specific technologies to
improve their CV.
•Sometime projects become a unmaintainable mess.
•I.e. there has to be some guidance
Slide 39
Slide 39 text
Autonomy and View on Humanity
•If you easily trust people, you will let them work
autonomously.
•If you don’t, you will control them.
•This might or might not be based on your good / bad
experience.
Some Standards Are Needed
•Autonomy means less communication.
•Communication = architecture (Conway)
•Communication breakdown leads to architecture mess.
…as Conway pointed out.
•Architecture must provide conceptual integrity.
•So: provide guardrails and enable communication
•I.e. limit autonomy
Slide 42
Slide 42 text
Autonomy vs. 9-5
•Some people want to be told what to do.
•Autonomy means being responsible.
•Life is easier if you are not responsible.
•They might still do a good job!
•But then again, they probably make decisions in other
contexts.
•So: Provide them with more autonomy
…and see that happens.
Slide 43
Slide 43 text
Autonomy
Trust
Desire to Control
Enforce vs. convince
Example: Tech Stack
Example: Code
Analysis
Accepting limited
understanding
Some standards are
needed
Some want no
autonomy
Slide 44
Slide 44 text
Conclusion
Slide 45
Slide 45 text
Conclusion
•Autonomy seems to make sense
•Many architecture modernizations try to enable more
autonomy.
•Main problem: psychological
•Trust, living with uncertainty…
•Leap of faith
•Some standard is needed (tech stack, architecture)
…but must it be enforced?
Slide 46
Slide 46 text
WIR SUCHEN
MITGESTALTER:INNEN
swaglab.rocks/karriere
Slide 47
Slide 47 text
Trink einen virtuellen
Kaffee mit mir!
https://calendly.com/
eberhard-wolff-swaglab/
Slide 48
Slide 48 text
Send email to [email protected]
Slides
+ Sample Microservices Book DE / EN
+ Sample Practical Microservices DE/EN
+ Sample of Continuous Delivery Book DE
Powered by Amazon Lambda
& Microservices
EMail address logged for 14 days,
wrong addressed emails handled manually