Bests & Worsts Reviews from Amazon

This book was hard for me to read and hard for me to review. It made me angry at times. Some of the recommendations of the book almost made me throw it away on the spot. Yet, I wanted to hear what the authors have to say. The further I got in the book, the more I became to see some value in what they were sharing. Yet... I would not recommend following the suggestions from this book. This book is about teams and organizations. How should you structure your teams and the organization? It proposes four types of teams (topologies) that you might need to build products. Their argument, when you make these teams topologies clear and specify the interaction modes then that should greatly improve your product development. However... the whole book stands and falls with their interpretation of Conway's Law and the strict approach to code ownership they take (chapter two). They see that components/services must be owned by teams and the team design must map to the architectural structure. Personally, I disagree with both of them and worked for over a decade in environments where this isn't true... making it hard to continue the rest of the book. They also argue that teams should be separated on purpose and only coordinate with the designated interaction mode... which is the exact opposite of the environments that I enjoyed working most where interaction between teams was frequent and informal. In my experience, this level of ownership and separation is going to cause silo forming and will make building one product really hard. I would recommend against this. The rest of the book explores the four team-topologies (stream-aligned teams, enabling teams, complicated sub-system teams, and platform teams. Of these, the authors recommend most teams ought to be stream-aligned and I would agree with that. That said... many stream-aligned teams in the same product would likely need to work on the same services/components, yet the author seems to claim that this isn't the case as good modular architecture can solve that (?!?). Here my world must be very different from the authors as I do not see how this can be resolved. The last part explores the three team-interaction modes, (1) collaboration, (2) x-as-a-service, and (3) facilitating. The different kind of teams have different default interaction modes. Again, I found the recommendations against non-standard team interaction quite harmful. All in all, as said, this is a difficult book to read and review. I learned from it, I liked it at times, it was vebose but written ok… yet I would never recommend it to anyone, with the exception of people who want to learn about what is the opposite of multiple teams interacting closely on shared code. For this reason, in the end, I decided on two stars.