Understanding Team Topologies
Team Topologies is a framework for organizational design in software engineering, introduced in the 2019 book of the same name. Its central claim is that team structure directly shapes system architecture — an application of Conway’s Law — so organizations should design team boundaries deliberately, rather than letting them emerge accidentally from reporting lines or historical accident. Platform engineering as a discipline draws heavily on this framework, and much of the vocabulary used around internal platforms — platform team, stream-aligned team, X-as-a-service — comes directly from it.
The Four Team Types
- Stream-aligned team: aligned to a single, continuous flow of work in a business domain — a product area, a customer journey, or a feature set — and responsible for delivering it end to end, ideally without needing to hand work off to another team.
- Platform team: provides internal services and APIs, such as a self-service infrastructure layer or a developer portal, that reduce the cognitive load stream-aligned teams would otherwise carry for underlying infrastructure and tooling. Platform teams are expected to operate with a “platform as a product” mindset, treating other engineering teams as customers.
- Enabling team: made up of specialists who work temporarily and closely with a stream-aligned team to help them adopt a new capability — for example, coaching a team through adopting distributed tracing — then step back once the skill has transferred.
- Complicated-subsystem team: owns a subsystem that genuinely requires deep, specialized expertise to build and maintain, such as a video codec or a machine learning model, where the complexity can’t reasonably be absorbed by a stream-aligned team.
The Three Interaction Modes
Team Topologies also defines how these team types should interact: collaboration (working closely together for a bounded period, usually to solve a novel problem), X-as-a-service (consuming another team’s well-defined API or platform with minimal ongoing collaboration), and facilitating (an enabling team helping unblock another team). The framework recommends keeping collaboration mode intentionally time-boxed, since prolonged collaboration tends to create unwanted coupling between teams.
A Concrete Example
A platform engineering team builds and operates an internal developer platform, offering it to ten stream-aligned product teams primarily in X-as-a-service mode: those teams consume the platform’s self-service infrastructure and CI/CD capabilities without needing to understand Kubernetes internals. When one of those teams wants to adopt distributed tracing for the first time, an SRE enabling team works alongside them in collaboration mode for a few weeks to transfer the knowledge, then withdraws once the team can operate tracing independently.
Why Organizations Adopt It
As engineering organizations scale past the point where informal, ad hoc team structures work, duplicated effort and unclear ownership become the norm. Team Topologies gives organizations a vocabulary and a set of patterns for deciding, deliberately, what a given team should own and how much it should depend on others — directly addressing the cognitive load problem that under-designed org structures create.
Trade-offs and Best Practices
Reorganizing around these team types is politically difficult and takes real time; it is not a lightweight framework to bolt on. Platform teams, in particular, risk becoming gatekeeping bottlenecks rather than enabling self-service if they don’t apply platform-as-a-product discipline — a real roadmap, documentation, and support commitments — to their own offering.
- Treat the topology as something to revisit periodically, not a one-time reorg.
- Keep collaboration-mode engagements time-boxed and outcome-focused to avoid unintended coupling.
- Review platform team interfaces (APIs, self-service portals) regularly against the actual cognitive load they’re meant to absorb.
Frequently Asked Questions
What is Team Topologies?
Team Topologies is an organizational design framework, developed by Matthew Skelton and Manuel Pais, that defines four fundamental team types and three team interaction modes for structuring engineering organizations around fast flow and sustainable cognitive load.
How does Team Topologies work?
Team Topologies works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Team Topologies matter?
Teams adopt Team Topologies to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Team Topologies?
Use Team Topologies when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
