Why we wrote the Team Topologies book
The book Team Topologies has been 5 or 6 years in the making. How did we (Manuel and I) come to write to book and why?
Back in 2013 I wrote a blog post covering some different kinds of what I called “DevOps team topologies”, or ways of organizing teams for building and running software systems rapidly and safely. These patterns then became the well-known and de facto industry standard DevOps Topologies, which we made Creative Commons BY-SA a couple of years later. The DevOps Topologies patterns helped hundreds of organizations around the world to think more clearly about the relationships between their teams, even including Netflix:
However, the DevOps Topologies patterns, like the “Spotify Model” for team design, are essentially static “point-in-time” views of team relationships. In our travels around the world helping organizations with software delivery practices, we noticed that organizations needed guidance on how to evolve team interactions. We also saw that in many organizations the boundaries between teams are very unclear: people were asking “why are we spending so much time working with that other team?” or “why is this service so difficult to use?” - very often there was little clarity about the purpose and duration of team-to-team interactions.
Photo from TechLeadsNW meetup by James Heggs
A strong driver for us in writing the Team Topologies book was therefore to codify some good patterns that we’d seen working in the industry and to define some patterns and terminology around team-based software delivery. These patterns and approaches increase the quality and clarity of team interactions within organizations involved in building and running software systems, enabling faster flow and better outcomes for users and organizations.
