The document discusses how to design teams for modern software systems. It covers Conway's Law which states that a product's architecture will mirror the structure of the organization that developed it. It also discusses cognitive load on teams and how stress can reduce team performance. Real-world team topologies are presented, such as component teams, platform teams, and product teams. Guidelines are provided for configuring teams, including matching team responsibilities to their cognitive load. The document advocates evolving different team topologies over time based on factors like the team's purpose and context.

1. How and why to design your
teams for modern software
systems
Matthew Skelton | Skelton Thatcher Consulting
@matthewpskelton | skeltonthatcher.com
Agile in Leeds meetup - @AgileInLeeds
28 March 2017, Leeds UK

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. Organisation design for effective software systems
Tutorial / Workshop
Weds 24 May 2017, Manchester
https://ti.to/skelton-thatcher-consulting/organisation-design-for-effective-software-systems-tutorial-workshop

5. Books

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

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

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

10. TEAM

12. TEAM
capabilities
appetite & aptitude
understanding
responsibilities

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

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

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

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

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

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

19. Front-end
developers
Back-end
developers

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

21. A
B
A B

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

24. Cognitive Load
for teams

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

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

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

28. We have SCIENCE!

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

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

31. (not just ‘pop’ science!)

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

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

34. Real-world
Team Topologies

35. DevOpsTopologies.com

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

37. Guidelines for
team design

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

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

40. Supporting & Business Domain
Supporting Business Domain
devopstopologies.com

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

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

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

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

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

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

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

48. Evolution of team topologies
devopstopologies.com
DISCOVER ESTABLISH

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

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

51. Summary

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

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

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

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

56. DevOpsTopologies.com

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

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

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

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

61. Caution

62. Team topologies
alone will not
produce effective
software systems

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

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

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

66. Organisation design for effective software systems
Tutorial / Workshop
Weds 24 May 2017, Manchester
https://ti.to/skelton-thatcher-consulting/organisation-design-for-effective-software-systems-tutorial-workshop

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