On 26th of September 2019 I had an opportunity to attend Team Topologies Fundamentals training in Leeds - the session was delivered by Matthew Skelton. Together with Manuel Pais he wrote a book called Team Topologies that discusses how to "build the best team organization for your specific goals, culture, and needs".
The training was organised into 4 sections:
- Teams and Conway’s Law
- Fundamental Toplogies
- Team Interaction Patterns
- Evolving Team Topologies
Both the book and content of the training are based on 5 years of research across 30+ organisation in multiple industries and various countries / cultures. The authors focused on distilling underlying principles, patterns and topologies. This allowed them to focus on the essence of team design, rather than on more specific challenges related to a particular industry.
Matthew Skeleton delivering the Team Topologies training
Teams and Conway’s Law
The first part of the training started with a discussion on what are the benefits of Spotify Model and how should not be blindly followed - it was a snapshot of what worked for the company at the time of publishing. Instead of copycatting approaches other people follow we should understand principles and make sure that we are addressing the underlying causes for problems, rather than visible symptoms.
With that in mind we’ve agreed on what we mean by a team in the context of the training:
- A group of 5-9 people - as per Dunbar’s number
- Stable and long-lived - so that they went through team formation phases and can work efficiently
- Colocated - either physically, or in a virtual space
Now that we knew what the team is, we've started looking at the answer to the question what the team is able to deliver Unfortunately is not just the answer to a question on how to slice and dice the software itself (microservices vs monoliths, service and domain boundaries). It’s also important to determine what is the cognitive capacity and load of the team. That will vary based on the team size, experience, rate of change and number of services the team is responsible for.
We have then looked at 3 types of cognitive load: intrinsic, extraneous and germane. As discussed during the training we want to minimise intrinsic one and ideally have no extraneous cognititive load. If we do that the spare capacity can be taken by the germane load which is the one related to addding value to the business.
Another factor contributing to the team performance is number of communication paths it has to handle, and the bandwidth of each path. This led us to the discussion about impact of the Conway’s and how to exploit it to improve the design of the software by changing how teams delivering it are shaped (aka Reverse Conway Maneuver).
Fundamental Topologies
The second module of the training introduced us to four topologies, that Manuel and Matthew identified as part of their research.
Stream-Aligned Teams
A stream-aligned team is a primary type of team that delivers value within organisation. It should be aligned to a single stream of work, and should be able to deliver that work independently and without unnecessary handoffs. This kind of team is responsible for the end-to-end delivery, monitoring and incorporating feedback of the customers. All other types of teams exists so that stream-aligned teams can focus on delivering their goals.
Enabling Teams
One of the reasons why a stream-aligned team might be underpeforming is a capability gap. The reason why enabling teams exist is to close this gap and bring missing skills and technical expertise to teams that need it. The enabling team has a clear mission and an expiry date, so when its job is done (i.e. teams are trained on how to use continuous integration) the team is likely to be repurposed (new mission).
Complicated-Subsystems Teams
Complicated-subsystem team is also created with a specific goal in mind. It is responsible for building a part of the system that requires very specific skills. The goal is to reduce the cognitive load of members of a stream-aligned team. Such team should be created when it's not feasible to expect team members to have a very specialist knowledge in some areas. The deliverables produced by the complicated-subsystem teams can be then consumed or used by stream-aligned teams.
Platform Teams
The last type of team - a platform team - enables stream-aligned teams to deliver the work. As such the goal of platform team is to reduce congnitive load related to running and maintaining the software within the organisation. They can achieve this by creating an easy to use, self-service, well-scoped and supported platform. The platform really should be seen as an internal product other teams are leveraging, but it can be challenging to find a balance between quality, completness and feature-requests coming from teams using the platform.
Designing topologies of the teams during the training. Picture: Nick Tune
Team Interaction Patterns
Equipped with the knowledge on different types of teams we were able to move to the next module of the course. The interaction patterns helped us understand the dynamics of relationships between teams, and also set expectations on how the communcation should look like.
Collaboration mode can be benefitial where high communication bandwith between teams is required. It can be because there is a need to reduce number of hand-offs between these teams so that they can innovate and iterate quickly. On the downside collaboration can cause higher cognitive load, which overall can lead to reduced outcomes.
X-as-a-Service works in a situation where a team needs predictable service delivered by another team. The responsibilities and expectactions are usually clearly defined, but at a cost of innovation - clients usually have to stick to what is avalilable.
Facilitation mode is well suited for enabling teams that support other stream-aligned teams. The goal is to unblock the latter and make sure they are successfull, but not by doing the work for them. Instead as the name suggest the team should facilitate the learning and make sure the capability gap is closed.
It's worth adding that Team Topologies comes with a notation used to represent teams and their relationships. Each team type is represented by a different colour, and each relationship has a diferent symbol associated to it. I think that once understood this notation works quite well, but at the beggining I didn't get that the flow is represented from left to right and also the direction of X-as-a-service dependency is not represented.
Evolving Team Topologies
Knowing both types of topologies and interaction patterns we were able to practice the team design. That was done using several examples and we had a chance to analyse multiple cases from real companies. We had quite a lot of discsussion about various heuristics that people used, as well as signals that we should look for.
We've agreed that the specific strategy will depenend the context and current goals of a part of the organisation. It would be naive to expect that we can simply apply a single strategy to the whole company and expect it to work well.
Summary
The training delivered by Matthew in a neat way teaches the foundations of team design and challenges this process poses. From my point of view, the ideas presented in Team Topologies can become a foundation for modern organisation design. I'm sure there is a lot of work ahead of us, and I still need to practice the techniques myself to decide how I'm going to use them with my clients and in future organisations.
That said, I conclude that going to this training was a money (and a day) well spent. Either reading the book or going to the training is something that I recommend for people that are empowered to design teams in technology organisations.