What is the Team Interaction Modes pattern?
Teams interact in three main ways. In collaboration, two teams work closely for a limited time to discover something new, such as a new API between them. In 'X as a service', one team consumes what another provides through a clear interface with little contact. In facilitation, one team coaches another. Naming the current mode for each pair of teams makes expectations clear.
What problem does the Team Interaction Modes pattern solve?
When teams never decide how they work together, everything becomes collaboration: meetings, shared backlogs and constant coordination, which is expensive and slow. Or the opposite happens, and a team is left alone with a platform it cannot use. Choosing the mode on purpose keeps collaboration for when it pays off and makes the rest self-service.
How do you implement the Team Interaction Modes pattern?
- For each team, list the teams it depends on and the mode of each relationship.
- Use collaboration for a limited time when the boundary is still being discovered, then move to 'as a service'.
- Expect platform and complicated-subsystem teams to be consumed as a service most of the time.
- Use facilitation when an enabling team is helping a product team build a skill.
- Treat a relationship that needs constant collaboration as a sign the team boundaries are wrong.
When should you use it?
- Teams spend much of their time in coordination meetings with each other.
- A platform or specialist team is unsure whether it should build for others or with them.
When should you avoid it?
- There are only two or three teams who already work well together. A shared understanding is enough.
What do you gain?
- Clear expectations between teams
- Less unplanned coordination
- Problems in team boundaries become visible
What does it cost?
- Needs regular review as teams evolve
- Labels can be applied without changing behaviour
- Adds vocabulary to learn
What are common mistakes with the Team Interaction Modes pattern?
- Permanent collaboration between two teams, which usually means they should be one team or have a different boundary.
- A platform consumed 'as a service' with no documentation, so it is really tickets in disguise.
- Changing modes without telling the other team.
Team Interaction Modes in practice
Northwind Rail
The ticketing and payments teams had worked in permanent collaboration for two years, with joint stand-ups and a shared backlog. Neither could release without the other.
The teams agreed a final three-month collaboration to design a clean payments API, then switched to consuming it as a service. They now meet once a quarter, and each releases on its own schedule.
Further reading: Team Topologies key concepts
Example decision record
- Context
- Two teams have worked in open-ended collaboration for years and cannot release independently.
- Decision
- Name the interaction mode for each team pair, keep collaboration time-boxed, and move to consuming each other as a service.
- Consequences
- Coordination drops and expectations are clear.
- Interfaces between teams need to be good enough to use without meetings.
Test yourself on Team Interaction Modes
An enabling team for performance has been 'helping' the same product team for 18 months. It now writes most of that team's caching code. What has happened?
4 questions involve this pattern. Practice all of them →
Saved in this browser only. See your progress →