Manuel Pais and Matthew Skelton, authors of the influential book "Team Topologies," have reshaped the way organizations think about structuring their teams for effective software delivery. Their work provides a practical framework for organizing business and technology teams to achieve a fast flow of change and create a more sustainable and humane work environment.
Core Principles of Team Topologies
The foundation of Pais and Skelton's work lies in a set of guiding principles that challenge traditional organizational structures.
On the Importance of Team-First Thinking:
- "A team-first approach to software systems is essential for success in today's fast-moving business environment."[1]
- "The team is the fundamental building block of modern software delivery."
- "Instead of structuring teams according to technical know-how or activities, organise teams according to business domains."[2]
- "Who is on the team matters less than the team dynamics."[3]
- "Businesses can no longer choose between optimizing for stability and optimizing for speed."[4]
On Conway's Law and Organizational Design:
- "Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organisations." (Conway's Law)[5]
- "Thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong."[2]
- "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins."[6]
- The "inverse Conway maneuver" suggests that organizations should evolve their team and organizational structure to promote their desired architecture.[7]
- "Technical leaders must have a say on the organisation design. Not all collaboration/communication is good."[3]
On Managing Cognitive Load:
- "When cognitive load isn't considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains."[6][8][9]
- "The primary purpose of the other three team types (Platform, Enabling, and Complicated-Subsystem) is to reduce the cognitive load on the stream-aligned teams."[10]
- To limit cognitive load, a single team should be able to accommodate two to three “simple” domains.[5]
- "A good platform should make stream-aligned teams move faster, not generate more dependencies to manage."[11]
- Minimise intrinsic cognitive load, eliminate extraneous cognitive load to leave room for germane cognitive load.[3]
The Four Fundamental Team Topologies
Pais and Skelton propose four fundamental team types to clarify responsibilities and interactions.
Stream-Aligned Teams:
- A stream-aligned team is aligned to a single, valuable stream of work, be it a product, service, feature set, or user journey.[5]
- "The purpose of a stream-aligned team is to deliver value with minimal hand-offs."[3]
- They are empowered to build and deliver customer or user value as quickly, safely, and independently as possible.[5]
Enabling Teams:
- An enabling team helps other teams to adopt and modify software as part of a transition or learning period.[12]
- "The mission of an enabling team is to help stream-aligned teams acquire missing capabilities, taking on the effort of research and trials, and setting up successful practices."[9]
- They act as consultants and mentors, driving innovation and helping other teams optimize their work.[13]
Complicated-Subsystem Teams:
- A complicated-subsystem team has a special remit for a subsystem that is too complex for a normal stream-aligned or platform team to handle.[12]
- This topology is optional and should only be used when necessary.[12]
- Their purpose is to reduce the cognitive load of stream-aligned teams.[3]
Platform Teams:
- "The mission of a platform team is to reduce the cognitive load of stream-aligned teams by off-loading lower level detailed knowledge."[8]
- "Platform engineering is a core concept of Team Topologies."[14]
- A platform team's work enables Stream-aligned Teams to deliver features more quickly by providing them with the systems they need to do so.[14]
- "The platform team's knowledge is best made available via self-service capabilities via a web portal and/ or programmable API."[9]
- "A crucial insight of Team Topologies is that the primary benefit of a platform is to reduce the cognitive load on stream-aligned teams."[15]
- The "Thinnest Viable Platform" approach encourages building only what is necessary to reduce cognitive load and enable fast flow.[10]
The Three Core Interaction Modes
Effective team interaction is crucial for a fast flow of value. Pais and Skelton define three primary modes of interaction.
Collaboration:
- Collaboration involves two teams working together for a defined period to discover new things such as APIs, practices, or technologies.[11][12]
- "Collaboration is expensive, so it must be planned and justified."[3]
- This mode is particularly valuable during the discovery of new technology or approaches where rapid learning is required.[12]
X-as-a-Service:
- X-as-a-Service is where one team provides and another team consumes something "as a service."
- This interaction mode is common for platform teams who provide services to stream-aligned teams.
- The goal is to allow the consuming team to be more autonomous and focus on their primary responsibilities.
Facilitating:
- Facilitating is where one team helps another to learn or adopt new approaches.
- This is a common interaction mode for enabling teams.
- The goal is to build capability in the facilitated team so they can be more self-sufficient in the future.
Evolving the Organization
Team Topologies is not a static model but an adaptive approach to organizational design.
- "Organizational design is never 'done'—it must evolve as business needs, technologies and people change."[11]
- "Team boundaries shouldn't be fixed permanently; they must adapt as products and technologies evolve."[11]
- "Much like a software architecture document gets outdated as soon as the actual software development starts, an org chart is always out of sync with reality."[3][4]
- "The most important thing is not the shape of the org, but the decision rules used to adapt and change it."[3]
- Organizations should allow teams to negotiate boundary changes directly rather than wait for top-down directives.[11]
- Triggers for the evolution of Team Topologies can include software growing too large for one team or work being consistently queued in a particular team.[3]
Practical Application and Broader Insights
- "A 'team' is more than a group of people – it's a whole living organism that must evolve and be supported in the process of its evolution."[16]
- "For effective team-first ownership of software, teams need to continuously define, advertise, test, and evolve their 'team API'."[15]
- The "team API" defines how a team communicates, what they own, and their practices, making interactions with other teams clearer.[7]
- "Successful organizations have realized that building and running software systems need awareness of the sociotechnical context: people plus tech."[1]
- "Remote work is not just about having zoom and slack installed. We also need psychological safety and ground rules and practices that are going to help people work together especially when we're talking about different teams working together."[15]
Sources
