Team Topologies

Origin

Matthew Skelton and Manuel Pais, 2019

Level

301 · Advanced

Fits

Scale-up, Enterprise

Time to apply

half a day to map today's teams, then a quarter to change one interaction

What you need

a list of every team and the work each one owns · a map of who depends on whom today, taken from tickets and requests, not from the org chart · one leader who can change team boundaries

Team Topologies is an approach to organization design for technology and knowledge work. Matthew Skelton and Manuel Pais published it as a book in 2019 through IT Revolution Press, with a foreword by Ruth Malan. The first edition has eight chapters and a conclusion in three parts: teams as the means of delivery, topologies for flow, and interactions for innovation. A second edition of 304 pages followed on 23 September 2025, adding case studies from several industries. It treats the team, not the individual or the department, as the basic unit of delivery, and asks how many teams of which kind a company needs and how they should work with each other.

The approach rests on four team types, three ways for teams to interact, and one limit that governs both: the amount of complexity a team can carry. It is meant for companies large enough to have many teams and shared services, which is why the stages here are scale-up and enterprise.

The four team types

There are four. teamtopologies.com defines them this way.

The last column is our illustration. The book is written for software and IT teams, and we found no source that tests these types in marketing.

The three interaction modes

Teams interact in one of three ways, per the authors’ site. In collaboration, two teams work together for a defined period to discover something new. In X-as-a-Service, one team provides and another consumes, with little back-and-forth. In facilitating, one team helps and mentors another.

The point is to choose the mode on purpose, per the book’s chapter 7 on picking suitable modes. Collaboration is costly for both teams, so it suits discovery and should end. A stable service is better consumed than co-built. The eight-step guide from IT Revolution, published in May 2021, tells readers to limit collaboration deliberately and to keep revisiting the structure as the work changes.

Cognitive load

Cognitive load is the amount of complexity a team can hold before its decisions and speed suffer. The Team Topologies site says each new tool, responsibility or domain adds to it, and that overloaded teams decide poorly and move slowly.

The term comes from educational psychology. Sweller used it in 1988 for the limited working memory a learner has, and Sweller, van Merrienboer and Paas developed it further in 1998. Individual limits are well studied, though the figures differ by researcher. Miller put short-term memory near seven items in 1956, and Cowan argued in 2001 for about four chunks. The book’s contents list shows it also uses Dunbar’s number to reason about how teams scale. A team’s load is a harder thing to measure than a person’s, and we found no validated instrument for it. The practical test is to ask the team where it feels stretched.

Conway’s law and the inverse Conway maneuver

Conway’s law says systems copy the communication structure of the organizations that build them. Melvin Conway wrote in How Do Committees Invent?, published in Datamation in April 1968, that such organizations are “constrained to produce designs which are copies of the communication structures” of the organization.

Choices about where to cut a system are older than the law. Parnas compared two ways of splitting the same program into modules in 1972. The inverse Conway maneuver turns Conway’s law around: design the teams so the system comes out the way you want. Skelton and Pais describe it in a November 2020 article from chapter 2 as reshaping team communication before the software is finished.

What the research says

The evidence for the mirroring idea behind Conway’s law is real but mixed. MacCormack, Baldwin and Rusnak compared matched pairs of products. Products from loosely coupled organizations were more modular, by up to a factor of eight on one coupling measure. A review of 142 studies by Colfer and Baldwin found mirroring common but not universal, and open collaborative projects, mostly software, did not support it.

Other studies tie structure to results. Nagappan, Murphy and Basili built a set of organizational complexity metrics, including counts of engineers and depth of ownership, and found they predicted failure-prone binaries in Windows Vista with higher precision and recall than churn, complexity or dependency measures. Herbsleb and Mockus reported that work items spread across sites took about two and a half times as long as colocated ones. Cataldo and Herbsleb studied two large projects at two companies and linked gaps between needed and actual coordination to more failures, and closer fit to higher productivity. Bird and colleagues found in Vista and Windows 7 that code changed by many low-expertise contributors was linked to more faults, which bears on how clearly a team owns its part. Herbsleb and Grinter found in a multi-site project that integration, not writing components, caused the most trouble once informal communication broke down.

These studies support the logic behind the approach. In our search we found no peer-reviewed study that tests the four team types against outcomes, and the case studies on the authors’ site, such as Docker and PureGym, are accounts from supporters.

Using it in marketing and growth

Treat this section as our extension. The book is about software, and nothing here has been tested in marketing.

The logic carries over where marketing work has hand-offs. A campaign that needs design, copy, data, legal and a developer in sequence has the shape of a software change waiting on three teams. Mapping streams, such as a country launch or a lifecycle program, and giving each one a team that owns it end to end is the stream-aligned move. Shared analytics, tracking and reporting fit the platform type. The growth team structure page covers independent and functional growth models, and marketing team structure covers the wider org. Cognitive load adds a check those pages lack: how many channels, markets and tools one team can run before quality drops. Span of control sets the manager’s limit, and operating model design places team design within the wider model.

Team Topologies says who owns work and how teams relate, not how to schedule it. Scrum and kanban run inside a team once its boundaries are set. A Growth Lab plan starts from a map of the streams and their owners.

How to apply Team Topologies, step by step

1. Name the streams of work. List the flows that run from an outside need to a result the customer sees, such as onboarding a merchant or booking a patient. Pick the two or three that matter most. Result: a short list of streams.
2. Sort today's teams into the four types. Mark each team as stream-aligned, enabling, complicated-subsystem or platform. Teams that fit none are usually a hand-off layer. Result: a map of missing types.
3. Measure the load on each team. Count the domains, tools and recurring requests each team carries, and ask where it feels stretched. Result: a ranked list of overloaded teams.
4. Draw the interactions you have today. For every pair of teams that depend on each other, label the link collaboration, X-as-a-Service or facilitating. Flag collaboration with no end date. Result: an as-is interaction map.
5. Choose the target and move one boundary. Decide which links become X-as-a-Service and which teams shrink. Change one boundary first, with a review date. Result: one live change.
6. Review the interactions. Ask whether the link did its job. A collaboration that produced a stable service becomes X-as-a-Service. Result: an updated map and the next boundary.

Examples

A fintech marketing organization

Illustrative, no real company implied. A payments company has separate teams for paid acquisition, lifecycle email, content and analytics, and every campaign for a new country needs all four. Treating each country launch as a stream, the company forms stream-aligned teams per region. Analytics becomes a platform team offering a shared reporting layer as a service, and a small enabling team coaches regional teams on experiment design.

A clinic network

Illustrative, no real clinic implied. A group of clinics runs one central call centre, one website team and one reputation team. Patients booking an appointment cross all three. The group forms a stream-aligned team around the booking journey, with the call centre scripts, the booking page and review requests in one team. The website team's shared tooling remains a platform offered to that team.

When to use it

Use it when work crosses many teams and hand-offs, when a team is overloaded and slow, or before a reorganization. It suits organizations with several teams and some shared services.

When not to use it

Skip it when one small team can hold the whole system in its head. It was written for software and IT delivery, and its use in marketing or other functions is an extension that the authors' book does not test.

Common mistakes

• Relabelling teams with the new names and changing no boundaries or hand-offs.
• Leaving collaboration running with no end date, so two teams stay tied together and neither can move on its own.
• Building a platform team that pushes mandatory tools instead of a product that stream-aligned teams want to use.
• Ignoring Conway's law and moving the org chart while the architecture and the tools stay as they were.
• Copying another company's team map instead of mapping your own streams and loads.

FAQ

What are the four team types in Team Topologies?

Stream-aligned teams own a flow of work end to end. Enabling teams help others close skill gaps. Complicated-subsystem teams hold work that needs deep specialist knowledge. Platform teams provide an internal service that speeds up stream-aligned teams..

What is the inverse Conway maneuver?

It means designing teams so that the organization produces the system structure you want, instead of letting the existing org chart decide it. Skelton and Pais describe it as reshaping team communication before the software is finished. Conway's law dates to Melvin Conway's 1968 paper.

What is cognitive load in Team Topologies?

It is the amount of complexity a team can hold and still work well. The authors say each added tool, responsibility or domain raises it, and an overloaded team decides poorly and moves slowly. The term comes from educational psychology, where John Sweller introduced cognitive load theory in 1988.

Which edition of the Team Topologies book should I read?

The first edition appeared in 2019 from IT Revolution Press. IT Revolution lists a second edition dated 23 September 2025, with case studies from several industries and a new foreword.

Sources

1. IT Revolution Press, Team Topologies (2019), excerpt with copyright page and table of contents
2. IT Revolution, Team Topologies, 2nd edition
3. Team Topologies, Key concepts
4. Team Topologies, Books
5. Skelton and Pais, Conway's law: critical for efficient team design in tech, IT Revolution, 2020
6. IT Revolution, Get started with Team Topologies in 8 steps, 2021
7. Conway, How do committees invent?, Datamation, 1968
8. MacCormack, Baldwin and Rusnak, Exploring the duality between product and organizational architectures, Research Policy, 2012
9. Colfer and Baldwin, The mirroring hypothesis: theory, evidence, and exceptions, Industrial and Corporate Change, 2016
10. Nagappan, Murphy and Basili, The influence of organizational structure on software quality, ICSE, 2008
11. Bird, Nagappan, Murphy, Gall and Devanbu, Don't touch my code! Examining the effects of ownership on software quality, ESEC/FSE, 2011
12. Herbsleb and Mockus, An empirical study of speed and communication in globally distributed software development, IEEE Transactions on Software Engineering, 2003
13. Herbsleb and Grinter, Splitting the organization and integrating the code: Conway's law revisited, ICSE, 1999
14. Cataldo and Herbsleb, Coordination breakdowns and their impact on development productivity and software failures, IEEE Transactions on Software Engineering, 2013
15. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, 1972
16. Sweller, Cognitive load during problem solving: effects on learning, Cognitive Science, 1988
17. Sweller, van Merrienboer and Paas, Cognitive architecture and instructional design, Educational Psychology Review, 1998
18. Miller, The magical number seven, plus or minus two, Psychological Review, 1956
19. Cowan, The magical number 4 in short-term memory, Behavioral and Brain Sciences, 2001
20. Dunbar, Neocortex size as a constraint on group size in primates, Journal of Human Evolution, 1992

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn