As a growing junior software engineer, I started to wonder about the tools and frameworks managers used for organising teams. I was always so curious about rigorous engineering methodologies and architectural patterns, and I was becoming curious to see their equivalents in the domain of organisation design.
Slowly I started to realise that there was little rigour. It seemed like team design was an ad-hoc, arm-waving exercise based on whimsical project needs. There was no systems thinking. And then came the Spotify Model. I saw a number of organizations going "full spotify". I'll leave it there.
Things Began To Change
Round-about 2017, things started to change. I noticed Matthew Skelton presenting at conferences. Sharing his experience of team design across a large number of organization's he'd worked with. Matthew was different because he was digging into research and relating it to modern team design.
In 2019, Matthew Skelton and his friend Manuel Pais released the Book Team Topologies. Based on their years of experience and research, they promised a toolkit for designing organisations that went beyond superficial ideas and helped organizations to think rather than offering pre-baked solutions.
Did they deliver on their promise? Yes they did. I've read the book twice, I refer to it often, and I promote the Team Toplogies concepts whenever people will listen to me.
The Thinking Person's Book
If you're interested in improving the design of your organization to improve the quality and frequency of your software delivery, then this book is probably for you. The one condition is that you have the desire to think for yourself. There is no "let's go full Team Topologies" option.
It would be easy to reduce Team Topologies to its iconic patterns. It's Stream-aligned, Complicated Sub-system, Enabling, and Platform Teams, and it's X-as-a-Service, Collaborating, and Facilitating interaction modes. While these patterns are extremely useful for laying the foundations of an industry-wide shared vocabulary, there's a tonne more value to gain from the book.
As I sit here looking at the table of contents, trying to remember the parts that stand out the most, I'm overwhelmed with the amount of information I want to write about, from the clarification of Conway's Law and it's application to modern organizations, to the concepts of a Team API.
Other standout aspects of the book are the focus on platforms. Don't build big platforms, focus on the Thinnest Viable Platform (TVP). Don't treat the platform like a collection of internal tools, but treat it like a product. So much useful advice in this area.
At 200-ish pages, Team Topologies is one of the most information-dense books I can recollect, and yet there is no compromise on readibility. Every chapter is a compelling pleasure.
Where Next?
If you pushed me hard to criticise the book, then my top piece of constructive advice would be to make some of the concepts of more actionable with detailed examples. It would be unfair to say the authors haven't attempted to address these issues. There are around 10 case studies in the book and they have started to create a github project to document their tools, like the TVP template.
Let's build on the momentum of Team Topologies. Let's add rigour to the design of technology organizations so we can get more work done and be happier along the away.
