Team Topologies 📘
My review, the best ideas, and takeaways from the famous book by Matthew Skelton and Manuel Pais.
Team organization — that is, how people communicate and work together — can make or break companies. Yet, when it comes to organizing engineering teams, it is hard to find good, comprehensive advice.
Most ideas out there feel either too abstract — e.g. “create two-pizza teams” — or too specific — e.g. “the ideal ratio between engineers and managers is 5”.
There are few works that manage to stay high-level, so to be relevant to many situations, while also being practical, so that you can apply lessons to your team.
Team Topologies is one of them.
Written in 2019 by Matthew Skelton and Manuel Pais, both experienced DevOps consultants, it has rapidly become a seminal book about team organization.
It has achieved this by providing an original, brilliant mental model about collaboration, coupled with case studies that let people understand how to use it in practice.
So, today I will review the core ideas in the book and give you my own take on them. We will cover:
🔄 Conway’s reverse maneuvre — using Conway’s Law for good.
🏋️♀️ Cognitive Load — an original way to think at teams’ scope.
🍀 The Four Types of Teams — the core of the book.
💬 The Three Interaction Modes — how the types of teams work together.
📌 My takeaways — what I personally took from the book and how to use this in practice.
Let’s dive in 👇
🔄 Conway’s reverse maneuvre
In Karate Kid — one of my favorite movies when I was a kid myself — an old Karate sensei teaches martial arts to a boy, by using weird, seemingly unrelated exercises.
Team Topologies pulls off a similar trick with software. It teaches you how to write good code, but almost never talks about it.
In fact, the authors are strong believers of Conway’s Law, which states that your software architecture will eventually resemble your team organization. So much, that they believe that if you create a good team organization, software architecture will largely take care of itself.
But what makes a team organization good? The book gives you a brilliant answer, which is about cognitive load 👇
🏋️♀️ Cognitive Load
There is wide consensus in our industry around splitting engineering orgs into small teams. There is less consensus on how to do so.
In Team Topologies, a good team should own an amount of software that can fit in your head (or their head, as a team). Engineers and teams are able to bring the most value when they sustain the right amount of cognitive load for their work: not too much, not too little.
Cognitive load here is the amount of mental effort that is required in your working memory to perform your job. Basically, how much stuff you have to load in your brain.
However, not all cognitive load is created equal. There are three kinds:
🔨 Intrinsic — your tech skills, which are intrinsic to your work. E.g. how classes are defined in Java.
🐌 Extraneous — stuff you have to remember that doesn’t bring value, so it is mostly a distraction. E.g. how do I deploy this app, again?
🌟 Germane — knowledge about your business domain and the problems you need to solve. E.g. what are good abstractions for financial data, or best practices for an e-commerce checkout.
Germane load is the only knowledge that creates actual value. So, you want to create teams where such load is maximized, while intrinsic and extraneous ones are minimized.
But how so? 👇