The Real Value of Team Topologies
What is Team Topologies? Is it a framework? Is it a set of principles? How can you start using it without having a big-bang, top-down approach? And is that ever the right approach?
Two years ago I read Team Topologies for the first time. Shortly after that, in May of 2023 there was the inaugural Fast Flow Conference in London. During interactions with the Team Topologies team and other attendees, I had the profound feeling that “this was important”. Honestly though I couldn’t put my finger on how and why. Yes everyone was lovely, yes there was ample ‘humanity’ on show in our interactions – but how does this translate into the workplace?
I too wanted to have more humane engineering practices based around the ideas of limiting work in progress, giving teams autonomy and basically treating them like adults. I too had been impressed by the work that Matthew Skelton did on DevOps Topologies and describing failure modes of teams in DevOps.
After being directly involved in many digital transformation initiatives, I was, however, dubious about any new framework which promised to ‘fix the problems of software delivery’. And this is where Team Topologies initially set itself apart. It didn’t claim to be a framework, it was a collection of guiding principles.
Not a Framework
But what exactly does that mean? When you look at many of the offerings from Team Topologies right now, it does actually look more and more like a framework, i.e. follow these steps to improve your organisational agility and time to deliver software systems.
But go further back, and you’ll see the roots of the mission, and read the book and understand the principles. Team Topologies was based on Matthew’s DevOps topologies. These were steeped in experience. These connect at an individual level in any organisation. I can explain these ideas to engineers, product owners and engineering managers.
DevOps Topologies neatly points out that while the initial intention of DevOps was to make single teams responsible for software development, deployment and operations, somehow, twenty years later, we’re still failing at that.
Source of the image: https://web.devopstopologies.com/
Team Topologies, therefore, aims to understand why we are failing and to introduce ideas which will help us do better at both an indiviudal and an organizational level. However, as a practical engineer, I’m really not interested in the organizational level. I’m happy to control the things that I can reasonably control rather than relying on others to provide a framework for that. Also I know that I’m only ever one re-org away from the teams changing around me or me losing my job.
Not a Programme of Change
In the Team Topologies book and on the website, more ideas are shared around different team types, interaction modes, and understanding the content of the work through value chains. I argue that these are not core principles. They are ways of achieving better value generation for your business – but for me Team Topologies core principles are about the Team – not the work.
While it’s easy to get distracted by buzzwords like team modelling, Conway’s Law, cognitive load and Dunbar’s number – the human element of what Team Topologies means is more valuable than the team types or interaction modes.
Therefore it’s not a programme of change – it’s a way of looking at your organisation.
The Human Principles
The core principles from the Team Topologies book are deeply human. I’ve distilled them as follows in order of importance:
The smallest working unit is a Team i.e. don’t rely on 10x engineers to save you all the time.
Teams should be of optimum size, have clear responsibilities and decide how they interact with other teams in the organisation.
Teams work better when they control everything they need to perform their work.
Teams achieve more when appropriately supported and given space to learn and continuously improve.
Don’t overload your teams. Limit “Work In Progress” and hence cognitive load in your teams to avoid burnout and increase innovation.
Understand the effort that your organisational design has on your software architecture. This is the effect of Conway’s Law or as Ruth Malan puts it: “If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins“.
Individual, Team-Centric, Stay Minimal
Team Topologies is about team orientation.
So, you can do Team Topologies with just this minimal set of principles. This means you don’t have to change your team setup. You can start by sizing your team correctly between 5 and 8 people. Ensure it has an agreed way of working and communication mode. Aim for a multi-skilled team approach where the team can deliver
Think about the broader organisation. Measure cognitive load in your teams. Use platforms judiciously. Consider certain types of enabling teams. Be mindful of the tools you use. Consider platforms.
But before you get swamped in a re-org, think about the type of organisation you want to build at a personal level. How should people operate? How should they feel?
The real value of Team Topologies is the things that you choose not to do.
(Note: This content was originally published on Richard's blog.)
About the author
Richard Bown, Team Toplogies Advocate
In his roles as an independent software consultant, tech lead, and software architect, Richard catalyses organisations and teams towards designing and building sustainable and resilient software architectures.
His writing includes recognising and managing extraneous cognitive load, the role of the individual in the Team Topologies organisation as well as about the first Fast Flow conference in May 2023:
Exploring cognitive load to avoid team toxicity
Thoughts and reaction to the Fast Flow conference in 2023
Richard is a co-organiser of the Netherlands Fast Flow meetup.
