Team Topologies Overview

The Four Team Types

Matthew Skelton and Manuel Pais built the Team Topologies framework around a simple idea: organize teams around the flow of delivery, not around technical functions. Forget the old frontend/backend/QA silos. Instead, there are four team types that work together to ship software well.

Stream-Aligned Teams do most of the heavy lifting. Each one owns a single stream of work, whether that's a product, a service, a user journey, or a business domain. They handle everything from ideation through production support. The whole point is to cut down on handoffs. A stream-aligned team should be able to design, build, test, deploy, and run their service without getting stuck waiting on other teams. Most of your engineers should be on stream-aligned teams.

Platform Teams exist to lighten the load for stream-aligned teams. They build internal products (deployment pipelines, infrastructure primitives, observability tooling) that other teams can pick up and use on their own. A good platform team runs like an internal SaaS company. They maintain a product roadmap, treat stream-aligned teams as their customers, and measure success by adoption and developer satisfaction, not just feature count.

Enabling Teams bring in specialists who help stream-aligned teams pick up new skills, whether that's security practices, performance tuning, or testing strategies. The important thing is that they're time-boxed. An enabling team works alongside a stream-aligned team for a few weeks or months, transfers what they know, and moves on. The moment an enabling team becomes permanent, it has turned into a bottleneck.

Complicated-Subsystem Teams own the parts of your system that need deep specialist expertise, things like machine learning pipelines, real-time bidding engines, or low-level protocol implementations. Without this team type, you'd be asking a stream-aligned team to maintain niche expertise they barely use, which drives up cognitive load and risk.

Interaction Modes

Teams don't work in a vacuum. The framework lays out three interaction modes: Collaboration (two teams working closely together during discovery), X-as-a-Service (one team consumes another's output with minimal back-and-forth), and Facilitating (one team coaches another). Picking the right mode, and adjusting it over time, matters just as much as picking the right team type.

When to Apply

Team Topologies makes the most sense once you have enough engineers to form at least 3-4 teams, so roughly 20 or more people. Below that, the overhead of formal team types just gets in the way. Above 100 engineers, it becomes pretty much essential for keeping cognitive load manageable and delivery speed up.