Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

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.

The team is the most effective means of software delivery, not individuals.

Restrict team responsibilities to match the maximum team cognitive load. Establish clear boundaries of responsibility for teams.

Traditional org charts don’t help us understand what the actual patterns of communication in our organization are,

Niels Pflaeging, author of Organize for Complexity, identifies not one but three different organizational structures in every organization:2 Formal structure (the org chart)—facilitates compliance

Informal structure—the “realm of influence” between individuals Value creation structure—how work actually gets done based on inter-personal and inter-team reputation

Team Topologies provides four fundamental team types—stream-aligned, platform, enabling, and complicated-subsystem—and three core team interaction modes—collaboration, X-as-a-Service, and facilitating.

this is the phrase that became known as Conway’s law: “Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.”

The key takeaway here is that 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.

Specifically, that is why monoliths need to be broken down (in particular, any indivisible software part that exceeds the cognitive capacity of any one team) while keeping a team focus,

When we talk about cognitive load, it’s easy to understand that any one person has a limit on how much information they can hold in their brains at any given moment. The same happens for any one team by simply adding up all the team members’ cognitive capacities.

When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.

Prioritization was hard, and the frequent context switching even throughout a single sprint led to a dip in people’s motivation. This is not surprising if we consider Dan Pink’s three elements of intrinsic motivation: autonomy (quashed by constant juggling of requests and priorities from multiple teams), mastery (“jack of all trades, master of none”), and purpose (too many domains of responsibility).

“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”

a reverse Conway maneuver (or inverse Conway maneuver) can be undertaken to reconfigure the team intercommunications before the software is finished.

Our research lends support to what is sometimes called the “inverse Conway maneuver,” which states that organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams.6