Team Interaction Modeling with Team Topologies
Is your organization no longer delivering value as quickly as it used to? Maybe your teams are struggling with too much context switching, and their current workload no longer fits in their head. Are your teams being pulled in many directions? Are those teams disengaged with their daily work? Does it feel like your organization's communication channels are hindering value delivery? Do you feel the need to change how your teams are working together, but you are having difficulty in articulating how the organization should adapt and change?
If the answer to any of these is yes, then using the modeling techniques provided by Team Topologies will help you to identify, classify, and document the existing team structures and communication channels within your organization and provide clear, concise terminology to describe how to re-organize those teams and their interactions to achieve better flow and deliver value faster.
Team Topologies provides a combination of principles and practices that can help structure and evolve an organization for effective collaboration, autonomy, delivery focus, and product alignment. Using the Team Topologies shapes and diagramming principles, it is possible to create a series of snapshots of your organization at various points in time that help you understand why the teams within your organization communicate and interact.
Getting started
A key thing to remember about Team Topologies team modeling is that you should not look to create the perfect organizational design but instead look to use the modeling on an ‘as necessary’ basis to aid discussions about existing and future team interactions.
It is worth noting here, that the term ‘team’ has a very specific meaning in Team Topologies:
‘The team is the smallest entity of delivery within an organization and should be a stable group of 5 to 9 people working towards a shared goal as a unit.”’
It is also important that each team remains stable. If this is not the case the you should ensure that you have engendered a high-trust culture within the organization. Each team should generally be aligned to one or more areas/subsystems of the business domain.
There are several ways that you could approach the application of Team Topologies and we don’t want to prescribe exactly how you do this, however, we recognize that sometimes it is useful to have a guide. Therefore, the following is a suggested approach to applying the concepts.
Identify your current teams and map them to the fundamental team types
The first step is to understand how your organization is structured and what teams currently exist. Classify each of those according to some of the common industry team types such as infrastructure, component, tooling, architecture, or support teams and identify those teams you may want to avoid or change. You can capture this using the ‘undefined team type’ representation shown below, where ‘Comp X’ is ‘Competency X’:
Capturing existing team types using the ‘undefined team type’ shape
The next step is to consider how these existing teams might map onto one of the four Fundamental Team Types from Team Topologies: Stream-aligned, Enabling, Complicated Subsystem, and Platform teams. Team Topologies has very clear definitions of the expected behaviors that each of these team types should exhibit. When you are mapping your existing teams to the fundamental team types, you should bear this in mind to help classify them accordingly. If the teams do not currently meet the expected behaviors then leave them using the ‘undefined team type’ shape shown above.
Consider how your existing teams might map to the fundamental team types
The following table provides an overview of some of the expected characteristics and behaviors for each Fundamental Team Type:
Stream-aligned teams
Long-term design, build, and run for software-enriched services in a small, stable team of around 5-9 people
Enabling teams
Reduce intrinsic cognitive load and increase flow in Stream-aligned teams. A group of experts who mentor & facilitate to uplift capabilities and detect gaps. This team type should not own any software components
Complicated Subsystem teams
Reduce extraneous cognitive load and increase flow in Stream-aligned teams. A group of specialists dealing with complicated aspects ‘as a service’ - like a mini-platform
Platform group
Reduce extraneous cognitive load and increase flow in Stream-aligned teams by providing non-differentiating aspects ’as a service’.
You may find that none of your current teams map cleanly to one of the fundamental team types, which is fine. The key thing here is that we want to understand our ‘as-is’ team interaction because we can begin to decide how to evolve our organizational design.
Creating our first Team Interaction Model
Team Topologies suggest only three Team Interaction Modes are needed to represent how teams should interact. These are Collaboration, X-as-a-Service, and Facilitation.
Here is a brief explanation:
Collaboration
Teams work closely with other teams that have different skill sets for a defined period of time (usually a few weeks). This is typically used when a high degree of adaptability or discovery is needed.
X-as-a-Service (XaaS)
A natural interaction model after collaboration has discovered suitable boundaries. XaaS provides clear ownership of a service with a smaller cognitive load for teams consuming the service. This interaction mode must provide a good developer experience and the service being consumed should generally be managed as [part of] a product.
Facilitating
One team helps another. This is the main operating model for enabling teams. This mode is used to help clear impediments and discover gaps or inconsistencies in existing components and services used by other teams. There should be a focus on the quality of interaction between the teams. Like the Collaboration mode, Facilitating is a temporary interaction mode - the interaction should generally last for no more than a few weeks.
After our first attempt at mapping team types (which may have resulted in many undefined team types), we can start considering how work flows through those teams. Since, in this scenario, we do not have any teams that meet the Fundamental Team Type requirements, we should create an interaction diagram that represents our current state. This might look something like this:
An initial team interaction diagram that represents the handovers between teams
In the above diagram, we are using a gray diamond to represent a ‘handover’ between teams. So, for value to flow from left to right, work must pass through each team. This may be like PMO to UX to Dev to Test to Operations. We have a number of hand-overs between teams, which will be slowing our teams down and creating increased work-in-progress as each team picks up something else whilst waiting on the next team to complete their work.
One common scenario is when two teams ‘collaborate’ for a long period of time. This collaboration may take the form of one team needing to engage with another team whenever a new change is introduced into their value stream. Although many people interpret this as a Collaboration interaction, Team Topologies has a much stricter definition of Collaboration in so much as it should be short-lived and purposeful (as described above). Therefore, we can use an ‘undefined interaction mode’ shape on our initial Team Interaction Model to represent scenarios where two teams have a long-lived ‘collaboration dependency.’ This could look something like this:
Two teams that collaborate over a long period of time can be considered to have an ‘undefined interaction’ mode
Identify ‘as-is’ and ‘to-be’ team interaction modes
After considering how our existing teams map to the Fundamental Team Types, we can begin to reason how and why the teams are currently working together and determine whether this impedes flow in the scenarios we have defined above, with handovers between teams and ongoing collaboration between teams, this is almost certainly the case. So, we need to start thinking about how to evolve from our ‘as-is’ to our ‘to-be’ state.
Defining our first team evolution
We need to consider how we can reduce the number of handovers by thinking about what capabilities we would need from each of the existing teams to form a Stream-aligned team composed of 5-9 people that could be responsible for the end-to-end delivery of value to an end customer.
Consider which capabilities from each team you would need to deliver end-to-end value without handovers between teams.
After some discussion around how a future Stream-aligned team might look, we can create our first ‘as-is’ to ‘to-be’ evolution, which may look something like this:
An ‘as-is’ to ‘to-be’ interaction diagram demonstrating an evolutionary step
As we can see above, the diagram describes that, with the help of an enabling team, we need Teams A, B, C, and D to collaborate for a defined period of time to form an initial Stream-aligned team, which includes the core capabilities required to deliver end-to-end value to the customer for a given value stream.
Limiting the cognitive load of each team
After our initial assumptions about how our stream-aligned team should look, we may find that the team is not quite producing the fast flow of change that we were expecting. Upon closer inspection, we may find that the team is struggling to cope with a specific capability, causing them to slow down.
It is possible to represent the relative cognitive load of each team using the team shapes - the larger the shape, the more cognitive load that team has to handle. In the diagrams below, I have added some ‘brain emojis’ to represent cognitive load and help visualize it in this article. However, this is not an essential part of Team Interaction Modeling.
The Stream-aligned team has increased cognitive load around capability B which is causing them to be slower
This might raise a number of questions, including:
Is the team's current size big enough for the amount of work it needs to deliver?
Does the team need support to simplify its intrinsic cognitive load?
Does the team need support to reduce its extraneous cognitive load?
Is the team having to work on a complicated subsystem that means it is too big for the team to handle?
Depending on the outcome of our investigations into the needs of our Stream-aligned team, we may find that they need help with their extraneous or intrinsic cognitive load.
Reducing cognitive load through a Platform service
In this scenario, it might make sense to introduce a Platform team to help provide the capability as a service, thereby abstracting away some of the complexities and providing a simpler service:
Reducing extraneous cognitive load of the team through a platform service
Reducing cognitive load through a complicated subsystem service
An alternative scenario is that the work being undertaken by the Stream-aligned team actually includes some fairly complicated processes around data science or machine learning and we could create a separate team entirely.
Reducing extraneous cognitive load of the team through a complicated subsystem team
Reducing cognitive load with an Enabling team
Another alternative might be that the stream-aligned team does not have the intrinsic knowledge within the team to deliver end-to-end value to the customer easily. Therefore, they may need support from a specialist Enabling team to help upskill the team on the missing capability.
An Enabling team helps to upskill the Stream-aligned team on the missing capability to reduce cognitive load
Reduce cognitive load by breaking apart a monolith
Consider whether you have any monoliths that are making it hard to identify smaller, more focused Stream-aligned teams. If you do, try to identify natural fracture planes that might help to break them apart and reduce any coupling and dependencies between teams. See pages 115-123 of the Team Topologies book for details on possible fracture planes.
If it looks like some teams may have too much cognitive load but it isn’t possible to increase the team size without exceeding the recommended limits (based upon Dunbar’s number and trust boundaries), you should look to reduce the cognitive load on Stream-aligned teams by making use of the other team types such as Platform, Enabling, and Complicated Subsystem teams. Look at areas of responsibility currently owned by one or more Stream-aligned teams. Could they be owned and offered as a service by an independent Platform team?
Explicitly guide (and limit) inter-team collaboration
Using Fundamental Team Types and core Interaction Modes, it is possible to model further interactions between teams. As you can see in the diagram below, we have captured a snapshot of the current interaction modes between the teams.
When creating Team Interaction Models, it is important to note that you should always include a ‘flow of change’ arrow indicating an expectation of flow from left to right. If two teams are in the same place on a y-axis, we would expect there to be some form of handover between the teams:
A sample Team Interaction Model with multiple teams
From the above diagram, it is clear that Stream A is collaborating with the Complicated Subsystem team. We should expect that this is a short-term collaboration to define and develop a future X-as-a-Service interaction, allowing Stream A to deliver value faster.
We can also see that the Complicated Subsystem, Stream B, and Stream C consume services from Steam D, a Stream-aligned team that is part of Platform A. However, we can also see that Stream C is collaborating with Stream D, potentially to develop another platform service that Stream C could consume.
In this case, Stream A is also receiving some facilitation from Enabling team A, which may be some help with the CI/CD pipeline or automation test suite (for example), depending on the skill set of the Enabling team.
After capturing the above snapshot of the existing team interaction modes, it is important that we monitor the interactions between teams and try to guide the inter-team collaboration to ensure that it does not occur over prolonged periods unless that is desired. Although collaboration is good for discovery, it can also be expensive. It is, therefore, important that any frequent or prolonged periods of collaboration are performed to explore (and possibly create) an X-as-a-Service interaction model between the two teams for future interactions.
In the following future diagram, we can see that the team interactions have evolved.
A snapshot of the organization showing how the team interactions have evolved
The collaboration interactions have been replaced with X-as-a-Service interactions, which should reduce cognitive load for both Stream A and Stream C. As a result, we should expect to see an improvement in the throughput metrics of both Stream-aligned teams. We can also see that Platform C has now produced a new X-as-a-Service used by Stream A and Stream C but not by Stream B (denoted by the missing asterisk). This could be because Stream B has decided not to consume the service because it is not yet fit for purpose. We can also see that Enabling team A has moved from facilitating Stream A onto Stream B.
Evolve team structures over time
As time goes by, new technology is adopted and ways of working are improved. Therefore, it is only natural that the team structures must also be adapted and changed. There are a number of reasons why Team Topologies will need to evolve. Some of the triggers may include but are not limited to software being too large for one team, delivery cadence becoming slower, or multiple business services relying on a large set of underlying services. You need to be mindful of the occurrence of these scenarios and act accordingly by re-evaluating whether the current team interaction design is fit for purpose or needs to evolve.
Use team interactions for organizational sensing
With well-defined, stable teams taking effective ownership of different parts of the software systems and interacting using well-defined communication patterns, organizations can begin to activate a powerful strategic capability: organizational sensing. The kinds of things you may consider ‘sensing’ are:
Have we misunderstood how users need/want to behave?
Do we need to change team interaction modes to enhance how the organization is working?
Should we still be building thing X in-house? Should we be renting it from an external provider?
Is the collaboration between Team A and Team B still effective? Should we move towards an X-as-a-Service model?
Is the flow of work for Team C as smooth as it could be? What hampers flow?
Does the platform for teams D, E, F, and G provide everything those teams need? Is an Enabling team needed for a period of time?
Rules and principles
When using the team shapes to create your own diagrams, there are a number of constraints that should be applied:
There is always an implied flow of change from left to right in the diagram (with apologies to people more familiar with a right-to-left flow!).
A key aspect of Stream-aligned teams is that they have end-to-end responsibility for a flow of change to the live services/systems, with no hand-offs to other teams. There should therefore be no other team between a Stream-aligned team and their customers/users (on the right of the diagram).
Team shapes should be solid to represent their long-lived nature.
Interaction Mode shapes should be 50% transparent to represent the interaction's short-lived nature.
Stream-aligned teams should generally never provide an X-as-a-Service directly. Instead, data or services from the Stream-aligned team should be made available ‘as a Service’ via a platform.
If an X-as-a-Service or Collaboration interaction crosses over multiple teams, it may be appropriate to use a black asterisk, ’*’, to clarify which teams are interacting.
Remember these guidelines:
Use diagrams as a starting point for meaningful discussion. They are visuals to drive conversations around needs and evolution.
Any diagrams you create will be a ‘snapshot’ of your current landscape. Use them to visualize and present potential issues that may need to be addressed.
For more information, see shapes.teamtopologies.com, and if you would like to learn more about using Team Interaction Modelling within your organization, look at our foundation workshop: P829 - Organization Evolution using Team Interaction Modeling.