Why Interaction Modes Matter
Defining team types is necessary but not sufficient. Two teams can be correctly typed but still create enormous friction if they interact in the wrong way. Team Topologies defines three interaction modes that specify how teams should work together — and critically, when each mode is appropriate.
Getting interaction modes wrong is one of the most common failure patterns in platform organizations. A Platform team that defaults to "Collaboration" for everything will find itself in endless meetings. A team that never Collaborates will build the wrong thing.
Mode 1: X-as-a-Service (The Goal State)
One team provides a capability as a service — via an API, a CLI tool, a self-service portal, or a Terraform module — with excellent documentation. The consuming team uses it without needing to talk to the providing team.
- When to use: When the interface is stable and well-understood. This is the target state for Platform and Complicated Subsystem teams.
- Cognitive load impact: Very low for the consuming team. They treat the service as a black box.
- Signal that it's working: Stream-aligned teams can provision resources and deploy code without filing tickets or attending meetings.
Example: A Platform team provides a Terraform module for a standard PostgreSQL database. A Stream-aligned team runs terraform apply and gets a database in 10 minutes. No conversation needed.
Mode 2: Collaboration (Temporary and Purposeful)
Two teams work closely together for a defined period to solve a specific problem — typically to discover the right API boundary, explore a new technology, or solve a cross-cutting architectural problem.
- When to use: When the problem is novel and the solution is unclear. Use it to discover the right X-as-a-Service interface.
- Cognitive load impact: High. Both teams must context-switch into each other's domain. This is expensive.
- Critical constraint: Collaboration must be time-boxed. If two teams are collaborating indefinitely, it means the interface between them has not been properly defined. That is a design failure.
Example: A Platform team and the Payments team collaborate for four weeks to design the right abstraction for database provisioning. At the end, the Platform team builds the Terraform module and the interaction shifts to X-as-a-Service.
Mode 3: Facilitating (Teaching and Uplifting)
One team helps another team learn a skill or adopt a practice. The Enabling team is the primary user of this mode.
- When to use: When a Stream-aligned team lacks a capability they need to be autonomous.
- Cognitive load impact: Medium. Requires active engagement but builds lasting capability.
- Signal that it's working: After the facilitation period, the Stream-aligned team no longer needs the Enabling team for that capability.
Interviewers sometimes ask: "How do you know when a team is collaborating too much?" The answer is that indefinite Collaboration is a signal of an undefined or poorly designed interface. In Team Topologies terms, Collaboration should always be a temporary mode used to discover the right X-as-a-Service boundary. If two teams have been collaborating for six months with no end in sight, the real problem is that nobody has made a decision about where the API boundary should be.