Q: What is a topologist? A: Someone who can’t tell the difference between a doughnut and a coffee cup.
I studied maths at university but don’t worry if you don’t get the joke (it’s a bit niche! - this might help Mug & Donut), this article won’t be discussing the finer points of Topology from a mathematical perspective. All I’ll explain at this point is that Topology is about the properties of spaces and shapes - and how you can deform them and come up with something that may “look” different, but is essentially the same thing. So it forces you to think carefully about what makes one shape truly different from another.
In the book Team Topologies, we’re concerned with the shapes of teams and the way they interact with each other. We look at how these shapes and interactions can be categorised, and how you can pick the right ones for your organisation.
My recommendation of this book comes with a warning. I definitely did enjoy reading it, learned a lot and was inspired to reflect on teams as a result of it - but equally, it’s definitely written for an audience familiar with modern software development environments. The case studies are large technology businesses and there’s a lot of terminology that will bamboozle you if you don’t have the right background knowledge. I wouldn’t suggest reading it yourself unless you have a good awareness of how software companies work or someone close by you can constantly nag with questions.
Having said all that, the concepts discussed in the book are very much applicable to other working environments and teams - I’m planning to write a longer article to explore this further, using examples from functions that appear in most businesses. So, perhaps consider reading my future article, rather than the Team Topologies book itself, as when I write I won’t be assuming any specialist knowledge.
The fundamentals
The starting point for the authors’ thinking is something called Conway’s Law. It suggests that the nature of whatever a group of teams design and develop flows from how those teams are organised and how they interact. Solutions are influenced and constrained by how the teams who develop them operate.
They suggest that we should consciously design what teams we have in an organisation, who’s in them, what each one's remit is , and how they interact with each other. And we should be prepared to evolve this over time. We need to be architects - designing teams and interactions to maximise potential productivity and align with what we want the outcomes to look like.
“It’s easy to understand that any one person has a limit on how much information they can hold in their brains at any given moment. The same happens for any one team by simply adding up all the team members’ cognitive capacities.”
Cognitive Load* is a key concept throughout the book. Each individual and team has a level of cognitive capacity, but we often don’t think this through when we assign responsibilities to a role or team. This can result in individuals or teams lacking the bandwidth to cope with the scope. They also then struggle with the time and attention costs of frequently switching from one area of work to another (sometimes known as “context switching”). Also, if you push a team beyond it’s collective cognitive capacity then it often stops acting as a team and starts behaving like a group of individuals.
I’ve worked with managers many times to design and document roles. Although I never called it Cognitive Load, I’ve often felt the need to challenge the combination of tasks and the scope of the role. We need to create jobs with a scope people actually want and that people actually have the capacity to be successful at (but are also challenging enough - back to Goldilocks again!). We must also pay attention over time, so that we recognise when the combinations and scope need to be re-evaluated. The same holds true for teams.
Another key concept is Responsibility Boundaries. If you get the boundaries wrong for a role or a team then you can end up with a lack of ownership and engagement. You can also slow down delivery hugely and find yourself with lots of conflict to deal with.
I was interested to read the authors’ analogy of a Monolith being a single stone (literally!!!) and that skilled stonemasons can find the natural “fracture planes” within that stone. Organisations can be monoliths. You want a skilled person to identify where the natural boundaries are, the ones that will group activities together in a way that supports productive, engaged teams. Otherwise, you just end up with lots of smaller monoliths.
We all know that we can only really build strong relationships with a small number of people. Dunbar has lots to say on this if you want to take a look, but the basic rule seems to be that you can function as one team if you have up to perhaps 9 people, after that you need to split into a number of teams that all sit in one group. Once the group of teams passes a total of 50 people, then you need to rethink your structure again, to have teams, in groups, in divisions - which will work for you up to about 150 people.
This means you need to get your fracture planes right when you design your organisation, so that each small team has Responsibility Boundaries that give them ownership of a whole something and a team Cognitive Load that fits within their cognitive capacity. Then they can be engaged, productive, resourceful, and hopefully also happy - happy people do better work (but do see below for lots of other things you need in place to make this come true, nothing involving people is ever solved by just one thing!).
Types of team
The book defines four types of team you might have within your business. Three of them are quite easy to understand.
Stream-aligned teams are made up of people with lots of different areas of expertise but who are all working together on a single stream of work within the business. It’s a bit like an end-to-end production line - taking in a request for work to be done; everyone doing their part to design, produce and test what’s needed; delivering it to the customer; and supporting that customer afterwards. They operate as independently as possible, without having to hand the work over to another team at any point and then wait for it to come back.
Platform teams provide easy to use tools, systems and services that other teams can access to do their work. The other teams retain ownership for delivery, but they don’t have to each reinvent the wheel when it comes to fundamental tasks. The key is for them to see other teams as customers - making sure that what they provide is simple, straightforward, easily available and reliable. They build and evolve things that take away pain from other teams - NOT cause it!
Enabling teams focus on specialist areas. They spend their time researching, learning, evaluating new ideas. They are the curators and communicators of specialist knowledge. They collaborate with other teams for specific periods of time, to transfer knowledge and enable that team to learn to do those things for themselves. But they should not be “ivory towers of knowledge”, bottle-necks to getting things done, or allow other teams to become dependent upon them.
The fourth team is known as a Complicated Subsystem team. They have a specific definition and only exist when you really need them. I’m not going to say any more than that here. Read the book (or my other article when it comes out) if you want to know more.
In Team Topologies, they don’t advocate creating teams of people just because they all do a similar job. Teams composed of people all focused on one “function” (e.g. quality assurance, customer support, finance, marketing, etc.) could exist as platform or enabling teams, but the preference in this book is to put everyone who genuinely collaborates to deliver something into one stream-aligned team.
What they do talk about, however, is having communities of practice within an organisation. This is where rather than having a marketing team, you put a marketing person into each stream-aligned team, and then all the marketing people across all the teams see themselves as a community of people who do marketing. I guess this is a “through the looking glass” version of having functional teams in your organisation, and then getting people to work in cross-functional teams for particular projects.
Most of the examples in this book are based on large businesses. I think it’s interesting to think about how the concepts could apply in small businesses and those that are growing. In your start-up micro business, you begin with one team - all working together and sometimes wearing multiple hats each. If you have more than one “domain” (perhaps two product lines, or customer types) in your business then you have to think about how to spread expertise between the two - at what point do you need separate people focused on each domain (or is it actually just one person with two hats that they switch? And how does that work with Cognitive Load?). I’ll explore this some more in my longer article, but would be really interested in any thoughts from anyone who’s experienced it.
In my last organisation, we had 150 employees. So just at Dunbar’s magic number - which he described as "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar.” We were generally organised into functional teams, but we did a lot of cross functional working and aligned people within functional teams to product lines or customer segments. I wonder what benefits we could have opened up if we’d thought differently about how to organise our people into teams...?
Ways of interacting
This book emphasises that it’s not enough only to design the structure of your teams well. You also need to consciously specify the ways teams interact with each other. Three forms of interaction are described.
Collaboration is used when the situation requires people from both teams to combine their skill sets, discover the details of a problem or opportunity, and innovate to come up with a solution. There’s a high communication overhead to this form of interaction - so you should only use it where the value you expect to gain is worth it.
It’s interesting that lots of businesses seem to want their people to be collaborative as a core behaviour. However, they rarely think about the cost of this. If you design your teams well, then collaboration mainly happens WITHIN each team, rather than between teams, which I think makes it less costly.
Service provision is used when one regularly or continuously needs something done by another team (often a platform team) and they want to be able to easily request it and have predictable delivery of that service. For this to work, there needs to be really good clarity about what is needed, a strong focus on user experience, and the costs of the interaction (to both teams) should be minimised. But this is not a situation where the customer is always right. The team providing the service should also be looking at the big picture and be future focused, not just blindly responding to requests.
Facilitation is used where one team (often an enabling team) is helping another team to overcome capability gaps and remove obstacles to them delivering what’s expected of them. It’s not doing something with them, or for them, but helping them to become able to do it themselves. Each facilitation is a time-bound interaction, not something ongoing.
When I think about a HR team delivering within a business, I can see us interacting with different people and teams in all three of these ways at different times. Certain activities needed to be provided as a service that employees could easily access and get a quick and accurate result from. On other occasions we worked with a manager in a facilitative way, helping that manager to become better able to manage a situation in the team. In other situations we worked collaboratively with another team to pool resources and problem solve together, coming up with a better solution than either team would have arrived at on their own.
Pulling it all together
Lastly, the authors stop to remind us that even with just the right team structures and interactions in place, none of this will result in fast and effective delivery unless we also have:
Clarity of business vision
A healthy culture
Good operational/technical practices within each team
Effective financial and resource management practices
This book is a long read, a bit like a textbook at times, with some tricky sections to get your head around, but I persevered and found the content to be challenging and inspiring. It made me really think about how we can design organisations (both small and big) to be effective in how they deliver and also to be places people can enjoy working. Getting team structures, sizes, remits and interactions right for your business can really make a difference.
* Cognitive Load can be defined as the total amount of mental effort being used in the working memory