# Team Topologies: Organising Teams Around the Flow of Work

Author: Marin Niehues, Niehues Consulting · Published: 2023-10-26 · Organisation Design
Source: https://www.niehuesconsulting.de/en/blog/team-topologies-organising-teams-for-flow/

Team Topologies is an organisational approach by Matthew Skelton and Manuel Pais that shapes teams around the flow of work and prescribes four team types and three interaction modes. The aim is for as many teams as possible to own a stream of work from idea to delivery without waiting constantly on others. This article explains the model from its primary source, sets out the introduction in six steps and gives the questions that decide whether it fits your organisation.

Many organisations are divided by discipline: development, test, operations, architecture. Each unit works efficiently within its field, and every order passes through several handovers before it reaches the customer. The handovers create waiting time, and in many workflows waiting time makes up the largest part of lead time. Team Topologies starts at this point and asks how teams can be shaped so that a stream of work stays within one team as far as possible.

**Teams are shaped around the flow of work for as long as the task does not overload a team. Where a team's load grows beyond its capacity to absorb it, a second kind of team is needed that provides capabilities.**

## What is Team Topologies?

Team Topologies is an approach to organisation design that Matthew Skelton and Manuel Pais published in 2019 in a book of the same name. It combines four ideas: teams are the smallest unit of the organisation, their task follows the flow of value creation, their workload must not exceed their cognitive capacity, and collaboration between teams follows a few clearly named modes.

The foundation is an observation that Melvin Conway made in 1968: organisations that design systems produce designs that copy their own communication structure. A study by MacCormack and colleagues from 2012 supports this mirroring hypothesis in software products. Skelton and Pais draw the reverse conclusion: whoever wants a particular system architecture designs the team structure first. This approach is known as the "inverse Conway manoeuvre". Added to it is the theory of cognitive load associated with John Sweller, under which people can process only a limited amount of task complexity at once. A team expected to master too many systems and disciplines delivers more slowly and with more errors.

## Which four team types does Team Topologies distinguish?

Team Topologies distinguishes four team types that differ clearly in task and shape. The first is the stream-aligned team, which owns a continuous stream of work such as a product, a customer group or a business process. It is the normal case and should make up most of the teams in the organisation. The other three types support these teams.

**The four team types according to Skelton and Pais**
Criterion | Stream-aligned team | Enabling team | Complicated-subsystem team | Platform team
Task | Owns a stream of work through to delivery | Helps other teams acquire a new capability | Maintains a part that needs specialist knowledge | Provides internal services that other teams use themselves
Typical examples | Customer portal, product line, order handling | Coaching in automation, testing practice | Algorithms, calculation core, image processing | Infrastructure provision, data platform
Collaboration | Uses the platform as a service, takes help from the enabling team | Time-limited, without ownership of the stream | Provides its output as a service | Service with a clear interface, like an internal product
Measure of success | Lead time, customer benefit | Grown capability of the supported teams | Relief for the stream-aligned teams | Usage and satisfaction of the teams

The enabling team withdraws as soon as the supported teams master the capability themselves. The complicated-subsystem team arises only where specialist knowledge is so demanding that no stream-aligned team can handle it on the side. The platform team treats its services like a product with internal customers. The authors speak of a "thinnest viable platform", one that does just enough to make the stream-aligned teams faster.

## Which three interaction modes exist?

Team Topologies provides three interaction modes between teams: collaboration, X-as-a-service and facilitating. Collaboration means that two teams work closely on a shared task for a limited time, for example to clarify a new interface. X-as-a-service means that one team provides something to another through a clear interface, without both needing to coordinate constantly. Facilitating means that one team coaches another in a capability.

The practical benefit is that every relationship between two teams has one of these modes and an end date or a review. Unclear relationships, in which everyone asks everyone for advice, create coordination effort and dependencies. Where time is lost between idea and delivery is described in the article [Shortening time to market](/en/blog/reduce-time-to-market/).

## How do you introduce Team Topologies in six steps?

The introduction follows six steps that start from the flow of work and change the structure only at the end.

1. Identify streams of work: the organisation describes which kinds of orders run from intake to the customer, with the departments involved and the waiting times between them. The result is a map of value streams.
2. Assess cognitive load: for each existing team, it is recorded how many systems and products it looks after and where people switch between topics. Teams with a very large number of responsibilities are candidates for a new shape.
3. Shape stream-aligned teams: one team per stream owns it from requirement to operation. The team stays small enough for all members to trust one another and to keep the task in view together.
4. Add supporting teams: the organisation checks where recurring tasks burden several teams and founds a platform or specialist team for them. An enabling team is created only with a clear task and an end date.
5. Define interaction modes: for each relationship between teams it is fixed whether they collaborate, use a service or receive facilitation, and when this is reviewed.
6. Measure and adjust: lead time, number of handovers and waiting time between teams show whether the shape works. At fixed intervals it is adapted to the measured values.

**Questions for the executive team**
- How many handovers does a typical order pass between intake and customer?
- Which team owns a stream from requirement to operation?
- Where are individual teams responsible for more systems or disciplines than they can master?
- Which relationships between teams have neither a mode nor an end date?
- Which metric shows that the new shape reduces waiting time?

## What is Team Topologies suited to, and what is it not?

Team Topologies suits organisations that develop and run digital products or services and where handovers between functions slow delivery. It fits as soon as several teams contribute to the same delivery, because the cost of coordination between them then becomes visible. For a single team, a clear mandate and a good way of working, for example with Kanban, are usually enough. How Kanban steers flow within a team is described in the article [Introducing Kanban: managing flow instead of utilisation](/en/blog/introducing-kanban-flow-over-utilisation/).

The model is no template for departmental boundaries outside product development. Where work consists of routine processes with fixed rules, as in accounting, a split by discipline often gives better specialisation. It also replaces no decision on leadership and accountability, since it defines teams but not who decides on budget and priorities. These questions remain the task of the executive team. An illustrative example: a mechanical engineering firm with a service business and a customer portal checks whether order entry, spare-parts ordering and appointment booking sit in one team. If they sit in three departments, at least two handovers arise per order, and the value-stream map shows where the waiting time sits.

## Team Topologies with Niehues Consulting

[Niehues Consulting](/en/) is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. The field of organisation design covers the shape of teams, roles and decision paths, to which Team Topologies contributes as one of several building blocks.

The approach follows the Niehues Delivery Model. Three test questions matter for team design: who decides, who delivers, who uses? Which roles, decision paths and interfaces does operation need? Who is accountable for operation from day one? The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange through the [contact page](/en/#kontakt).

**Conclusion**
Team Topologies shapes teams around the flow of work, limits cognitive load per team and governs collaboration through three interaction modes. The introduction starts from value streams and changes structure only once waiting time and load are visible. For organisations with several product teams it is a sound framework; for routine areas with fixed rules it is the wrong template.

**Sources**
- Skelton, Pais: Team Topologies: Organizing Business and Technology Teams for Fast Flow, book, 2019
- Conway, Melvin E.: How Do Committees Invent?, Datamation, 1968
- MacCormack, Baldwin, Rusnak: Exploring the Duality between Product and Organizational Architectures, Research Policy, 2012
- Sweller, John: Cognitive Load During Problem Solving: Effects on Learning, Cognitive Science, 1988

## Frequently asked questions

### What are the four team types in Team Topologies?

Team Topologies knows stream-aligned teams, enabling teams, complicated-subsystem teams and platform teams. The stream-aligned team owns a stream of work through to delivery, and the other three types relieve it. Stream-aligned teams are the normal case, and the other types arise only where needed.

### Who created Team Topologies?

Matthew Skelton and Manuel Pais created Team Topologies and published it in a book in 2019. The approach builds on Conway's observation about organisations and system design and on the theory of cognitive load. The authors keep developing it through materials and workshops.

### What is Conway's Law?

Conway's Law, formulated by Melvin Conway in 1968, says that organisations designing systems produce designs that copy their communication structure. A company with four separate departments tends to build a system with four separate parts. This is why the structure of teams influences the architecture of the product.

### How large should a team be in Team Topologies?

A team stays small enough for all members to trust one another and to keep the task in view together, and the authors point to research on the size of trusting groups. The size follows cognitive capacity, because a team should master all systems and disciplines of its stream. If the stream grows beyond that, it is split or relieved by a platform team.

### What is cognitive load in teams?

Cognitive load is the amount of information and complexity a team must process at the same time. It rises with the number of systems, disciplines and customers it is responsible for. When the load falls, the speed and quality of delivery rise.

### Does Team Topologies work with Scrum?

Yes, Team Topologies governs the shape of teams, and Scrum governs the way of working within a team. A stream-aligned team can work with Scrum or Kanban. The two approaches complement each other and do not compete.

### Is Team Topologies only for software companies?

Team Topologies was written for software and technology organisations, and its examples come from that field. It can be applied wherever teams produce a product or service in a continuous stream. For routine processes with fixed rules a split by discipline often fits better.

### How long does it take to implement Team Topologies?

The map of value streams and the assessment of load come first, and the new shape of teams follows in stages. A first shape for one stream can be tested within a quarter, and the effect then shows in lead time. Reorganising all teams at once raises the risk and is rarely necessary.