Team Topologies is an increasingly popular topic in organisations looking to improve delivery speed. It is fascinating; It has that perfect combination of ideas to hook me, both practically in my daily life and well backed up by scientific research I can dive into.
When I find something interesting, I write. I love to get more people excited about things I am excited about. However, when writing this article, I struggled to articulate the experiences of those who are coming to these ideas for the first time.
So I did what any AK-er would do in this situation: I reached out to someone with a different perspective. Victoria has been helping a bunch of organisations get their first taste of Team Topologies, she bridges that gap between being an expert and knowing what her attendees experience, so can replay their experiences of coming to Team Topologies for the first time.
In this article, I want to report her experiences and what attendees of her workshops are telling her. I want to use them to tackle those first problems you experience as you dip your toes into the Team Topologies world.
#So why are people turning to Team Topologies?
According to Victoria, what she hears most often from people attending her workshops is that people turn to Team Topologies because organisations are struggling to get teams to deliver.
"Organisations are created for a reason," Victoria says "they have a mission, and they bring in the best people they possibly can to help them to deliver on that mission". However, as time passes, something is lost, and people, the team, "the powerhouse of delivering on that mission", become hampered by layers of bureaucracy that made sense in previous iterations of the organisation but are just causing teams to split their focus now.
This problem has many names: the frozen middle, the build trap, a lack of agility, a lack of DevOps or a lack of Domain Driven Design (DDD) practices. What can be frustrating with this is that we have been finding solutions to these problems for years, and we have a lot of tools to help, but very few that work beyond just one team (without excessive bullshit, I am looking at you SAFe and Scrum).
Organisations need the help of Team Topologies to help them solve this problem, as Victoria puts it, "the key thing about Team Topologies for me is unravelling that knot and refocusing organisations on the importance of setting up the teams for success".
What are the core components?
Team Topologies brings together a lot of thinking from the Agile and DDD Communities. In particular, it combines the ideas of a Team Topology (or type), Cognitive Load Theory as applied to teams, and Conway's Law into one usable and, perhaps more importantly, explainable package.
If you are familiar with these communities, much of it will already be familiar. However, for those who are not, I'll quickly introduce them.
Conway's law is probably the easiest of these to grasp. In 1967 Conway said, "Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure." My favourite rephrasing of this is by Eric S Raymonds, who wrote The Cathedral and the Bazaar. Eric said, "If you have four groups working on a compiler, you'll get a 4-pass compiler.".
Conway's law is a foundation of Team Topologies and is useful to remind us that how organisations design their teams impacts their output, so let's use that to our advantage.
Exploring Team Topologies
But I thought this was called Team Topologies, so what are these topologies? There are 5 (or 3, depending on how you look at it). Let's go over the primary 3:
- Stream Aligned Teams -These teams align themselves with the flow of work or their value stream. They take ownership of the process from conception to delivery to their users.
- Enabling Teams, These are teams that work with other teams, with one important feature: they facilitate capability uplift rather than doing the work for them, and their engagement with the other team has an end date that is soon.
- Complicated Subsystem Teams, These teams work with another team but are a specialised group of experts to simplify a complicated problem, reducing the cognitive load of a Stream Aligned Team. Usually chock full of brilliant domain experts.
Two additional team structures
And the two that are not quite direct team structures
- Undefined topology, An absence of any defined topology, not a desirable state in Team Topologies, but most people's starting point.
- Platform Group, This grouping of other team types allows the topologies to be fractal, something we commonly see in resilient structures in nature. This topology is a grouping of teams that delivers a service accessed in a non-blocking way to accelerate the flow of other teams. For example, a database provisioning team. The critical thing to know is that these teams should be able to be competitive with what public services can offer, that means being customer centric, and understanding the users needs. Think of it as a box that a group of other teams fit in.
Effective communication styles
These come with some defined effective communication styles.
- Facilitation: almost exclusively provided by Enabling Teams, a time delimited interaction that uplifts the capability of another team.
- X-as-a-Service: most frequently provided by Platform Groups or Complicated Subsystem Teams and consumed by Stream Aligned Teams, the provision of a service in a non-blocking way.
- Collaboration: most frequently between two Stream Aligned Teams, or between a Complicated Subsystem Team/Platform Group and a Stream Aligned team at the inception of an X-as-a-Service, collaboration is costly, so it should be time delimited with defined outcomes.
These patterns allow the limiting of team cognitive load by limiting handoffs, but also to let teams say, "Talk to us like this, so you don't disrupt us".
Understanding Team Cognitive Load
Team Cognitive Load is also a fascinating idea; it builds on the work by Australian Psychologist John Sweller, but instead of applying it to the individual, we use it for the team.
Cognitive load theory as applied to individuals works like this, when a person is solving a problem their brain is under differing sorts of pressures. These types of load are Intrinsic, Germaine, and Extraneous.
Think back to the first time you did algebra. Was it hard? The existence of mental models that let you solve problems fast, and reduces effort needed to solve a problem. This is called the "Intrinsic" cognitive load.
Ever tried to focus while in a noisy office? Pressures from the environment are called "Extraneous" cognitive load.
Finally there is how hard this particular instance of a problem is to solve. This is the "Germane" cognitive load. For example adding 3+3 is easier than 7543565+654334, but it uses the same skills.
Applying Cognitive Load to teams
- We want to "
Simplifythe intrinsic". This isn't about solving less hard problems, it's about building those mental models in our team members that make the intrinsic load in individuals lower, so that might be solving a problem more often, adding an expert to the team, or doing some training. - We want to minimise the extraneous by removing environmental noise for the team (such as bureaucracy),
- Finally we want to maximise the work which is germane to the problem.
Put all these concepts together, and you have Team Topologies, a set of patterns you can apply to your organisation.
But trying this out isn't all smooth sailing
When first introduced to these ideas, it's tempting to take whatever your team currently does and label it with one of these names.
Victoria told me about the confusion from attendees at her workshops, a common question is, "So how do we fit into this model that you're trying to teach us?".
An essential thing to say here is that a team won't just magically fit into these topologies, you need to evolve it intentionally. As Victoria puts it "When we're asking a team to define themselves as a platform group or a stream aligned team or an enabling team, frequently the answer is, 'but we do a bit of all of that'…it makes a lot of sense to us, but we can't put our square peg into this round hole."
To solve this, Victoria's advice is, "Take some of those core concepts and make small changes. Proving their value at a small scale is a good place to start, and then start rolling it out."
Some practical resources
This article aims to answer some of the questions that commonly come up when talking about Team Topologies based on Victoria's and her attendee's experiences, making it a bit easier to get started with the topic.
If you (like me) find this fascinating and would like to know more, I recommend the following:
I would love to hear from you about your experiences, you can get in touch via the Team Topologies page on the Armakuni site, or just drop me a message on LinkedIn. I love feedback, and learning about the perspectives of people with the same passions as me."
