Team Topologies, Mapped

Where Team Topologies Sits on the Map

From the book 10X ORG: when speed is the primary goal, the big, messy problem must be sliced into smaller, well-bounded work areas, so each team can stay focused, act independently, and deliver at high velocity. Horizontally, you shift toward broader skills to create a smoother, more reliable flow. Vertically, you narrow the scope of work.

On the Org Topologies map, these fast-flow delivery units sit in the lower-right quadrant, where scope is tightly owned, boundaries are clear, and rapid iteration is possible. Team Topologies, created by Matthew Skelton and Manuel Pais, is one of the approaches the book names that encourage and support the creation of such Delivery Topology structures.

What a Delivery Topology Gives You

From the Primer: compared to the Resource Topology, the Delivery Topology upgrades delivery units to have fast flow by removing dependencies. Structurally, this typically means forming complete cross-functional teams and a smoother path to “completely done” work. Note the strong focus on outputs and local efficiency.

Keeping teams fast and constantly efficient in producing outputs is only possible when they are permanently fixed to a narrow work scope: an internal component or a specific set of capabilities. The other side of that coin is that they cannot easily switch contexts. By design, they lack the work mandate to engage with the big picture.

The Delivery Topology is well suited to domains where the core challenge is not discovering what to deliver, but delivering new capabilities predictably with short lead times.

Accelerating Value Delivery, Within Its Lanes

Team Topologies is presented as a way to accelerate value delivery. Mapped, that acceleration happens within narrow streams of work that are kept stable, even as the strategy changes. Each team is fast in its lane: the trade-off built into the heart of Delivery Topology, optimized for local speed and local flow.

When value shifts and the organization needs its teams to follow it, the lanes no longer fit. To keep the organizational design and the business strategy in sync, narrowly specializing teams need to be reorganized regularly, and this is expensive and difficult. Reorg after reorg, each time as justified, each time as expensive, each time as disruptive: the book calls it the transformation treadmill. Repeated shake-ups don’t revitalize organizations; they exhaust them.

Bounded Areas Are Not Value Streams

The book warns of a common and risky mistake, especially common in IT: labeling bounded work areas as “value streams.” In Lean and the Toyota Production System, a value stream is defined end to end from the customer’s perspective and activated by customer pull, from concept to cash. What IT often calls “value streams” are internal partitions of work, not the full flow of value from request to fulfillment.

Without a broader perspective, these Delivering units tend to optimize local outputs rather than business outcomes. As a result, they strongly rely on Directing units for cross-unit alignment, coordination, and outcome-level steering.

When Fast Feels Last, and Flow Runs Slow

If some work can truly be done by a single team with good flow, there is little else to wish for, provided, of course, that the direction of the team’s fast running is right. The problems begin when the work is truly larger than any team’s scope.

What if there are 5, 10, or 25 teams, each owning a small part of the “platform”? One team is fast when tuning the product catalog. Another works, with great flow, on payment integrations. Each team may be running fast and steady. Yet from the stakeholder’s perspective, the overall outcome can still feel slow, or even stall.

This is the trade-off built into the heart of Delivery Topology. It is optimized for local speed and local flow, because it promises speed and flow only in isolation: by splitting a whole into parts and assigning those parts to teams. The moment an outcome requires coordinated change across many parts, local speed and flow do not translate into global speed and flow.

Divide and Conquer

The book lists “stream-aligned teams,” “value streams,” “release trains” and “platform teams” among the industry’s many best practices for slicing organizations into parts. It calls the pattern divide and conquer.

What happens when a “product” or “stream-aligned” team delivers at impressive speed within its value stream, yet those outputs no longer connect to outcomes that matter, because the market has moved on? In a dynamic environment, the narrower the team’s scope, the higher the likelihood that the design will drift out of fit. The pattern is easy to recognize: dissatisfied stakeholders, growing pressure on employees, and, sooner or later, a new reorganization to redraw the boxes once again.

Cognitive Load, Reconsidered

Cognitive load is real, and it can drastically affect performance. It is often cited as a reason to give people narrow ownership and a comfortable, bounded scope. The book calls this a significant misunderstanding: cognitive load is not about how much people know. It is the amount of mental effort required to perform a task and learn while doing it. People do not get overloaded because they learn too much, but because the costs of learning are unnecessarily high.

Counterintuitively, when organizations try to “reduce cognitive load” by narrowing ownership, they usually increase it elsewhere. Fragmented ownership creates handoffs, dependencies, and waiting. Work that spans multiple components forces context switching. Among the practices the book recommends instead: starting with the big picture, merging discovery and delivery, minimizing work in progress, and sharing work in pairing and mobbing.

Stream-Aligned Teams in Practice

In our analysis of James Shore’s talk, he helped an organization of 42 component teams move away from the “spaghetti” state by redefining responsibilities and making what he calls “full ownership teams”, very similar to the stream-aligned teams popularized by Team Topologies. Most teams could now work on customer features end to end. That is a great improvement.

In the words of its creators, Matthew Skelton and Manuel Pais: “The goal is to optimize for fast flow of change.” Because of this goal, stream-aligned teams are given work in their field of expertise, because that is the fastest way to get that work done. Because of the relatively narrow scope of work, stream-aligned teams “did not truly own a significant portion of the final product” (James, in the talk). When work units are fixed to work only on given parts of the whole, you will have dependencies between the teams, though less strong than between pure component teams.

As James concludes, and as the book quotes in its chapter on Triple Taxation: “To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult.” What looks like investment in change is often just paying the reorganization tax again. The next step that company took was toward a fluid structure with FAST.

Elevate by Unpinning

The book tells the case of Strobbo, a Belgian SaaS company. Org Topologies revealed a clear Delivery Topology: teams operated within well-defined domains, delivered predictably, and experienced minimal handover friction. As the product strategy evolved, what was structured as an autonomous, fast-flow system based on the past roadmap became a network of interdependent silos.

Management responded by introducing Multi-Team Product Backlog Refinement sessions and other structures and practices that helped teams expand product scope across domains and begin sharing the outcomes. This way, Strobbo unpinned their teams, elevating their boundaries up to the level of the whole product.

A Framework Comes Last

The Primer’s sequence: business objectives, then the org goal, then the topology, then the framework. A framework is the last thing you choose, not the first. While the Elevating Katas give one set of guides to get change going, people will of course also get guidance from existing frameworks while aiming for the target topology.

Read the full case study, see the three topologies, or map your own organization in the C-OTC class. The whole argument is in the book 10X ORG at 10xorg.com.