Team Topologies: a model for organizing software teams
Large software estates need large numbers of people, and large numbers of people need deliberate organization into effective teams. Business-capability-centric teams keep software responsive to customer needs, but they can easily be overwhelmed by the range of skills their work demands. Team Topologies, the model developed by Matthew Skelton and Manuel Pais, addresses this by defining four team types and three interaction modes. Its goal is to foster healthy interactions that let business-capability teams sustain a steady flow of valuable software.
The model's primary unit is the stream-aligned team: a long-running, business-capability-focused group that treats its software as a product. Such teams are full-stack and full-lifecycle, owning front-end, back-end, database, UX, testing, deployment, monitoring, and prioritization. They are outcome-oriented rather than activity-oriented, and ideally sized as a two-pizza team. In a large organization, many such teams exist and share common needs like data storage, networking, and observability — even while supporting different business capabilities.
The platform's real job: reducing cognitive load
Small, full-lifecycle teams need protection from non-focal concerns. Off-the-shelf platforms like Ruby on Rails cover some cases, but many products require integrating multiple platforms and internal services, plus following corporate standards. The answer, in many organizations, is an internal platform that integrates these pieces — and the team that builds it is the platform team.
Smaller organizations may need only one such team, producing a thin layer over external products. Larger platforms require more people than two pizzas can feed, so the authors now describe a platform grouping of multiple platform teams.
A platform's defining characteristic is that stream-aligned teams use it mostly self-service: they operate their own products and direct their own platform usage without elaborate collaboration. In Team Topologies terms, this is X-as-a-Service mode. Platform teams, however, must build their services as products — which requires genuine understanding of customer needs. That often means using collaboration mode while the service is being built, with the understanding that this intensive partnership is temporary and should give way to X-as-a-Service once the platform matures.
None of this is especially novel on its own. Breaking organizations into business-aligned and technology-support teams predates enterprise software, and many writers have urged making business teams full-stack and full-lifecycle. The sharp insight of Team Topologies is different: full-stack, business-aligned teams often face excessive cognitive load, which undermines the desire for small, responsive teams. The platform's primary benefit, then, is not standardization or cost reduction — it is reducing that load. That framing alters platform design decisions, roadmaps, and the way platform teams measure success.
Specialists and subsystems
Some capabilities need specialists who can invest deeply in topics important to many teams. A security specialist, for example, may need more time studying and engaging the security community than a stream-aligned team can afford. Such people form enabling teams, whose job is to grow skills inside other teams — so those teams can stay independent and own their services fully. Enabling teams work primarily through facilitating mode: coaching and educating rather than writing standards or enforcing conformance.
Occasionally, a stream-aligned team's work contains a demanding aspect that justifies a dedicated group — the complicated-subsystem team. Its purpose is to reduce cognitive load on the stream-aligned teams using that subsystem, which can be worthwhile even with only one client. Such teams usually strive for X-as-a-Service interaction, falling back on collaboration mode only for short periods.
Team Topologies also offers graphical symbols for team and interaction diagrams. The current standard shapes differ from those in the book; a recent article explains how to use them.
A useful oversimplification
Team Topologies explicitly acknowledges Conway's Law: the team structure it encourages shapes the software architecture into responsive, decoupled components aligned with business needs. Like any model, it is incomplete — real organizations rarely sort cleanly into four team types and three interaction modes. But that constraint is precisely what makes it useful. As a tool, Team Topologies pushes organizations toward operations where stream-aligned teams maximize flow by keeping their cognitive load light.
