⭐ Toby's Rating: 8/10 - Recommended For: Technology Managers
3 Big Ideas: 💡
Team Topologies Summary:
Use the Inverse Conway manoeuvre: Whereby an organisation focuses on organising team structures to match the architecture they want the system to exhibit, rather than expecting teams to follow a mandated architecture design.
Minimise Extraneous Team Cognitive Load so that teams can focus on the work that really matters.
The four-team topologies, interaction modes (see image below) and effective software boundaries will help improve the flow of value.
2 Most Tweetable Quotes: 🎙
Team Topologies Summary Quotes:
You can think of Team Topologies like elements needed for creating and maintaining a garden. The team topologies approach, acts like the instructions for placing the flowers and plants, along with patterns for pruning, and training, whereas the cultural engineering and financial elements are like the soil, water and fertiliser that helps the plants grow healthily.
If the architecture of the system and the architecture of the organisation, are at odds. The architecture of the organisation wins. - Ruth Malan
Tobys Top Takeaway: 🎁
I really liked how the Team Topologies book clearly described Conway's Law with practical examples. A key principle within the book is to reduce communication as much as possible between teams. This may sound counterintuitive as "collaboration” is widely espoused within agile.
However, as the Team Topologies book explains, high collaboration within the team is good but it's ideal to have minimal collaboration outside your team. When high collaboration is needed across teams this increases cognitive load and time to deliver.
Therefore what's really crucial is knowing when teams should collaborate instead of using another form of interaction such as "X-as-a-service"
Fast flow requires restricting communication between teams team collaboration is important for grey areas of development, where discovery and expertise are needed to make progress, but in areas where execution prevails not discovery, communication becomes an unnecessary overhead.
A caution for readers. The team topologies book is practical so it would be tempting to jump straight into solutions. However, these team topologies are designed for organisations attempting to optimise flow.
Overall, the team topologies approach advocates for organisation design that optimises for the flow of change and feedback from running systems.
The hard truth is that might not be your organisation’s goal or at the very least there are significant organisational dynamics that undermine flow. For example, if your organisation is fixated with efficiency or “keeping people busy” implementation of these topologies is unlikely to be successful.
A final thought. I would love to hear the authors thoughts on strategy deployment and backlog alignment to the topologies. For example, how does the backlog interaction work between the different teams? Especially how is the complicated subsystem team backlog managed? Assume this would be a key team where effective prioritisation might be required.
Big Ideas from Team Topologies by Matthew Skelton and Manuel Pais 💡
In addition to this team topologies summary, I recommend reading this summary by Henny Portman
Henny created a visual summary of the team topologies book:
“Modern organisation design…. is about designing for collaborative technologies for the voice of the customer.” - Naomi Stanford
“Organisations should be viewed as complex and adaptive organisms, rather than mechanistic and linear systems.” - Naomi Stanford
Team Topologies focuses on how to set up dynamic team structures and interaction modes that can help teams adapt quickly to new conditions and achieve fast and safe software delivery.
The combination of well-defined teams and well-defined interaction modes provides a powerful and flexible organisational capability for structural adaptation to change in external and internal conditions, enabling the organisation to sense its environment, modify its activities and focus to fit.
Behavioural studies suggest that humans work best with others when we can predict their behaviour
Three organisational structures in every organisation:
The formal structure - facilitates compliance
Informal structure - the realm of influence between individuals
Value creation structure - how work actually gets done based on interpersonal relationships and reputation.
Five rules of thumb for designing organisations:
Design when there is a compelling reason
Develop options for deciding on a design
Choose the right time to design
Look for clues that things are out of alignment.
Stay alert to the future.
Given our skills constraints, cultural and engineering maturity desired software architecture and business goals, which team topology will help us deliver results faster and safer?
Conway’s Law and Architecture:
Inverse Conway manoeuvre:
Whereby an organisation focuses on organising team structures to match the architecture they want the system to exhibit, rather than expecting teams to follow a mandated architecture design.
If the architecture of the system and the architecture of the organisation, are at odds. The architecture of the organisation wins. - Ruth Malan.
Conway's Law tells us that we need to understand what software architecture is needed. Before we organise our teams. Otherwise, the communication paths and incentives in the organisation will end up dictating the software architecture
Software architecture (and Organisation Design) good practices:
Loose coupling
High cohesion.
Clear, and appropriate version compatibility
Clear, and appropriate cross-team testing.
“More than ever I believe that someone who claims to be an architect needs both technical and social skills they need to understand people and work within the social framework. They also need a remit that is broader than pure technology. They need to have a say in organisational structures and personnel issues.” - Alan Kelly.
The three different categories of dependency:
Knowledge
Task
Resource dependencies
Thoughts on Platforms:
A digital platform is a foundation of self-service API's tools services, knowledge and support which are arranged as a compelling internal product autonomous delivery teams can make use of the platform to deliver product features at a higher pace with reduced coordination
Technology is only ever a part of the platform, roadmaps guided evolution play documentation and concern for developer experience and appropriate encapsulation of underlying complexity, are all key parts of an effective delivery platform for stream aligned teams.
Fracture Planes - Defining Software (Organisational) boundaries
A fracture plane is a natural seam in the software (organisation) system that allows the system to be split easily into two or more parts:
Business domain bounded context
Regulatory compliance.
Change cadence.
Team location.
Risk performance isolation.
Technology
User personas
Fracture Plane Litmus Test:
Does the resulting architecture support more autonomous teams with reduced cognitive load?
When considering subsystem boundaries. The main aim should be to find software fracture planes that align to business domain bounded contexts because most of these bounded contexts will map to streams of change that are natural for the organisation
Triggers for the evolution of team topologies
The software has grown too large for one team.
Delivery cadence is becoming slower.
Multiple Business Services rely on a large set of underlying services.
Teams Topologies also needs:
a healthy organisational culture
good engineering practices
healthy funding and financial practices
clarity of business vision.
How to get started with teams topologies:
Start with the team - What does the team need in order to:
act and operate effectively as a team?
own part of the software effectively?
focus on meeting the needs of users?
reduce the unnecessary cognitive load?
consume and provide software and information to other teams?
Identify suitable streams of change
Identify the thinnest viable platform.
Identify capability gaps in team coaching, mentoring service management and documentation.
Share and practice different interaction modes and explain principles behind, new ways of working.
You might also like: Ultimate List of Organizational Design Resources
