Team Topologies #
Although Team Topologies is strictly not about architecture, it has a huge impact and connection on how we structure team ownership and our architecture according to Conways law. Therefore, I felt this made sense to cover in the Architecture Handbook.
What is Team Topologies? #
An adaptive model to organization design.
“Team Topologies” is a book that provides a framework for organizing and optimizing software development teams within an organization. The book emphasizes the importance of adapting team structures and interactions to the specific context of the organization and its technological landscape. This is all based on the Reverse Conway Maneuver. By embracing Conways Law, this framework tries to help create efficient teams that will also result in your desired architecture. As always, frameworks come with their fair share of criticism, but it doesn’t make it worth covering and using as input in your decision process.
Team topologies is a framework that gives you the tools, concepts, and patterns that help you reason and navigate the challenges of organizational design, with Conway’s law in view.
Why Team Topologies? #
Organization not only need to strive for autonomous teams, they also need to continuously think about and evolve themselves in order to deliver value quickly to the customers.
Key Concepts #
These concepts are used as building blocks on how to reason and think of structuring teams ownership and responsibilities.
Conway Law #
Taking Conways Law in consideration, we can use this to our advantage to create teams that result in the architecture/system that we want, while making the teams also more efficient.
Flow Of Change #
Refers to how changes in software and systems are managed and how they flow through an organization’s structure of teams.
Team Types #
- Stream-aligned team aligned to a flow of work from (usually) a segment of the business domain. These are “You Built It, You Run It” teams. No hand-offs to other teams for any purpose.
- Primary team type
- Enabling team helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
- Reduce load for stream-aligned teams, by acting as service providers (e.g learn new things while retaining focus).
- Complicated Subsystem team where significant mathematics/calculation/technical expertise is needed.
- Reduce load for stream-aligned teams, where stream-aligned teams are the internal customer of the subsystem.
- Platform team a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams.
- Reduce load for stream-aligned teams, where stream-aligned teams are the internal customer of the platform.
The goal of the these team types, is to manage cognitive load for teams by defining clear responsibilities and boundaries.
Interaction Modes #
There are only three ways in which team should interact:
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a Service”
- Facilitation: one team helps and mentors another team
Relation To Systems Thinking #
Notice that we recognize the key parts of any generic “system” from Systems Thinking.
- The Organization: The top level system we view.
- Team Types: Are the “Components” or “Elements” that our system is made of up and what their boundaries are.
- Interaction Modes: How Components/Elements of a system are interconnected with each other.
Conway’s Law & Reverse Conway Maneuver #
Part I (Teams as the means of Delivery) of the Team Topologies Book
The Issue with Traditional, top-down approach to team organization (Org Charts) #
- Conway’s law suggest major gains from designing software architecture and team interactions together, since they are similar forces.
- Team Topologies clarifies team purpose and responsibilities, increasing the effectiveness of their interrelationships.
- Team Topologies takes a humanistic approach to building software systems while setting up the organizations for strategic adaptability.
Conway’s Law and Why It Matters #
- Organizations are constrained to produce designs that reflect communication paths.
- The design of the organization constrains the “solution search space” limiting possible software designs.
- Requiring everyone to communicate with everyone else is a recipe for a mess.
- Choose Software Architectures that encourage team-scoped flow.
- Limiting communication paths to well-defined team interactions produces modular, decoupled systems.
Team-First Thinking #
- The team is the most effective means of software delivery, not individuals.
- Limit the size of multi-team groupings within the organization based on dunbars number.
- Restrict team responsibilities to match te maximum team cognitive load.
- Establish clear boundaries of responsibilities for teams.
- Change the team working environment to help teams succeed.
Team Patterns #
Part II (Team Topologies that work for flow) of the Team Topologies Book
Static Team Topologies #
- Ad hoc or constant changing team design slows down software delivery.
- There is no single definitive team topology but several inadequate topologies for any one organization.
- Technical and cultural maturity, org scale, and engineering discipline are critical aspects when considering which topology to adopt.
- In particular, the feature-team/product-team is powerful but only works with a supportive surrounding environment.
- Splitting a team’s responsibilities can break down silos and empower other teams.
The 4 Fundamental Team Topologies #
- The 4 fundamental team topologies simplify modern software team interactions.
- Mapping common industry team types to the fundamental topologies sets up organizations for success, removing gray areas of ownership and overloaded/underloaded teams.
- The main topology is (business domain) stream-aligned; all other topologies support this type.
- The other topologies are enabling, complicated-subsystems, and platform.
- The topologies are often “fractal” (self-similar) at large scale: teams of teams.
Choose Team-First Boundaries #
- Choose software boundaries using the team-first approach.
- Beware of hidden monoliths and coupling in the software-delivery chain.
- Use software boundaries defined by business-domain bounded contexts.
- Consider alternative software boundaries when necessary and suitable.
Evolving The Organization Design #
Part III (Evolving team interactions for innovation and rapid delivery) of the Team Topologies Book
Team Interaction Modes #
- Choose specific team interaction modes to enhance software delivery.
- Choose between 3 interaction modes - collaboration, X-as-a-Service, and facilitating - to help teams provide and evolve services to other teams.
- Collaboration can be a powerful driver for innovation but can also reduce flow.
- X-as-a-Service can help other teams deliver quickly but only if the boundary is suitable.
- Facilitating helps to avoid cross-team challenges and detects problems.
Evolve Team Structures With Organizational Sensing #
- Use different team topologies simultaneously for strategic advantage.
- Change team topologies and interactions to accelerate adoption of new approaches.
- Differentiate between explore, exploit, sustain, retire phases using team topologies.
- Expect multiple, simultaneous team topologies to meet different needs.
- Recognize triggers or organizational change.
- Treat operations as high-fidelity sensory input for self-steering.
Conclusion: The Next-Generation Digital Operating Model #
- Combine a team-first approach with Conway’s law, the 4 fundamental topologies, team interaction modes, topology evolution, and organizational sensing.
- Get Started: begin with the team, identify streams, identify the thinnest viable platform, identify capability gaps, and practice team interactions.