Book Review: Team Topologies

Team Topologies is an important book for software leaders at product companies with multiple interacting teams. First, it provides a visual language that articulates team structures and interaction models that are fundamental to software design. Second, it comes from a place of real experience coupled with tons of research (there’s a 15-page bibliography written in text that is very small). Third, it verbalizes all sorts of thoughts that software leaders know to be true, but can’t easily put into words. Fourth, it emphasizes a key factor in software development that is not considered widely enough in the industry: cognitive load on teams.

I know a good book when I’m constantly underlining sentences or entire paragraphs. Some entire pages of this book are thought provoking. There is very little time wasted and barely any fluff, which is unusual for a business book.

Also unusual for a business book is the beautiful design and colorful nature of it all. (So much color!) The book is very artistic for its genre and quite pleasant to read. The visuals are fantastic and each section of the book is color-coded. It is extremely well thought out from a reader’s experience. And as someone who just wrote his own book, I can sincerely appreciate the amount of thought that went into the reader’s experience of this title.

However, I wish it came in a spiral bound edition because the amount of note-taking and re-examining parts of the book really make this paperback binding a chore. I found I was constantly underlining great points and wanting to flip around, but the binding of the book kept getting in my way.

I bought this book at the very end of 2019 when my boss said we should all buy it and study it to prepare for our major 2020 initiatives. My boss had dozens of post-it notes sticking out of the pages and I showed him how marked up my book had become. In speaking with the rest of the team, I found that everyone was marking their books up. TT is not a casual read.

One of the key lessons taught by this book is the importance of Conway’s Law: “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” (10). This book goes all in on Conway’s Law. It is the foundational belief upon which every concept is built. It’s like transubstantiation in Catholicism. So, if you’re the heretical type who disagrees with Conway’s Law, you’re gonna have a hard time with this book. I had never really given much thought to Conway’s Law before, but it confirms a lot of what I’ve believed in my gut since I started managing software teams in 2008.

Another key lesson is the idea of a “reverse Conway maneuver,” which basically means: arrange your teams in the way you’d like your software to look and the software will take that shape over time. I love this idea and had never considered it before. It’s simple and brilliant. It’s something we are actively trying at work as part of our digital transformation. Wish us luck!

Even more brilliant is that Conway’s Law was written in the 1960s! This isn’t new stuff. I loved getting caught off guard with this tidbit, too: “One key implication of Conway’s law is that not all communication and collaboration is good” (24). I wouldn’t say I’m in the camp that believes “all communication and collaboration is good,” but this idea helped me to see that I’m not always looking for bad, ineffective, or costly communication across teams. Chat systems like Slack make you believe everyone should talk to everyone. When I see big group conversations happening, I often think, “It’s cool to see people from different teams collaborating.” Instead, I should be thinking, “Is their communication actually helping or hindering?” (No, this isn’t to say people shouldn’t get to know each other. Anyone reading this should know better.) TT sums it up nicely: “Everyone does not need to communicate with everyone” (26).

Add alt text

There are so many great one-liners, too. I love this one from page 17, “An organization that is arranged in functional silos … is unlikely to ever produce software systems that are well-architected for end-to-end flow.” How true is that? As leaders, we hear software issues blamed on individuals or a hundred other things, but very few people consider the fact that bad software and bad products can be a byproduct of team organization and communication patterns. The code is more than the code.

Much of the book is digestible only for people experienced with larger companies or within larger companies. For example, when I was a dev leader at a digital marketing agency, I think I would have found very little value in this book. However, where my team and I are right now in the midst of digital transformation and a complete company overhaul, this is just what the doctor ordered.

On the down side, the book is clearly geared toward “enterprise people.” What does that mean? It’s overcomplicated and uses too much academic language. I don’t know any technologists who talk the way these authors do. Funny enough, even the authors don’t talk this way in their excellent presentations about the book (search the YouTubes). The book embodies a “professional vibe” that seems more “consultant” than “real-world technologist.” There are many, many sentences that are overly complex and difficult to get through. Here’s an example, which literally made me draw a sad face in the book:

“When we undertake a reverse Conway maneuver (see Chapter 2), the homomorphic pull of self-similarity that Conway’s law identifies is anticipated: the organization is set up to match the communication paths needed in the software and systems architecture. However, a new architecture cannot be expected to emerge as soon as a new team structure has been devised and implemented. Precisely due to the forces behind Conway’s law, the existing software architecture will initially ‘push back’ against the new team structures.” (147)

The book is riddled with sentences like this. It reminds me of the satirical Turbo Encabulator video, which says: “Now, basically the only new principle involved is that instead of power being generated by the relative motion of conductors and fluxes, it’s produced by the modial interaction of magneto-reluctance and capacitive diractance. The original machine had a base plate of prefabulated amulite, surmounted by a malleable logarithmic casing in such a way that the two spurving bearings were in a direct line with the panametric fan.”

The book focuses heavily on the “Reverse Conway Maneuver.” However, there’s not enough content in the book describing the pitfalls and gains of such a reorg. My team is in the midst of the maneuver and I’d love to have some psychological assurances going into it. As I read through the book, I kept hoping for more “here’s what you can expect” type content.

Lastly, and I’m just nitpicking here, but there are several references to musicians and ensembles. Speaking as a musician, I find these distracting because the metaphors are generally not right. I’m reminded of the book I is an Other, which is a great book that describes the pitfalls of using metaphors. Some people don’t get metaphors, some people disagree with them because they have different ways of thinking. I found that these metaphors took away from the message of the book for me. For example, “just as a jazz band coordinates the music it plays, we should expect to carefully curate the communication that takes place within an organization” (133). I literally wrote “No” in the side margin almost every time there were musical references. I’ve played in several jazz bands and the style of communication is not analogous to what happens within an organization.

Overall, great book. Definitely 5 stars from me. I learned so much reading this book and it helped me to quickly see dev leadership differently. That’s a rare quality in a book. Get yerself a copy.