Use standard interactions between teams
Team Topologies proposes using standardized patterns of interacting between teams. In particular, it suggests that that there are 3 patterns that are sufficient to describe the interactions between most teams:
- Collaboration: two teams work closely together for a defined period to discover new patterns, approaches, and limitations. Responsibility is shared and boundaries blurred, but problems are solved rapidly and the organization learns quickly.
- X-as-a-Service: one team consumes something (such as a service or an API) provided “as a service” from another team. Responsibilities are clearly delineated and–if the boundary is effective–the consuming team can deliver rapidly. The team providing the service seeks to make their service as easy to consume as possible.
- Facilitating: one team helps another team to learn or adopt new approaches for a defined period of time. The team providing the facilitation aims to make the other team self-sufficient as soon as possible, while the team receiving the facilitation has an open-minded attitude to learning. (Skelton and Pais 2019, chap. 7)
Whenever two teams interact, they should pick one of these modes to be operating under but be willing to change their approach when conditions change.
Collaboration
The collaboration team mode is suitable where a high degree of adaptability or discovery is needed, particularly when exploring new technologies or techniques … because it avoids costly hand-offs between teams. (Skelton and Pais 2019, chap. 7)
When collaborating, it is common for the two teams to fully merge into one At a former company of mine, we would call this merged team a “virtual team” or a “vteam.”
:
The two teams must take on joint responsibility for the overall outcomes of their collaboration, because the act of collaborating creates a blurring of responsibility boundaries. (Skelton and Pais 2019, chap. 7)
Note that this interaction is almost always ephemeral:
A need for ongoing collaboration suggests incorrect domain boundaries and/or team responsibilities, or the incorrect mix of skills within a team. (Skelton and Pais 2019, chap. 7)
X-as-a-Service
[The X-as-a-Service model works best] during later phases of systems development and periods where predictable delivery is needed (rather than discovery of new approaches). … [This approach] results in the delivery team having to understand less about non-core aspects of their work, allowing them to deliver more quickly. (Skelton and Pais 2019, chap. 7)
Note that this means there is less innovation in this space:
By design, innovation across the boundary happens more slowly than with collaboration, precisely because X-as-a-Service has a nice, clean API that has defined the service well. (Skelton and Pais 2019, chap. 7)
Also note that the goal of the providing team is to reduce cognitive load on the consuming team, so providing team must take careful responsibility for the whole product As I read this section, I was reminded of the whole product metaphor from Crossing the Chasm
they are building: usability/experience, documentation/training, and the careful evolution of features to serve the interests of all consuming teams.
As a result, it is common to start with a Collaboration model to discover the correct service boundaries before moving into a X-as-a-Service pattern. Alternatively, it is common to temporarily adopt a Collaboration model when a team has been X-as-a-Service for a while to help team members refresh their empathy with other teams.
Facilitating
The remit of the team undertaking the facilitation is to enable the other team(s) to be more effective, learn more quickly, understand a new technology better, and discover and remove common problems or impediments across the teams. (Skelton and Pais 2019, chap. 7)
In particular, a facilitating team tends to focus on the quality of interactions between other teams.
For example, a team facilitating the effectiveness of three stream-aligned teams (see Chapter 5) might find that the logging service provided by the platform is quite difficult to configure: all three teams find it difficult to use. The team helping the three teams can then facilitate some improvements to the logging service from the platform. (Skelton and Pais 2019, chap. 7)