Defining team types is not enough. The same two teams can interact in ways that either accelerate or destroy flow. Team Topologies defines exactly three valid interaction modes. Using the wrong mode for the situation is one of the most common causes of organizational dysfunction.
1. Collaboration
- Definition: Two teams work closely together, often with shared code ownership and daily communication, for a defined, time-boxed period to discover or build something neither could do alone.
- Pros: High innovation, rapid discovery, shared context.
- Cons: High cognitive load (two teams' worth of concerns merge), expensive in meeting time, does not scale.
- Use Case: A Stream team and a Platform team working together for two weeks to design the first version of a deployment abstraction. Neither team knows exactly what the right API should look like yet — collaboration is how they find out.
- Warning: Collaboration that never ends is not collaboration — it is a merged team with unclear ownership. Set an explicit end date and a transition plan.
2. X-as-a-Service
- Definition: One team consumes a capability provided by another team via a well-defined interface (API, CLI, documentation) with minimal direct communication required.
- Pros: Very low cognitive load for the consumer, high scalability for the provider, fast delivery.
- Cons: Innovation is constrained to what the service already offers; feedback loops are slower.
- Use Case: After the collaboration phase above, the Platform team publishes the deployment CLI. Stream teams now deploy without talking to the Platform team at all. The Platform team can serve dozens of stream teams simultaneously.
- The goal: Most steady-state interactions between Platform teams and Stream teams should be X-as-a-Service. Collaboration is for building; X-as-a-Service is for operating at scale.
3. Facilitating
- Definition: One team (usually an Enabling team) helps another team clear an obstacle, learn a skill, or adopt a new practice. The facilitating team does not do the work — they coach.
- Pros: Spreads capability, unblocks teams, reduces long-term dependency.
- Cons: Requires the facilitating team to be genuinely expert and genuinely willing to hand off.
- Use Case: An Enabling team (Observability specialists) embeds with a Stream team for three weeks to help them instrument their service with OpenTelemetry. By the end, the stream team can do it themselves.
Interaction Mode Anti-Patterns
| Anti-Pattern | What It Looks Like | Correct Mode |
|---|---|---|
| Permanent Collaboration | Two teams always in the same meetings, unclear who owns what | Time-box collaboration, then transition to X-as-a-Service |
| Enabling as Doing | Security team writes all the security code for every team | Facilitating — teach, don't do |
| Platform as Gatekeeper | Platform team must approve every deployment via ticket | X-as-a-Service — self-service with guardrails |
| Complicated Subsystem as Bottleneck | Every team waits on the "data science team" for any ML feature | Clean API contract, async communication |