The document discusses guidelines for designing teams for modern software systems. It notes that team structure should mirror software architecture (Conway's Law). High-performing teams optimize cognitive load by matching responsibilities to a team's capacity. Various team topologies are presented, including anti-patterns to avoid, like separate silos. Guidelines include evolving topologies over time for discovery vs. predictability, and using different topologies in different parts of an organization. However, team structure alone is not enough - culture, engineering practices, and business vision are also needed for effective software systems.

1. Matthew Skelton | Skelton Thatcher Consulting
How and why to design
your teams for modern
software systems
06 Dec 2016, Munich, DE - #DevOpsCon

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

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

4. Books

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

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

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

9. TEAM

11. TEAM
capabilities
appetite & aptitude
understanding
responsibilities

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

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

14. “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

15. “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/

16. “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.

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

18. Front-end
developers Back-end
developers

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

20. A
B
A B

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

23. Cognitive Load
for teams

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

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

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

27. We have SCIENCE!

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

29. “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

30. (not just ‘pop’ science!)

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

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

33. Real-world
Team Topologies

34. DevOpsTopologies.com

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

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

37. Anti-Types

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

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

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

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

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

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

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

45. Types

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

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

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

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

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

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

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

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

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

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

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

57. Guidelines for
team design

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

59. 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?

60. Supporting & Business Domain
Supporting Business Domain
devopstopologies.com

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

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

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

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

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

67. https://twitter.com/EricMinick/status/517335119330172930

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

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

70. Evolution of team topologies
devopstopologies.com
DISCOVER ESTABLISH

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

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

73. Summary

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

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

76. “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

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

78. DevOpsTopologies.com

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

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

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

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

83. Caution

84. Team topologies alone will
not produce effective
software systems

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

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

87. thank you
Matthew Skelton
@matthewpskelton
skeltonthatcher.com