Team Topologies is a model for organizing software engineering teams around how work actually flows through a system, built on four fundamental team types and three ways those teams interact with each other. It was developed by Matthew Skelton and Manuel Pais and published as a book in 2019, and it gives organizations a shared vocabulary for questions that used to get answered ad hoc: how many teams should own a system, where should the boundaries between them sit, and who talks to whom and how often. Instead of organizing around technology layers (a database team, a frontend team, a network team), it organizes around the flow of value to users and treats team boundaries as an architectural decision, not just an HR chart exercise.
The reason Team Topologies exists is that most organizations design team structures around org chart convenience or historical accident rather than around how software actually gets built and shipped. A team that spans too many concerns burns out from context switching. A team that's too narrowly scoped becomes a bottleneck every other team has to queue behind. Conway's Law, the observation that systems end up shaped like the communication structure of the organization that builds them, means a bad team structure doesn't just create friction, it actively produces a worse architecture, because engineers build interfaces that mirror whatever team boundaries already exist, good or bad.
The mechanism is the four team types: stream-aligned teams (aligned to a single flow of business value, usually a product or user journey, and able to ship without waiting on another team for routine changes), platform teams (providing internal services that reduce the cognitive load on stream-aligned teams), enabling teams (helping stream-aligned teams adopt new practices or technology for a bounded period, then stepping back), and complicated-subsystem teams (owning a piece of the system that genuinely requires specialist knowledge, like a machine learning model or a codec). Layered on top are three interaction modes, collaboration, X-as-a-Service, and facilitating, which describe how any two teams should work together at a given point in time, and which are meant to change deliberately as the relationship matures rather than staying fixed forever.
By 2026, Team Topologies has become one of the more commonly cited frameworks among platform engineering and DevOps leaders trying to justify why they're restructuring, largely because it gives a name and a diagram to patterns many organizations were already groping toward without a shared language for them. It shows up constantly in platform engineering discourse specifically because the platform team type maps directly onto what a self-service internal developer platform is trying to be: a service consumed by stream-aligned teams, not a gatekeeper they have to negotiate with for every change.
This page covers the four team types and three interaction modes in detail, how the model reasons about cognitive load as the resource that limits how much a team can own, where the framework tends to get misapplied, and how a team actually starts adopting it without a disruptive company-wide reorg. The durable idea underneath the specific vocabulary is that team boundaries are not neutral, they shape what kind of software an organization is capable of building, and getting them wrong quietly taxes every team's throughput in a way that's easy to miss until someone names the pattern.
Stream-aligned teams are the center of the model and, in most organizations, should be the majority of teams. A stream-aligned team is aligned to a single, continuous flow of work, usually a product, a set of features, or a user journey, and it has everything it needs to build, test, and ship changes within that flow without routinely waiting on another team. The goal is fast flow: a stream-aligned team should be able to go from idea to production for most of its own changes without a ticket to another group sitting in a queue. In practice that means the team holds enough end-to-end responsibility, frontend, backend, testing, and often first-line operational ownership of what it ships, that a typical feature doesn't require a handoff to get live.
Platform teams exist to reduce the cognitive load a stream-aligned team carries. Instead of every stream-aligned team building and operating its own CI pipeline, provisioning its own infrastructure, and managing its own observability stack, a platform team builds those as internal, self-service capabilities. The test for whether something belongs on a platform team is whether it's a genuine, well-defined service with clear interfaces, not a dumping ground for anything that touches infrastructure. A platform team that requires a ticket and a two-week wait for every request isn't really operating as a platform; it's operating as a bottleneck wearing a platform's name. A good way to tell the two apart is to ask whether a stream-aligned team can get what it needs at 2 a.m. without waking anyone up; if the answer is no, the platform isn't self-service yet, whatever the team is called.
Enabling teams are deliberately temporary. They exist to help a stream-aligned team adopt a new skill, tool, or practice, work alongside that team for a bounded period, usually weeks to a few months, and then step back once the capability has transferred. An enabling team that never rotates out and instead becomes a permanent dependency has quietly turned into something else, usually either a hidden platform team or a bottleneck, and that drift is one of the more common failure modes teams run into after adopting the model. Good enabling teams tend to be staffed with people who enjoy teaching and handing off ownership, which is a different temperament than the one that thrives on owning a system indefinitely, and organizations that staff enabling teams with the wrong kind of engineer often find the rotation never actually happens.
Complicated-subsystem teams are the exception to "most teams should be stream-aligned." They exist because some pieces of a system genuinely require deep specialist knowledge that most engineers won't have and shouldn't need, a video encoding pipeline, a pricing algorithm with heavy math, a real-time bidding engine. The team owns that subsystem so stream-aligned teams can consume it without needing to understand its internals, similar to how a platform team is consumed but scoped much more narrowly to one hard technical problem rather than a broad internal service. The discipline here is restraint: it's tempting to declare any tricky piece of code a "complicated subsystem" to justify carving out a dedicated team, but the model reserves this type for cases where the complexity is genuinely intrinsic to the domain, not just messy because nobody's cleaned it up.
Collaboration mode is when two teams work closely together, sharing responsibility for a piece of work over a defined period, deliberately overlapping their boundaries to discover something neither team could have found alone. It's valuable specifically because it's high-bandwidth and high-friction at the same time; the friction is the point, since discovering unknowns often requires that close, sometimes uncomfortable back and forth. It's not meant to be the default steady state for two teams; it's meant to be temporary, aimed at a specific unknown that needs solving, and both teams should be able to name what that unknown is and roughly when they expect to have resolved it.
X-as-a-Service mode is the opposite: one team consumes something another team provides through a well-defined interface, with minimal need for direct communication. This is the target state between a stream-aligned team and a platform team once the platform's service is mature. A team pulling a database instance through a self-service portal, with clear documentation and no need to talk to a human, is X-as-a-Service working as intended. It's also the lowest-cognitive-load mode for the consuming team, which is exactly why it's the goal state for high-frequency interactions, and why platform teams should treat their internal documentation and interfaces with the same seriousness a vendor would treat a paying customer's experience.
Facilitating mode is when one team, often an enabling team, helps another team overcome a specific obstacle, typically by coaching or removing an impediment, without doing the work itself. It's lighter weight than collaboration and more human than X-as-a-Service, and it's the natural mode for the kind of temporary skill transfer enabling teams are built for. A platform team occasionally shifts into facilitating mode too, helping a struggling stream-aligned team understand why a migration is failing, without that becoming its permanent way of engaging with that team. The distinguishing feature of facilitating mode is that the facilitating team never actually does the work itself; it removes obstacles and builds capability, but the team being helped keeps ownership the whole time.
The point of naming these three modes explicitly is that teams often use the wrong one without realizing it and then wonder why the relationship feels broken. A platform team stuck in constant collaboration mode with every stream-aligned team it serves isn't really operating as a platform, since collaboration mode doesn't scale to many simultaneous relationships. Naming the mode a relationship is actually in, versus the mode it should be moving toward, is one of the more practical diagnostic tools the framework provides, and it's often more useful in a retrospective than any amount of debate about org charts, because it gives two teams a concrete, low-stakes vocabulary for describing what's actually going wrong between them.
The core constraint the whole model is built around is cognitive load: the total amount a person can hold in their head at once, split by the framework into intrinsic load (the inherent difficulty of the domain itself), extraneous load (friction from bad tooling, unclear documentation, or convoluted processes), and germane load (the productive effort of actually learning and problem-solving in the domain). A team's scope has to fit within what its members can realistically hold, and past that point, adding more responsibility doesn't produce proportionally more output, it produces mistakes, slower delivery, and burnout. Extraneous load is the one leaders have the most direct power over, since it's rarely inherent to the work itself, a confusing deployment process or an undocumented internal API is friction someone chose to leave in place, whether they meant to or not.
This reframes a common organizational instinct. When a team is struggling, the default move is often to add more people or assign more scope, but Team Topologies argues the opposite is frequently true: a struggling team is often already carrying more cognitive load than it can handle, and the fix is to reduce scope, not add capacity to an already-overloaded structure. A platform team's entire reason for existing, in this framing, is to strip extraneous load off stream-aligned teams so those teams' cognitive budget goes toward the actual product problem, not toward wrestling with infrastructure. Adding headcount to a team that's overloaded on extraneous load, rather than fixing the load itself, usually just adds another person who has to learn the same confusing systems everyone else is already struggling with.
Cognitive load is also the practical yardstick for deciding how many services or systems a single stream-aligned team can reasonably own. There's no universal number, a monolith versus a microservices architecture changes what a team can hold, but the model insists the question be asked explicitly rather than left to accumulate silently until a team is quietly drowning in systems nobody remembers assigning to them. Some organizations use a rough proxy, like the number of production services or the on-call page volume a team is responsible for, as an early warning signal, not because the number itself is meaningful in isolation, but because a sudden jump in it is a decent trigger to stop and ask whether scope needs rebalancing.
This is also why the model resists simply drawing more boxes on an org chart as a substitute for actually addressing load. Adding a team without reducing what an existing team owns just moves the coordination problem somewhere else; it doesn't remove it. The real fix is almost always to either genuinely reduce scope, automate away extraneous load through better platform capabilities, or accept that a team is doing fewer things well rather than many things adequately. Leaders who skip this step and just reorganize boxes on a chart tend to find the same team still overloaded three months later, just with a different name and possibly a new manager absorbing the same unresolved load.
Team Topologies is aimed squarely at organizations building and operating their own software over time, where team boundaries persist long enough to matter and where Conway's Law has real teeth. It's a natural fit for companies past the size where one team can build everything, typically somewhere north of thirty or forty engineers, where the coordination cost between teams has become a visible drag on delivery speed. It's also particularly relevant for organizations running a platform engineering initiative, since the model gives that effort a clear job description, reduce cognitive load for stream-aligned teams, rather than leaving "build a platform" as a vague mandate that can drift toward whatever the platform team finds interesting.
It's a poor fit, or at least overkill, for a five-person startup where everyone already talks to everyone daily and there's no real coordination problem to solve yet. Applying the full vocabulary of stream-aligned, platform, enabling, and complicated-subsystem teams to a company with two engineering teams tends to produce more process than problem, since the framework is answering a coordination question that doesn't exist yet at that scale. At that size, the entire company is effectively one stream-aligned team, and introducing formal team-type labels usually adds ceremony without adding clarity.
It's also not a project management framework and doesn't replace Scrum, Kanban, or whatever a team uses to run its day-to-day work. Team Topologies operates one level up, deciding what a team's boundary and mandate should be in the first place; the frameworks that run within that boundary are a separate decision entirely. Conflating the two, treating a Team Topologies adoption as equivalent to changing how standups run, misses the point of the model completely, and it's a common enough confusion that it's worth stating plainly: this is a structural model, not a ceremony or a ritual to bolt onto existing meetings.
And it's not a static diagram to draw once and file away. The book is explicit that team types and interaction modes should evolve as a system matures, an enabling team's job is to become unnecessary, and a collaboration relationship between two teams is meant to resolve into X-as-a-Service once the unknown it was created to explore has been discovered. Organizations that draw the topology once, put it in a wiki, and never revisit it are missing the part of the model that actually produces value: the deliberate evolution, not the one-time classification. A topology diagram that hasn't changed in two years is a signal worth investigating on its own, since real systems and real teams rarely stay static for that long without something quietly drifting out of sync with the documented structure.
Start by mapping what actually exists today, not what an ideal structure would look like. Name every current team, identify its actual mandate versus its stated one, and note the interaction patterns already happening informally. Most organizations discover that several of their teams are already functioning as something resembling stream-aligned, platform, or enabling teams, just without the label, and that discovery alone often clarifies more than a top-down redesign would. It also tends to surface teams operating with no clear type at all, doing a bit of everything for whoever asks loudest, which is usually the clearest sign of where cognitive overload is hiding.
Pick one or two friction points to address rather than attempting a full reclassification of every team at once. A common starting move is identifying a team that's become an accidental platform, quietly serving every other team's infrastructure requests through tickets, and formally giving it a platform mandate along with the self-service tooling to make X-as-a-Service mode actually possible, rather than leaving it stuck fielding one-off requests forever. Measuring the ticket queue and turnaround time for that team before and after the change gives a concrete way to show the reorganization actually worked, rather than relying on anecdote.
Treat enabling team engagements as genuinely temporary from day one. Set an explicit end date or exit criteria when an enabling team starts working with a stream-aligned team, and revisit that date rather than letting the engagement drift into permanence by default. The single most common way organizations get this wrong is standing up an enabling team with good intentions and never actually rotating it out, at which point it's either become a hidden platform team or a bottleneck wearing the wrong label. Writing the exit criteria down publicly, not just agreeing to them verbally, makes it much harder for the engagement to quietly extend itself past its useful life.
Finally, revisit the topology on a cadence, quarterly is common, rather than treating it as a one-time decision. As a platform capability matures, the mode between it and stream-aligned teams should shift from collaboration to facilitating to X-as-a-Service. As a complicated subsystem becomes better documented and less fragile, it may eventually fold into a platform capability or even be absorbed by a stream-aligned team. The model is meant to be read as a living description of an evolving system, not a permanent org chart, and the organizations that get the most value from it tend to be the ones that treat the quarterly review as seriously as they treat a roadmap review.
Team Topologies is a model for designing software team structures around four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, facilitating), developed by Matthew Skelton and Manuel Pais.
Matthew Skelton and Manuel Pais developed the model and published it as a book in 2019, drawing on their consulting experience with organizations struggling with team structure, communication overhead, and the effects of Conway's Law on software architecture.
A platform team provides a broad, reusable internal service, like CI/CD or infrastructure provisioning, consumed by many stream-aligned teams, while a complicated-subsystem team owns one specific piece of the system that requires deep specialist knowledge, like a pricing engine or a video codec, and is usually consumed by fewer teams for a narrower purpose.
Conway's Law observes that systems end up structured like the communication patterns of the organization that builds them, and Team Topologies takes that as a design principle, arguing that deliberately shaping team boundaries and interactions is a way of deliberately shaping the resulting software architecture, rather than leaving that shape to accident.
No, DevOps is a set of practices and cultural values about collaboration between development and operations, while Team Topologies is a structural model for how to organize teams; many organizations use Team Topologies as a way to actually operationalize DevOps goals through concrete team boundaries.
Stream-aligned teams should exist in essentially every organization building software, but platform, enabling, and complicated-subsystem teams are situational; a small organization might have no complicated-subsystem team at all if nothing in its system requires that level of specialization.
The model doesn't prescribe a precise numeric formula; instead it gives a qualitative framework (intrinsic, extraneous, and germane load) for teams and leaders to reason through when deciding whether a team's scope, number of systems owned, or number of responsibilities has grown past what's sustainable.
Yes, the model is about team boundaries and interaction patterns, not about microservices specifically, and a stream-aligned team can absolutely own a well-modularized part of a monolith as long as it can make most changes without waiting on another team.
The most common mistake is treating it as a one-time reorg exercise, drawing the four team types onto the existing org chart and then never revisiting interaction modes or team boundaries again, which misses the model's core point that topology should evolve as systems and teams mature.
