From the AllDayDevOps 2017 live stream https://www.youtube.com/watch?v=XqowSG2Jxqc 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, exploring a selection of key team topologies 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 experience helping companies around the world with the design of their teams. Takeaways: - The implications of Conway’s Law for software teams - Cognitive Load for teams - Effective team topologies - Team evolution

1. October 24, 2017
Team Topologies:
how and why to design your teams
for modern software systems
Matthew Skelton
Co-founder and Principal Consultant
Skelton Thatcher Consulting
@matthewpskelton

2. October 24, 2017
1.The implications of Conway’s Law for teams
2.Cognitive Load for teams
3.Effective team topologies
4.Team evolution
Takeaways – Team Topologies

3. October 24, 2017
Session Title
Your Name
Your Title
Your Company
Your @TwitterHandle

4. October 24, 2017
Session Title
Your Name
Your Title
Your Company
Your @TwitterHandle

5. October 24, 2017
bit.ly/addo-slack
Find me on slack, right now!

6. October 24, 2017

7. Today
• Conway’s Law (or heuristic)
• Cognitive Load for teams
• Real-world Team Topologies
• Guidelines for team design

8. About me
Matthew Skelton
@matthewpskelton
Co-founder at
Skelton Thatcher Consulting
skeltonthatcher.com

9. Books

10. teamtopologies.com
Upcoming book:
Team Topologies for
effective software systems
by Matthew Skelton & Manuel Pais

11. Team-first digital transformation
30+ organisations
UK, US, DE, India, China
skeltonthatcher.com

13. How and why to
design your teams
for modern software
systems

14. Safer, more rapid
changes to
software systems
(Business Agility)

15. TEAM

17. TEAM
capabilities
appetite & aptitude
understanding
responsibilities

18. (assumption)
the team is stable, slowly changing,
and long-lived
#NoProjects

19. Conway’s Law
(or Conway’s Heuristic)

20. “organizations which design
systems ... are constrained to
produce designs which are copies
of the communication structures of
these organizations”
– Mel Conway, 1968
http://www.melconway.com/Home/Conways_Law.html

21. “if the architecture of the system and
the architecture of the organization
are at odds, the architecture of the
organization wins”
– Ruth Malan, 2008
http://traceinthesand.com/blog/2008/02/13/conways-law/

22. “We find strong evidence to support
the hypothesis that a product’s
architecture tends to mirror the
structure of the organization in
which it is developed.”
– MacCormack et al, 2012
MacCormack, Alan, Carliss Y. Baldwin, and John Rusnak. ‘Exploring the Duality Between Product and Organizational Architectures: A Test of the
“Mirroring” Hypothesis’, 1 October 2012. http://www.hbs.edu/faculty/Pages/item.aspx?num=43260.

23. homomorphic force
(#Conway  #Yawnoc)
HT @allankellynet
(same) (shape)

24. Front-end
developers
Back-end
developers

25. ‘Reverse Conway’
Tobbe Gyllebring (@drunkcod)

26. A
B
A B

28. Design the
organisation architecture
to produce the right
software architecture

29. Cognitive Load
for teams

30. Cognitive load
the total amount of
mental effort being used in
the working memory
(see Sweller, 1988)

31. Cognitive load
Intrinsic
Extraneous (Irrelevant )
Germane (Relevant)

32. ‘Hacking Your Head’: Jo Pearce
See http://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-45-mix
@jdpearce

33. We have SCIENCE!

34. Science since 1988
• Driskell et al, 1999 ‘Does Stress Lead to a Loss of Team Perspective?’ Group Dynamics:
Theory, Research, and Practice 3, no. 4 (1999): 291.
• Fan et al, 2010 ‘Learning HMM-Based Cognitive Load Models for Supporting Human-Agent
Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119.
• Ilgen & Hollenbeck, 1993 ‘Effective Team Performance under Stress and Normal
Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision
Making in Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993.
• Johnston et al, 2002 ‘Application of Cognitive Load Theory to Developing a Measure of
Team Decision Efficiency’. DTIC Document, 2002.
• Sweller, John, 1994 ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’.
Learning and Instruction 4 (1994): 295–312.
• Sweller, John, 1988. ‘Cognitive Load during Problem Solving: Effects on Learning’.
Cognitive Science 12, no. 2 (1988): 257–285.

35. “stress impacts team
performance … by narrowing or
weakening the team-level
perspective required for
effective team behavior.”
– Driskell et al, 1999
Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302

36. (not just ‘pop’ science!)

37. High-performing teams are
hugely effective
Optimise for the team

38. Match the team
responsibility to the
cognitive load that
the team can handle

39. Real-world
Team Topologies

40. DevOpsTopologies.com

41. Development & Testing
IT Operations / Web Operations
Anti-Type
Database / DBA
DevOps activity
SRE
Component
Supporting (Tooling / Platform / Build)

42. (Can you spot an important
team type that is missing?)

43. Anti-Types

44. Anti-Type A – Separate Silos
devopstopologies.com
Dev Ops

45. Anti-Type B – Separate DevOps Silo
Dev OpsDevOps
devopstopologies.com

46. devopstopologies.com
Dev OpsDevOps
Anti-Type C – “We Don’t Need Ops”

47. Anti-Type D – ‘DevOps’ as another Dev team
devopstopologies.com
Dev Ops
DevOps

48. Anti-Type E – DevOps as new SysAdmin team
devopstopologies.com
Dev OpsDevOps

49. Anti-Type F – Ops embedded in a Dev Team
HT: Matt Franz (@seclectech)
devopstopologies.com
Dev
Ops
DevOps

50. Anti-Type G – Dev-DBA gap!
devopstopologies.com
Dev OpsDBA

51. Types

52. Type 1 – Smooth Collaboration
devopstopologies.com
Dev OpsDevOps

53. Type 2 – Fully Embedded
devopstopologies.com
Dev Ops

54. devopstopologies.com
Dev OpsDevOps
Type 3 – Infrastructure-as-a-Service

55. Type 4 – DevOps-as-a-Service
devopstopologies.com
Dev OpsDevOps

56. devopstopologies.com
Dev OpsDevOps
Type 5 – Temporary DevOps Team

57. devopstopologies.com
Dev OpsDevOps
Type 6 – ‘Facilitating’ DevOps Team

58. Type 7 – SRE Team (Google)
SRE
HT: @kwdhinde
devopstopologies.com
Dev OpsDevOps

59. HT: @jascbu
devopstopologies.com
Dev OpsDevOps
Type 8 – ‘Just run my Containers’

60. Type 9 – DB capability in Dev
DBADB Dev
devopstopologies.com
Dev OpsDevOps

61. Type 10 – DB as a Service
DBaaSDB Dev
devopstopologies.com
Dev OpsDevOps

62. There is no single ‘right’ team
topology, but several ‘bad’
topologies for any one
organisation

63. Guidelines for
team design

64. Collaboration vs X-as-a-Service
Collaboration X-as-a-Service
devopstopologies.com

65. Collaboration vs X-as-a-Service
Collaboration X-as-a-Service
devopstopologies.com
Rapid discovery
No hand-offs
Comms overheads?
Ownership clarity
Less context needed
Slower innovation?

66. Supporting & Business Domain
Supporting Business Domain
devopstopologies.com

67. Inner Topologies
Collaboration XaaS
Within any group there may be
internal collaborations AND other X-
as-a-Service (XaaS) relationships
devopstopologies.com

68. Team types
Component team
Platform / ’substrate’ team
Supporting / ‘productivity’ team
Product/Feature team
devopstopologies.com

69. Team configuration
devopstopologies.com
Platform / ’substrate’ team
Product/Feature team

70. Team configuration
Component team
Platform / ’substrate’ team
Product/Feature team
devopstopologies.com

71. Team configuration
Component team
Platform / ’substrate’ team
Product/Feature team
Supporting / ‘productivity’ team
devopstopologies.com

72. Discovery vs. Predictability
Team 1
Team 2
Team N
Discovery, rapid learning
Predictable delivery
devopstopologies.com

73. Established platform (PaaS)
Predictable delivery
devopstopologies.com

74. Evolution of team topologies
devopstopologies.com
DISCOVER ESTABLISH

75. Evolution of team topologies
Team 2
Discover Discover
Team N
Team 3
Use
Use
devopstopologies.com
Team 1
Establish
Establish
…

76. Evolve different team
topologies for different parts of
the organisation at different
times to match the team
purpose and context

77. Summary

78. Front-end
developers
Back-end
developers
A
B
A B

79. Design the
organisation architecture
to produce the right software
architecture

80. “stress impacts team
performance … by narrowing or
weakening the team-level
perspective required for
effective team behavior.”
– Driskell et al, 1999
Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302

81. Match the team responsibility
to the cognitive load that the
team can handle

82. DevOpsTopologies.com

83. There is no single ‘right’ team
topology, but several ‘bad’
topologies for any one
organisation

84. Team configuration
Component team
Platform / ’substrate’ team
Product/Feature team
Supporting / ‘productivity’ team
devopstopologies.com

85. Evolution of team topologies
Team 2
Discover Discover
Team N
Team 3
Use
Use
devopstopologies.com
Team 1
Establish
Establish
…

86. Evolve different team
topologies for different parts of
the organisation at different
times to match the team
purpose and context

87. Caution

88. Team topologies
alone will not
produce effective
software systems

89. Also needed:
culture, good engineering,
sane funding models,
clarity of business vision

90. Safer, more rapid
changes to
software systems
(Business Agility)

91. teamtopologies.com
Upcoming book:
Team Topologies for
effective software systems
by Matthew Skelton & Manuel Pais

92. thank you
Matthew Skelton & Manuel Pais
@SkeltonThatcher
skeltonthatcher.com

93. October 24, 2017