[Book Review] Team Topologies, Matthew Skelton and Manuel Pais

Two-line summary

5 minute read

My unexpected disappointment in Team Topologies stems from the fact that it was so frequently quoted in conversations with senior leadership. Though I do affirm that the referenced concepts are effective and widely applicable, the delivery itself is riddled with basic writing errors that make the reading experience incredibly frustrating.

My rating: 2/5 stars

Table of contents

• Valuable takeaways
• Downsides of this book
• Most notable excerpts

Valuable takeaways

The resounding strength of this book is its ability to define a set of theories to describe organizational behaviour in tech with alarming accuracy. The most valuable takeaway is gaining the terminology behind common phenomena that is otherwise felt subconsciously. As an example, I'd previously struggled to articulate why widely-scoped teams often overestimate their capacity during sprint planning. I learned here that is it due to cognitive load in the form of adhoc distractions and maintaining past projects that is not typically factored into effort estimates.

Team Topologies further equips the reader with an understanding of how the individual experience is reflected in the context of an organization's broader structure. You no longer need to wonder, "why am I not motivated at work?" This book takes the guesswork out of identifying pain points by introducing frameworks such as Dan Pink's three elements of intrinsic motivation: autonomy, mastery, and purpose.

I also enjoyed how clearly the authors are able to establish relationships between cultural symptoms and their respective structural root cause. I've experienced roles that required constant re-orgs and an unsustainable amount of context gathering to get anything done. It was not until this book that I was able to understand the organizational flaws that cascaded into these issues.

It's quite useful to zoom out of your day-to-day to consider the reasoning behind team architecture. It helped me understand how and why leaders in my own workplace were thinking about the evolution of the company.

Downsides of this book

First and foremost, the grammar in this book makes it near unreadable. It is published by IT Revolution, which is a tech-first publishing group and may explain why the writing seems like an unedited first draft. Here's an example from the foreword; try to understand it on your first pass:

"To achieve duly scoped, bounded responsibilities, natural - and relatively independent - system (sub)structure is sought to align teams to." 

Huh? Another example from the first chapter:

"The recent focus (at least within IT) on product and team centricity, as illustrated by Mik Kersten's book on moving from Project to Product, is another major milestone."

This sentence could easily be improved to say, "The recent focus on product and team centricity is another major milestone, as illustrated by Mike Kersten...". Instead, the writers choose to punctuate with parentheses in a dependent clause, requiring the reader to reread the sentence several times in order to understand it. Poor sentence structure and run-on sentences are a common thread throughout the entire book. I felt exasperated by the writing style. 

Another issue is how the concepts are sequenced and structured. The authors speak on topics at length before finally defining them many chapters later. The title of the book is Team Topologies and yet the first time this term is defined is at the beginning of chapter four, which reads:

"[...] we need to consciously design our teams rather than merely allow them to form accidentally or haphazardly. We call these consciously designed team structures team topologies."

If this term was presumed knowledge in the first three chapters, why is the reader introduced to it as if it's new information in part two? I can't make sense of this beyond a severe lack of editing.

I found that entire sections of the book were left up to the reader to derive conclusions instead of providing a logical sequence. In chapter three, there is a case study about the office layout of Auto Trader. It lists their various attempts at optimizing layout including only allowing employees to have one monitor and seating non-technical and technical groups together. At the end of the study, it notes that flow should be optimized for specific collaboration but doesn't explain how they arrived at this conclusion. Did any of the attempts work? Which worked and which didn't? Is there a recommended structure or is the study intended to encourage layout experimentation? It's frustrating that the reader is meant to guess the reasoning behind a case study instead of culminating the evidence with a clear conclusion. 

Beyond writing style, I found that some recommendations were just bad takes. In chapter three, it states that "looking to reward individual performance in modern organizations tends to drive poor results and damages staff behaviour." It goes on to note the success of Nokia giving bonuses on a team basis, rather than an individual basis. In my experience at some of the largest tech companies, merit-based compensation is one of, if not the main, source of motivation for highly-skilled candidates. Even on a balanced team of high-performing employees, the purpose of performance reviews is to evaluate the relative output of individual team members. I would challenge these authors to interview folks at Twitter, Facebook, Reddit, etc and ask them how they would feel about team-based compensation instead of focusing on insurance, car and telco. To me, this is a dated mindset that would never work at a modern tech company.

My final point has no bearing on the review; it's more of a general note. I read this book as part of a book club with other individual contributors. While it was interesting, the material cannot be implemented unless leaders with powerful organizational influence read and buy into its concepts. The premise of this book is not something you can tackle with a bottom-up approach so it's not entirely applicable to a general audience.

Most notable excerpts

• "Businesses can no longer choose between optimizing for stability and optimizing for speed." (Chapter 1: The Problem with Org Charts)
• "Much like a software architecture document gets outdated as soon as the actual software development starts, an org chart is always out of sync with reality." (Chapter 1: The Problem with Org Charts)
• "When cognitive load isn't considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts." (Chapter 1: The Problem with Org Charts)
• "Given any [particular] team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist." (Chapter 2: Conway's Law and Why it Matters)
• If, logically, two teams shouldn't need to communicate based on the software architecture design, then something must be wrong if the teams are communicating." (Chapter 2: Conway's Law and Why it Matters)
• "Building and running software systems is a sociotechnical activity, not an assembly line in a factory." (Chapter 4: Static Team Topologies)

As always, would love to hear your thoughts and feedback in the comments below.