Team Topologies and socio-technical design

Team design is architecture work

Chapter 3 showed that Conway's law is not a curiosity but a force: the system a group of teams builds tends to copy the way those teams communicate. If that is true, then deciding how teams are formed, what each owns and how they interact is an architectural decision, with consequences as lasting as choosing a database or an integration style. The discipline of designing software structure and team structure together is called socio-technical architecture.

The most influential practical framework for doing this is Team Topologies, by Matthew Skelton and Manuel Pais (IT Revolution, 2019; second edition 2025). It starts from a simple aim, fast flow: a steady, sustainable stream of small changes from idea to production, with little waiting between teams. It then offers a small vocabulary for designing organisations that achieve it: four team types, three interaction modes, a limit called team cognitive load, and a technique for finding the seams along which software and teams can be split.

Several premises run through the approach. The team, not the individual, is the unit of delivery: work is given to teams, ownership belongs to teams, and teams are long-lived, so that they accumulate knowledge of their domain and code instead of being assembled for a project and scattered afterwards. Teams are small, usually five to nine people, because trust and shared understanding decline quickly beyond that size (the authors draw on Robin Dunbar's research on group sizes). And team boundaries should be designed for the flow of change, not for the convenience of reporting lines or the history of who built what.

For architects this changes the job. A proposed service boundary is only good if some team can own it fully; a proposed team is only viable if the code it owns lets it work without asking permission from three other teams. The architect who draws boxes without asking who will own each one is designing half the system.

The four fundamental team types

Team Topologies argues that almost every team in a software organisation should be one of four types. The point of so few types is clarity: each type has a different purpose, a different way of measuring success and a different relationship with the other teams, so knowing a team's type tells everyone what to expect from it.

A stream-aligned team is aligned to one flow of change: a product, a customer journey, a user group or a business capability. It owns its part end to end, from discovery through build to running it in production, and should be able to deliver most changes without waiting for anyone. Stream-aligned teams are the default and should be the large majority; the other three types exist to reduce their burden.

A platform team provides internal services (deployment pipelines, a runtime environment, observability, data infrastructure) as a product that stream-aligned teams consume through self-service. A good platform is judged by its users' speed, not by its own feature list. An enabling team consists of specialists who help other teams acquire a capability they lack, such as test automation, observability practices or a new framework, and then move on; its success is measured by the other team no longer needing it. A complicated-subsystem team owns a part that needs rare expertise, such as a pricing engine built on actuarial models, a route-optimisation solver or a video codec, so that stream-aligned teams can use it without having to master it. The book stresses that this type should be used sparingly and only where the specialism is genuine.

Three interaction modes

Team types say what teams are; interaction modes say how they work together. Skelton and Pais argue that ambiguous, ad hoc interaction between teams is a major source of delay, because every unplanned conversation is a dependency. They therefore recommend that every pair of teams that must interact chooses one of three modes deliberately, for a stated period.

In collaboration, two teams work closely together on a shared goal, with blurred responsibilities, for example while discovering how a new capability should be split. It produces fast learning but costs both teams capacity and cognitive load, so it should be time-boxed. In X-as-a-Service, one team provides something (an API, a platform capability, a library) that another consumes with little or no collaboration; this scales well but only works once the boundary is well understood and the interface is good. In facilitating, one team, typically an enabling team, helps another learn or remove an obstacle.

The modes are meant to change. A common sequence is discover then settle: a platform team collaborates with one stream-aligned team for a few weeks to design a new capability, then turns it into a self-service offering and moves to X-as-a-Service. The modes also work as a sensing mechanism. If a team that is supposed to consume a service as a service keeps needing meetings, the interface or the boundary is probably wrong; if two teams have been collaborating for a year, they may really be one team, or the split between them may be in the wrong place.

Cognitive load as a design constraint

The idea of cognitive load comes from educational psychology. John Sweller's cognitive load theory, first published in 1988, started from the observation that human working memory can hold and process only a few new items at a time, so instruction should be designed not to overload it. The theory distinguishes intrinsic load (the inherent difficulty of the material), extraneous load (difficulty caused by the way the task is presented) and, in later work, germane load (effort that builds lasting understanding). Researchers still debate whether germane load is a separate category, and Team Topologies uses all three as a practical heuristic rather than a measurement.

Section 3.7 introduced the team version of this idea: the total a team must hold in its heads to build, run and change what it owns. What matters here is how to use it as a design constraint. When an architecture assigns a team more than it can understand, the effects are predictable: slower delivery, shallow fixes, fragile on-call, knowledge concentrated in one or two people and, eventually, departures. These are the same symptoms often blamed on poor engineers or poor code.

The book offers rules of thumb for sizing a team's responsibilities by domain complexity: give each domain to a single team; a team can usually handle two or three simple domains; a team that owns a complex domain should own nothing else; and no team should own two complicated domains. Teams can also be asked directly, for example with a short survey on how well they understand their systems, how confident they feel when on call and how much time goes on tooling rather than the domain. Rising ticket queues, long onboarding times and frequent handovers to the one person who understands a component are useful indirect signals.

The architectural responses mirror the three kinds of load. Reduce extraneous load with platforms, automation, paved paths and good documentation. Bound intrinsic load by drawing service and module boundaries so that each team's share of the domain is coherent and of a manageable size, and by putting deep specialisms behind complicated-subsystem interfaces. Protect germane load by leaving time for learning, which is where enabling teams help.

Team APIs and the thinnest viable platform

If teams interact through deliberate modes, each team needs a clear face to the rest of the organisation. Team Topologies calls this the team API: everything the team offers and expects. It includes the technical API (endpoints, events, libraries and their versioning and deprecation rules) but also the human interface: documentation and onboarding guides, the team's roadmap and current priorities, its working practices, the channels where it can be reached, how to request work from it and what response times to expect.

Writing a team API down is a cheap and revealing exercise. It forces a team to say what it owns, which usually exposes unowned services and contested data, and it gives other teams a way to interact without a meeting. Many organisations keep it as a short page in the team's repository, reviewed each quarter alongside the architecture documentation.

The platform deserves particular care because it is where good intentions most often go wrong. A platform built as a large internal project, with a long roadmap and mandatory adoption, can easily add cognitive load rather than remove it. Skelton and Pais recommend the thinnest viable platform: the smallest set of services, documentation and standards that genuinely speeds up its users. For a small organisation that may be a well-kept page listing the cloud provider services teams should use and how; for a large one it may be an internal developer platform. Platform engineering is covered in depth in Chapter 10; the essential point here is that a platform is a product whose customers are other teams, and it should be designed and measured as one.

Fracture planes: where to split software and teams

When a part of the system has grown too big for one team, it has to be split, and the split must work for both the code and the teams. Team Topologies calls the natural seams along which software can be divided fracture planes. The book lists several, and the first is usually the best: a bounded context from domain-driven design, because a boundary that follows the language and rules of the business tends to keep related changes together.

The others are useful when they line up with a real difference in how parts of the system must be treated. Splitting along a technology boundary alone (for example a mobile team and a back-end team) is generally the weakest choice, because most changes then cross it, which is the layered team structure Conway's law warns about.

Conway's law, the inverse manoeuvre and its limits

Team Topologies is, in effect, a toolkit for the inverse Conway manoeuvre that Section 3.7 described: decide the architecture you want, then shape teams and interaction modes so that Conway's law pushes the system towards it. Its additions are practical. Team types say what kind of team should own each part; interaction modes say which team boundaries are meant to be thin (X-as-a-Service) and which are temporarily thick (collaboration); cognitive load says how much each team can own; fracture planes say where to cut.

The limits from Section 3.7 still apply and are worth restating in this setting. Reorganising teams does not restructure a tightly coupled codebase: for months after a reorganisation the new teams will fight the old architecture, which is why team changes and architecture changes should be planned as one programme. Boundaries that are hardened into teams too early make mistakes expensive, so many organisations keep uncertain boundaries inside one team or one modular monolith until they have evidence. And frequent reorganisations destroy the long-lived team knowledge the approach depends on.

Practitioners also disagree about how literally to apply the framework. Supporters value the shared vocabulary, which turns vague complaints (we keep waiting for the data team) into designable questions (what interaction mode do we want with the data team, and what would make it X-as-a-Service?). Critics warn that the four types are often applied as labels to an unchanged organisation, that real teams sometimes mix types (a platform team that also owns a complicated subsystem) and that the framework says little about funding, management structure or incentives. Both points are fair: the types are a design aid, not an org chart, and the authors themselves present them as a starting point for continuous adjustment.