Three Patterns for Team Interaction in Team Topologies

I’m still learning how to use these patterns effectively, but I know there’s something essential to the patterns of usage:

Collaboration works for discovering new interfaces and solving ambiguous problems. But it’s high-bandwidth, high-cost, and shouldn’t be the default mode.

X-as-a-Service provides clear boundaries with minimal coordination overhead. One team consumes what another produces through well-defined interfaces. This is where most team relationships should live.

Facilitating involves temporary knowledge transfer, typically from enabling teams to help others become more capable. It’s coaching, not ownership.

The counterintuitive insight: “increased collaboration is not always the same as increased communication.” More talking doesn’t equal better outcomes.

“Fast flow requires restricting communication between teams. Team collaboration is important for gray areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead.”

Sometimes the best team relationship is intentionally limited communication. Deploying independently with short lead times means teams are similarly decoupled. That gets tricky the more we get into common services.

The mental model shift: think of team interactions as consciously designed APIs, not emergent social patterns.

Inspired by Team Topologies