Team Topologies: Organizing Business and Technology Teams for Fast Flow

First of all, buying this book as an audiobook was a mistake. It’s a textbook with diagrams to look at, best absorbed through reading. Also, I work as a software engineering team lead. Spending my free time reading books about what I do for work everyday is a quick way to burn out.

That said, the information is interesting. It explains different patterns of structuring teams within an organization based on the organization of the code for the software the business supports and how these patterns ease development of the software. For example, a system for sending and receiving packages might be organized into two teams: one that handles everything about sending packages and one that handles everything about receiving packages. This allows developers to specialize in one area and communicate often with other specialists on their team rather than requiring all developers to know a lot about both areas. This reduction in cognitive load increases the speed and quality of development, reduces mistakes, and improves developer experience. The company I work for has been practicing these principles for the past year and a half. It works well, much better than the team structure we had before.

The book also made me feel like an imposter. It states that toxic team members need to be identified and removed for the health of the team. Individuals must put the team before themselves by, for example, being on time to meetings and helping team members to complete current work before starting new work. Me, I’m chronically late to meetings, I’m a rule bender and breaker, and I split my time between current and future work. I reason that I’m late to meetings when I don’t see the point of them, especially at 7:30am. Developers may have work now, but they won’t have enough or any if no one is figuring out what happens next. I’m a free-minded introvert operating the best I can in an extroverted world. And it’s been working pretty well. My team and I get a lot of work done.

Still, I’m a team lead. I’m supposed to be showing my developers how to behave professionally, even when I think nobody gives a crap about me or needs an announcement that I’m going to be at an appointment for the next hour. It’s very possible that I’m a toxic team member that makes team topologies fall apart.

Leave a Reply

Your email address will not be published. Required fields are marked *