📖 Business
Three Interaction Modes
Just as there are exactly four team types, Skelton and Pais define exactly three ways teams should interact. Not "however feels natural" — three deliberate, named modes with clear rules about when to use each one. The constraint is the point: if a team interaction doesn't fit one of these three modes, something is wrong with the team boundaries. Undefined interaction — teams bumping into each other ad hoc — is the primary source of organizational friction, unclear ownership, and delivery bottlenecks.
2
Minutes
2
Concepts
+45
XP
1
How It Works
The three interaction modes:
- Collaboration — Two teams work closely together on a shared goal, with blurred boundaries and high-bandwidth communication. Think pair programming across teams, shared Slack channels, joint standups, co-owned code. This mode is expensive: it requires high trust, aligned priorities, and significant coordination overhead. Use it for discovery and innovation — when neither team knows the answer yet and you need to explore together. Critical rule: collaboration should be temporary. If two teams are permanently collaborating, they should either merge into one team or redraw boundaries so they can interact via X-as-a-Service instead.
- X-as-a-Service — One team provides a capability that another team consumes through a well-defined interface: an API, a CLI tool, documentation, a self-service portal. Low friction, clear ownership, minimal coordination needed. The provider team owns the service; the consumer team uses it without needing to understand the internals. This is the goal state for most interactions. It scales, it's sustainable, and it preserves team autonomy.
- Facilitation — One team (usually an enabling team) helps another team learn or adopt something new. The help flows in one direction — the facilitating team has expertise the other team needs. The engagement is time-boxed: teach them to fish, then move on. Facilitation should result in the receiving team being self-sufficient. If the facilitation never ends, it has become a dependency, not an enablement.
Anti-patterns to watch for:
- Undefined interaction — Teams bumping into each other with no agreed mode. Causes confusion, duplicated work, and finger-pointing.
- Permanent collaboration — Two teams always working together blurs ownership and creates a distributed monolith of people.
- Facilitation that becomes dependency — The enabling team never leaves, becoming a permanent crutch rather than a temporary boost.
- X-as-a-Service with no self-service — If consumers have to file tickets and wait, it's not really X-as-a-Service. It's a queue.