Beyond the Spotify Model: using team topologies for fast flow and organisation evolution Key takeaways: 1. Why using the “Spotify Model” of team design is not enough 2. The four fundamental team topologies needed for modern software delivery 3. The three team interaction modes that enable fast flow and rapid learning 4. How to address Conway’s Law, cognitive load, and team evolution with Team Topologies For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway's Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes. This talk will cover the basics of organization design using Team Topologies, exploring a selection of key team types and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on the forthcoming 2019 book Team Topologies and first-hand experience helping companies around the world with the design of their technology teams. About Team Topologies Team Topologies is a clear, easy-to-follow approach to modern software delivery with an emphasis on optimizing team interactions for flow. Four fundamental types of team - team topologies - and three core team interaction modes combine with awareness of Conway’s Law, team cognitive load, and responsive organization evolution to define a no-nonsense, team-friendly, humanistic approach to building and running software systems. Devised by experienced IT consultants Matthew Skelton and Manuel Pais, the Team Topologies approach is informed by the well-known DevOps Team Topologies patterns (also authored and curated by Matthew and Manuel). Matthew and Manuel have worked with many organizations around the world to help them shape their teams for modern software delivery, and Team Topologies is the result of that experience. teamtopologies.com From a talk given at Agile Scotland on 11 March 2019

1. TeamTopologies.com
@TeamTopologies
Beyond the Spotify model
using Team Topologies for organisation design
with software delivery
Matthew Skelton, Conflux
co-author of Team Topologies - @matthewpskelton
Agile Scotland, 11 March 2019, Edinburgh

2. 2
(Confession)
I
❤
Edinburgh

3. 3

4. 4

5. 5

6. 6
The Spotify Model
Limitations
Team Topologies
Getting started

7. 7

8. 8

9. The Spotify model of
team design for
software delivery
9

10. 10
Henrik Kniberg & Anders Ivarsson, 2012
https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

11. 11
The Spotify model
Squad: semi-autonomous delivery team
Tribe: family of Squads - related work
Chapter: line management within a Tribe
Guild: cross-Tribe interest/specialist group

12. 12
The Spotify model has
been hugely helpful to
100s of organizations

13. The Spotify model
helps to...
13

14. 14
Encourage flow
of change

15. 15
Establish and
clarify team
responsibilities

16. 16
Promote good
kinds of team
collaboration

17. 17
Plan and budget
for cross-team
enablers

18. 18
The Spotify model helps to
Encourage flow of change
Establish and clarify team responsibilities
Promote good kinds of team collaboration
Plan and budget for cross-team enablers

19. Limitations of the
Spotify model
19

20. “This article is only a snapshot of our
current way of working - a journey in
progress, not a journey completed. By
the time you read this, things have
already changed.”
- Kniberg & Ivarsson
20

21. There is No Spotify Model
21
Marcin Floryan, 2016
https://www.infoq.com/presentations/spotify-culture-stc

22. 22
Software sizing
and cognitive
load

23. 23
Heuristics for
Conway’s Law

24. 24
Patterns for
team
interactions

25. 25
Triggers for
change and
evolution

26. 26
We also need to address
Software sizing and cognitive load
Heuristics for Conway’s Law
Patterns for team interactions
Triggers for change and evolution

27. Team Topologies
27

28. Team Topologies
28
Research over 5 years across multiple industry sectors
Informed by 50+ peer-reviewed journal articles
30+ client organizations - consulting and training since
2013 with orgs in CN, EU, IN, US, UK, +
Book: 12+ case studies from well-known organizations

29. Origins - DevOps Topologies
29
CC BY-SA devopstopologies.com

30. 30
Philip Fisher-Ogden,
Director of Engineering at
Netflix:
“thanks for your insightful
articulations of devops
topologies. They inspired
many discussions and
helped us to think about
what model Netflix teams
could be/are using.”
https://twitter.com/philip_pfo/status/999074792123740160

31. 31
Crystal Hirschorn,
Director of Engineering at
Condé Nast International
“Your topological models
resonated extremely well
on both the Dev and Ops
side btw! I like the balanced
arguments, e.g. different
perspectives, for each
pattern.”
https://twitter.com/cfhirschorn/status/1103387659890819073

32. Team Topologies
32
Organizing business and
technology teams for fast flow
Matthew Skelton and
Manuel Pais
Publication date: Sept 2019
IT Revolution Press
Pre-order from Amazon.com:
https://teamtopologies.com/book

33. “innovative tools and concepts for
structuring the next generation
digital operating model”
Charles T. Betz, Principal Analyst, Forrester Research
33

34. Team Topologies for fast flow
Conway’s Law
Team-first
Thinking
Team
Interactions
Sensing for
Evolution
34

35. 35
Software sizing
and cognitive
load

36. 36
Team-first Thinking

37. 37
Team-first Thinking
The team is the means of delivery

38. 38
Team-first Thinking
Design for team cognitive load

39. 39
Team-first Thinking
Choose boundaries for team ownership

40. 40
Team-first Thinking
Physical and digital workspace

41. 41
Team-first Thinking
The team is the means of delivery
Design for team cognitive load
Choose boundaries for team ownership
Physical and digital workspace

42. 42
Heuristics for
Conway’s Law

43. 43
Conway’s Law

44. 44
Conway’s Law
Heuristic for ‘natural’ expected design

45. 45
Conway’s Law
Mirroring in tech system + human system

46. 46
Conway’s Law
Reverse Conway to mitigate worst effects

47. 47
Conway’s Law
Constraint on solution search space

48. 48
Conway’s Law
Heuristic for ‘natural’ expected design
Mirroring in tech system + human system
Reverse Conway to mitigate worst effects
Constraint on solution search space

49. 49
Patterns for
team
interactions

50. 50
Team Interactions

51. 51
Team Interactions
3 defined Interaction Modes

52. 52
Team Interactions
Collaboration: 2 teams working together

53. 53
Team Interactions
X-as-a-Service: 1 provides, 1 consumes

54. 54
Team Interactions
Facilitating: 1 team helps another

55. 55
Team Interactions
3 defined Interaction Modes
Collaboration: 2 teams working together
X-as-a-Service: 1 provides, 1 consumes
Facilitating: 1 team helps another

56. 4 fundamental topologies
56
Stream-aligned team
Enabling team
Complicated Subsystem team
Platform team

57. 4 fundamental topologies
57
Flow of change

58. 3 core interaction modes
58
Flow of change
X-as-a-Service
Facilitating
Collaboration

59. 59
Triggers for
change and
evolution

60. 60
Sensing for Evolution

61. 61
Sensing for Evolution
Not all teams in the org look the same

62. 62
Sensing for Evolution
Discover, then push to Platform

63. 63
Sensing for Evolution
Awkward team interactions are signals

64. 64
Sensing for Evolution
Evolve the org with changing ecosystem

65. 65
Sensing for Evolution
Not all teams in the org look the same
Discover, then push to Platform
Awkward team interactions are signals
Evolve the org with changing ecosystem

66. Getting started with
the Team Topologies
approach
66

67. Getting started
67
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

68. How well can the team as a unit “grok”
the systems they own and develop?
Push some things into a Platform?
Are skills or capabilities missing?
Explicit cognitive load
68

69. Getting started
69
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

70. Are there major mismatches between
the team interactions and the required
software / system architecture?
What could be easily adjusted?
Large Conway mismatches
70

71. Getting started
71
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

72. What would change if we adopted the
3 team interaction patterns?
Collaboration, X-as-a-Service, Facilitating
How would teams react & behave?
Team Interactions
72

73. Getting started
73
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

74. How is your Platform defined?
What is the thinnest platform that
could work?
What’s needed to run an support it?
Thinnest Viable Platform
74

75. Getting started
75
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

76. Review
76

77. 77
The Spotify model helps to
Encourage flow of change
Establish and clarify team responsibilities
Promote good kinds of team collaboration
Plan and budget for cross-team enablers

78. 78
We also need to address
Software sizing and cognitive load
Heuristics for Conway’s Law
Patterns for team interactions
Triggers for change and evolution

79. Team Topologies for fast flow
Conway’s Law
Team-first
Thinking
Team
Interactions
Sensing for
Evolution
79

80. Getting started
80
Explicit cognitive load
Large Conway mismatches
Team Interactions
Thinnest Viable Platform

81. Sign up for news and tips:
TeamTopologies.com
81

82. Thank you!
info@teamtopologies.com
82
Matthew Skelton, Conflux
@matthewpskelton
Manuel Pais, Independent
@manupaisable
Copyright © Conflux Digital Ltd 2018-2019. All rights reserved.
Registered in England and Wales, number 10890964
Icons made by Freepick from www.flaticon.com - used under license