Team Topologies: Organizing Business and Technology Teams for Fast Flow

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.

Was reading intently until they mentioned they'd purposely restricted their engineers to only have one screen, so they could "look at each other more". I can't imagine how someone could decide to deliberately damage their engineer's productivity like that and get away with it. But perhaps they didn't, hence writing books now instead. Stuff like that is a real canary as to the wisdom of the authors of this book. Save your money.

These guys really did their homework on reviewing the current literature, and building the case between team structure and the architecture of software. What I really liked is how the different operating and engagement modes for teams and between teams can evolve to affect healthy patterns for the software.As a technology person it's easy for me to wrap my head around the patterns for teams just like the patterns for software, and how use can use one to influence the other for good (and bad) outcomes.I bought both the Audio book and the physical book. They go great together, as you can listen to the audio version and then back it up with references to and re-reading the physical version.

Skelton and Pais successfully demonstrate the powerful link between how software teams are organised and interact with each other and the corresponding impact on software change velocity and quality. This book is a quintessential guide on how to organise development and operations team to win in a rapidly changing business environment. While the ideas contained here on DevOps and Agile are not new the authors provide a detailed, thorough and practical guide on how to align business, dev and ops team to deliver. As it were, they answer the existential question on how to move from traditional functional teams to cross functional teams that follow agile and DevOps principles to delivery value faster. This book is a must read for any technology leader who wishes to successfully implement DevOps and/or Agile.

If you're a busy CTO, the audiobook is just as excellent as the written one.Team Topologies highlights the problems your org chart is creating for your software's architecture (and as a result, your business).To remedy these problems, Matthew Skelton and Manuel Pais offer a different perspective on org structure in the form of four fundamental team topologies: value stream aligned teams, enabling teams, platform teams, and complicated subsystem teams.The theory behind these team structures is chiefly built upon the premise of the Inverse Conway Maneuver, which "recommends evolving your team and organizational structure to promote your desired architecture." Ideally, this would require skilled software architects also be the architects of the teams in order to - for example - develop well-defined team APIs since software architects are already expected to be masters of API development.Additionally, the concepts of developing sensing organizations, using Domain Driven Design to identify fracture planes, and managing a team's cognitive load are dissected to explain how to effectively structure high-performing teams.If you have read and implemented the practices espoused in Project to Product, the Devops Handbook, and Accelerate but are still encountering communication bottlenecks and problems with scaling your existing team structures to meet product demands, then I highly recommend Team Topologies.

We read this book as part of a work book club and while there was a lot of good ideas and content, many found it tough to absorb and apply. Perhaps it was not the right read for us at the time but I definitely will continue to use this book as needed, just tough to sit down and read it consistently over a couple weeks.

It helps me to complement my experience. It is an easy book to understand.As a non tech person, it was not hard to read. Glossary helps a lot.

Finally a resource that looks past the agile teams and supporting business facing only products by introducing Enabling and Platform teams. I read this book twice. The first time I read it I was working at another company and many of the teams were stream-aligned and there were platform teams, so the book was more validation rather than giving me new knowledge. I am now reading it through the lens of my new company and how they are organized and I am riveted. The business unit I am in is Conway’s law amplified and the book is giving me the words to be able to communicate the problems and why. I’m looking at the communications and dependency overhead and inside I am screaming “look at the software architecture!” And “break up the DB and Ops silo!” I myself am forming a platform X-as-a-Service team for Cloud-Native apps that includes CICD, containers, microservices architecture, data analytics services, observability services and using the book to help me design the teams. It is a well written and actionable book.

I hoped for a deep dive into the tradeoffs and tension between vertical vs horizontal teams (stream aligned vs the other three in the book’s parlance). Instead the first section contains countless quotes that are nice, but platitudinal. Then they provide basic introductions of their team types, then provide contextless examples of structuring a group of teams. There was no second order analysis such as observing the side effects and potential weaknesses or strengths or how to balance or offset these. It served as an okay list of definitions but failed to go further or provide a deeper look at the inherent tradeoffs or push and pull dynamics.To make the feedback explicit, one example of missing substance was a complete absence of the observation that service teams (all 3 kinds) inherently introduce the risk that product teams can become blocked because they must wait for the service teams to build and deliver their tools and services. What happens when the tools team needs 6 months to get their stuff ready? Should the product team work around them? What happens when the product teams implemented 10 ad hoc versions of the tools they were waiting for in the interim? How should you unwind this? Which is preferable, how do you weigh these tradeoffs?

The book gives you a different perspective regarding how to build software in an effective way, by putting a team first approach and given the proper tools and guides to achieve it