The Four Fundamental Team Types

In the Team Topologies model, every team in your organization should map to one of exactly four types. This constraint is intentional — it forces clarity about purpose and prevents the proliferation of ambiguous "Center of Excellence" or "Tiger Team" structures that nobody can explain.

1. Stream-Aligned Team

• Role: Aligned to a specific, continuous stream of work — a product feature area, a user journey, a business domain, or a customer persona.
• Goal: Deliver value directly to the end user or customer with minimal dependency on other teams.
• Motto: "You build it, you run it."
• Example: The "Checkout" team owns everything from the shopping cart UI to the payment processing backend to the on-call rotation for those services.
• Key point: This is the primary team type. All other team types exist solely to support Stream-Aligned teams. If you are adding a Platform team, ask: which Stream-Aligned teams does this serve, and how does it reduce their load?

2. Platform Team

• Role: Provides internal services, tools, and APIs that reduce the cognitive load of Stream-Aligned teams.
• Goal: Enable stream teams to deliver work with substantial autonomy by making the right way the easy way.
• Motto: "Make the right way the easy way."
• Example: A Platform team builds a self-service deployment CLI. Stream teams run acme-deploy my-service and the platform handles Kubernetes manifests, TLS certificates, and observability wiring automatically.
• Key point: A Platform team is a product team whose customers are internal engineers. They maintain a roadmap, collect feedback, and measure adoption — not ticket queues.

3. Enabling Team

• Role: A small group of specialists in a specific domain (Security, Architecture, Observability, Testing) who help Stream-Aligned teams bridge a capability gap.
• Goal: Upskill the stream team, then step back. They do not own the software; they teach.
• Motto: "I'm here to teach you how to fish."
• Example: A Security Enabling team embeds with the Payments team for six weeks to help them implement SAST scanning in their CI pipeline. After six weeks, the Payments team owns and runs it themselves.
• Key point: An Enabling team that never leaves has become a dependency, not an enabler. Success is measured by whether the stream team no longer needs them.

4. Complicated Subsystem Team

• Role: Responsible for a part of the system that requires such deep, specialized knowledge that it would overwhelm a normal stream team.
• Goal: Encapsulate complexity behind a clean interface so stream teams can consume it without understanding the internals.
• Motto: "Don't worry about the math; just use the interface."
• Example: A team of signal-processing engineers owns a real-time audio transcription engine. Stream teams call a REST API — they do not need to understand FFT algorithms or acoustic models.
• Key point: This team type is the rarest and most commonly misused. Before creating one, ask: is this genuinely PhD-level complexity, or are we just avoiding the work of making it simpler? Most "complicated subsystem" teams are actually Platform teams in disguise.