Team Topologies: Designing Organisations for Fast Flow of Value

Why traditional org charts are not enough

Speed is a key competitive factor in the digital economy. Yet many companies are held back by their own structure: teams depend heavily on one another, responsibilities remain unclear and coordination consumes a lot of time.

Traditional org charts do little to help. They show reporting lines, not how work actually flows. Often they reinforce the very silos they are meant to overcome.

With Team Topologies, Matthew Skelton and Manuel Pais developed a model and a shared language for designing organisations around a fast flow of value. A core idea is the Reverse Conway Maneuver: since systems mirror the communication structures of the organisation that builds them, the organisation should be deliberately designed so that the desired, decoupled architecture can emerge.

The four team types

Team Topologies gives each team a clear purpose. This creates transparency about responsibility and collaboration.

Stream-aligned team

The stream-aligned team is the central team type. It is aligned with a continuous stream of value and owns a product, a service or a user journey end to end. The aim is to deliver customer value without hand-offs to other teams. An example is a team that owns the entire path from product search to checkout on an online marketplace.

Enabling team

Enabling teams consist of specialists who help stream-aligned teams build new capabilities. They work for a limited time, for example when introducing test automation, and then step back. Their mission is to enable, not to deliver permanently.

Complicated subsystem team

Some parts of a system require deep specialist knowledge, such as complex algorithms or low-level programming. A complicated subsystem team concentrates this knowledge and relieves the other teams. Typical examples are a video processing engine or a fraud detection component.

Platform team

The platform team provides an internal platform as a product. It encapsulates technical complexity and offers reliable services for deployment, monitoring, authentication or databases. A good platform speeds up other teams instead of creating new dependencies.

The interplay is what counts

The four types only take full effect together. The performance of a stream-aligned team depends on the quality of the platform it uses. Without enabling teams, knowledge gaps emerge. And using the types merely as labels, without designing the relationships between teams, misses the point of the model.

The three interaction modes

Alongside the team types, Team Topologies describes three modes of collaboration. They make explicit how teams are expected to work together.

• Collaboration: Two teams work closely together for a limited period to develop something new, such as a new interface or a solution to a complex problem. This mode is intensive and deliberately temporary.
• X-as-a-Service: One team uses a service provided by another with as little direct coordination as possible. This requires a clearly documented interface and reliable operations.
• Facilitating: One team, usually an enabling team, helps another overcome an obstacle or build a capability. Afterwards, the supported team works independently again.

The modes are not static. A new platform capability can be developed in collaboration and, once stable, consumed as X-as-a-Service. If difficulties arise later, a temporary switch to facilitating helps. This deliberate switching sets Team Topologies apart from rigid process frameworks.

Cognitive load as the benchmark

A central concept is cognitive load. It describes the total mental effort a team needs for its work: domain complexity, the technologies involved and internal processes.

When the load is too high, error rates rise, delivery slows down and motivation drops. The team types are therefore designed to relieve stream-aligned teams in a targeted way:

• A complicated subsystem team takes on specialised complexity.
• The platform covers recurring technical tasks.
• An enabling team closes knowledge gaps.

If a team is permanently overloaded, that is a clear signal to redesign team boundaries or support.

Case studies

Trade Me: a lean internal platform

The New Zealand online marketplace Trade Me replaced its monolith with microservices. This reduced dependencies in the code but increased the load on development teams, who now had to handle operations, security and infrastructure themselves. The company then introduced a deliberately lean internal platform, a so-called thinnest viable platform. According to the published case study, the time to deploy a new, simple service dropped from three weeks to one day.

Telenet: from the Spotify model to its own operating model

Belgian telecommunications provider Telenet had introduced agile methods based on the Spotify model but ran into structural limits. By redesigning its operating model along the principles of Team Topologies, the company removed these blockers and improved agility across departments.

Docker: rebuilding product development

After a strategic realignment, Docker rebuilt its product development organisation based on the concepts of Team Topologies. According to the company, this was a key factor in its subsequent growth.

Conclusion

Team Topologies is not a one-off reorganisation project but a way of thinking about the continuous evolution of an organisation. Team types, interaction modes and cognitive load form a shared language that helps identify friction early and adapt structures in a targeted way.

The goal is an organisation that delivers value quickly without overloading its people. This requires a leadership culture that hands responsibility to teams. Read more in our article Beyond Command and Control.