Combining Wardley Maps and Team Topologies

Two Frameworks, One Strategic Advantage

Team Topologies and Wardley Mapping are two of the most influential frameworks in modern technology strategy. Team Topologies, created by Matthew Skelton and Manuel Pais, gives us a vocabulary for team design: four fundamental team types (stream-aligned, platform, enabling, and complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, and facilitating). Wardley Mapping, created by Simon Wardley, gives us a way to visualize our business landscape as a value chain plotted against an evolution axis, from genesis through custom-built and product to commodity.

Each framework is powerful on its own. But used together, they answer the question neither can answer alone: what team structure does our specific strategic context demand? Team Topologies tells you the types of teams you need; Wardley Mapping tells you where and why.

The Problem with Team Design in a Vacuum

Most organizations design their team structures based on gut instinct, historical accident, or a generic best practice borrowed from a conference talk. They adopt Team Topologies and create stream-aligned teams, platform teams, and enabling teams — but they lack a principled way to decide which components belong to which team type, or where team boundaries should fall.

Without strategic context, you get predictable failure modes: platform teams building custom solutions for components that should be outsourced as commodity services, stream-aligned teams struggling with deeply novel technology that demands specialist enabling support, or complicated-subsystem teams guarding components that have long since evolved into well-understood products.

Wardley Mapping provides the missing strategic context. By mapping your value chain and understanding where each component sits on the evolution axis, you gain a principled basis for team design decisions.

How the Evolution Axis Informs Team Type Choices

The evolution axis in a Wardley Map describes how components mature over time, moving from left (novel, uncertain) to right (industrialized, well-understood). This axis maps remarkably well onto Team Topologies’ four team types:

• Genesis and Custom-Built (left side): Components in the genesis and early custom-built phases are novel, poorly understood, and require rapid experimentation. This is the domain of stream-aligned teams working in close collaboration mode with enabling teams. Enabling teams provide coaching and support in new techniques, languages, or practices that stream-aligned teams need to explore uncharted territory.
• Custom-Built to Product (middle): As components mature and patterns emerge, some become technically complex but increasingly well-defined. This is where complicated-subsystem teams earn their place — owning components that require deep specialist knowledge (such as a machine learning pipeline or a real-time trading engine) but are not yet commoditized enough to be offered as a platform service.
• Product to Commodity (right side): Components that have evolved to become well-understood, stable, and widely needed across the organization are prime candidates for platform teams. These teams provide their capabilities as X-as-a-Service, reducing cognitive load on stream-aligned teams and accelerating delivery across the organization. Think identity services, CI/CD pipelines, or monitoring infrastructure.

This mapping is not rigid — it is a heuristic. But it gives leaders a strategic rationale for team design that goes far beyond intuition.

Value Chains Define Stream-Aligned Team Boundaries

The vertical axis of a Wardley Map represents the value chain — the chain of components needed to serve a user need. This axis is equally valuable for team design because it reveals natural boundaries for stream-aligned teams.

A well-drawn Wardley Map exposes which components cluster together to serve a particular user need. These clusters often correspond to natural team boundaries. Rather than slicing teams by technical layer (frontend team, backend team, database team), you can slice them by value chain segment, ensuring each stream-aligned team owns a coherent slice of user value from top to bottom.

When you use the value chain to define team boundaries, you minimize cross-team dependencies and maximize each team’s ability to deliver end-to-end value independently. This is the essence of fast flow.

Simon Wardley has spoken extensively about how organizations repeatedly make the mistake of applying uniform management practices across all components, regardless of their evolutionary stage. The same insight applies to team design: a one-size-fits-all team structure ignores the fundamentally different demands of novel versus commodity components.

Practical Application: A Step-by-Step Approach

Organizations that have combined these frameworks typically follow a process like this:

• Step 1: Map the landscape. Start with a Wardley Map. Identify your users, their needs, and the components in your value chain. Plot each component on the evolution axis.
• Step 2: Identify clusters and boundaries. Look for natural groupings of components along the value chain that serve distinct user needs. These become candidates for stream-aligned team boundaries.
• Step 3: Match team types to evolution stages. For components on the right (commodity/utility), consider platform teams. For components on the left (genesis/custom), ensure stream-aligned teams have enabling team support. For technically complex components in the middle, evaluate whether a complicated-subsystem team is warranted.
• Step 4: Define interaction modes. Use the map to determine how teams should interact. Teams owning commodity components should offer X-as-a-Service. Teams exploring novel components should be in collaboration mode with enabling teams. Over time, as components evolve rightward, interaction modes should shift accordingly.
• Step 5: Anticipate evolution. Wardley Maps are not static. Components move rightward over time. Plan for your team structure to evolve with the map — today’s complicated-subsystem team may become tomorrow’s platform team as the underlying technology matures.

Why the Combination Is More Powerful Than Either Alone

Team Topologies without Wardley Mapping risks creating well-named teams that are poorly aligned to strategic reality. You might build a beautiful platform team around a component that is still in genesis and needs experimentation, not standardization. Or you might keep a stream-aligned team struggling with a component that has evolved to commodity and should simply be consumed as a service.

Wardley Mapping without Team Topologies gives you strategic insight but no organizational vocabulary to act on it. You can see that a component is evolving toward commodity, but you lack a clear model for how to restructure your teams in response.

Together, they form a feedback loop: the map informs the team design, and the team structure’s effectiveness (or friction) informs the next iteration of the map. Leaders like Mark Schwartz at AWS and practitioners in the Domain-Driven Design community have noted how strategic mapping and deliberate team design reinforce each other, creating organizations that adapt their structure as their landscape evolves rather than waiting for a painful reorganization.

Bringing It All Together with Team Dependencies

Applying these frameworks in combination sounds powerful in theory, but in practice it demands tooling that connects the strategic view to the organizational view. That is exactly what Team Dependencies is built to do. By allowing you to map your value chain, plot component evolution, assign team types, and visualize the dependencies between them, Team Dependencies brings Wardley Mapping and Team Topologies together in a single, interactive tool — so you can move from strategic insight to team design decisions in one place, and keep both aligned as your landscape evolves.