📖 Business
Four Fundamental Team Types
Skelton and Pais argue that every team in a software organization should fit one of exactly four types. Not five, not ten — four. This constraint is deliberate: it forces clarity about what each team exists to do and eliminates the ambiguous "component teams," "shared services teams," and "tiger teams" that create confusion and slow delivery. The four types form a complete system where one type delivers value directly and the other three exist solely to support it.
2
Minutes
2
Concepts
+45
XP
1
How It Works
The four fundamental team types:
- Stream-aligned — The primary type. Owns end-to-end delivery for a single stream of work aligned to a business domain, product, or user journey. Responsible for the full lifecycle: design, development, testing, deployment, and production monitoring. Most teams in the organization should be stream-aligned. If you're unsure what type a team should be, default to this one.
- Platform — Provides self-service internal capabilities that reduce cognitive load on stream-aligned teams. Think CI/CD pipelines, infrastructure provisioning, observability tooling, data pipelines, and internal developer portals. The critical success metric: can a stream-aligned team consume your platform without needing to file a ticket or schedule a meeting? If they have to talk to you to use your service, you're not a platform team yet — you're a bottleneck.
- Enabling — Helps stream-aligned teams acquire new capabilities they don't yet have. Might help teams adopt Kubernetes, improve testing practices, or migrate to a new framework. The engagement is explicitly temporary — uplift the team's skills, then move on to the next team that needs help. If an enabling team is permanently embedded with the same stream-aligned team, something is wrong.
- Complicated-subsystem — Owns a technically complex area that requires deep specialist knowledge: machine learning models, video codec optimization, financial risk calculation engines, real-time physics simulations. This type exists because the cognitive load of that subsystem would overwhelm a stream-aligned team. Keep these teams small and focused.
The fundamental rule: all three supporting types (platform, enabling, complicated-subsystem) exist only to help stream-aligned teams deliver faster. If a supporting team can't explain how it accelerates stream-aligned delivery, it shouldn't exist.