This article was originally published on bmf-tech.com.
What is Team Topologies?
Team Topologies is an "adaptive organizational design model to maximize the flow of business value."
It fundamentally differs from traditional organizational design (hierarchical organizational charts) by prioritizing the following:
- Emphasizing dynamic "flow" over static "hierarchy"
- Considering "cognitive load" as a design constraint
- Thinking of software architecture and organizational structure as a set
The goal is to create a state where each team can operate autonomously by organizing inter-team dependencies and reducing unnecessary communication (coordination costs).
Why Team Topologies?
Why do traditional function-based organizations (frontend, backend, infrastructure, etc.) not work well? Two powerful laws are at play here.
Conway's Law and the "Reverse Conway Maneuver"
The law proposed by Melvin Conway in 1968 is still valid today.
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
In other words, if an organization is siloed, the system will also be fragmented, making integration difficult. Conversely, if you want to create loosely coupled microservices, you must first divide the organization into loosely coupled independent teams. This is called the "Reverse Conway Maneuver."
Cognitive Load Theory: The Limits of Teams
Another important concept is "cognitive load." There is a limit to the complexity that the human brain (working memory) can handle at one time. Team Topologies classifies this load into three types and aims to reduce "extraneous load."
- Intrinsic Load: Essential load for work, such as how to write Java or business logic.
- Extraneous Load: Non-value-adding load, such as overly complex deployment procedures, difficult-to-use test environments, and unclear internal procedures.
- Germane Load: Load for seeking better solutions. More resources should be allocated here.
Cognitive Load and "Lack of Ownership"
What happens when cognitive load exceeds a team's capacity?
The team can no longer fully understand the entire system. Then, anxiety like "I don't want to touch the working parts" or "What if it breaks when deployed?" begins to dominate. As a result, there is a "lack of ownership (sense of ownership and responsibility)" towards the system.
The attitude of "I don't know anything outside my responsibility" spreads, incident response is passed around, and delivery speed dramatically decreases.
The aim of Team Topologies is to restore healthy ownership by setting appropriate team sizes and responsibility scopes.
Four Team Types
To avoid chaotic team formation and manage cognitive load appropriately, Team Topologies recommends classifying the organization into the following four types only.
Stream-aligned Team
- Role: Teams aligned with the main value stream of the business.
- Characteristics: They have end-to-end responsibility (ownership) for the entire flow, from planning, development, testing, to operations. They minimize "waiting for requests" from other teams and are the main actors in delivering value autonomously. In a healthy organization, 80-90% of all teams are of this type.
Platform Team
- Role: Teams that provide infrastructure and tools as "self-service" so that stream-aligned teams can operate autonomously.
- Characteristics: They view internal developers as "customers" and provide an easy-to-use, low-cognitive-load platform (Thinnest Viable Platform). They are not mere "infrastructure operators" but teams that create "products" to increase the productivity of product teams.
Enabling Team
- Role: Specialist teams to fill gaps in specific technical areas (security, test automation, AI, etc.).
- Characteristics: Instead of doing the work for them, they temporarily join stream-aligned teams to provide technical guidance and coaching, thereby improving the team's capabilities. They are teams that "teach how to fish rather than give fish."
Complicated Subsystem Team
- Role: Teams that handle only parts that are too specialized for normal teams to handle due to high cognitive load, such as advanced mathematical models or image processing engines.
- Characteristics: They are set up as an exceptional measure to reduce cognitive load. They should not be increased easily.
Three Interaction Modes
Not only the "shape" of the team but also the "way of interaction" needs to be intentionally designed.
| Mode | Description | Suitable Situation |
|---|---|---|
| Collaboration | Two teams closely cooperate to solve problems together. | When introducing new technology or during the exploratory phase when API specifications are not yet decided. |
| X-as-a-Service | One team uses the API or tools provided by another team. | When the platform is mature and can be used with just documentation. It has the lowest cognitive load. |
| Facilitation | One team supports another by removing obstacles. | When an enabling team supports the learning of other teams. |
The important thing is that these modes are not fixed but should be used differently depending on the time. Dynamic changes, such as starting with "Collaboration" to build together and then transitioning to "X-as-a-Service" once stable, are required.
Conclusion
Team Topologies is not a "new organizational chart" that ends once implemented.
As the product phase changes, the necessary team shape and optimal interaction also change. Regularly questioning "Are the current team boundaries appropriate?" and "Is cognitive load becoming too high?" and continuously refactoring the organization (organizational sensing) is the key to maintaining a fast flow.
Starting by discussing with your team which type they fit into and whether "cognitive load" is undermining ownership might lead to valuable discoveries.
Top comments (0)