Four years ago to the date, Team Topologies was published. It is highly successful, said to be one of the most successful DevOps books ever written, which is quite an achievement after a more approachable book like “The Phoenix Project” and the standard “Accelerate“.
I am taking the opportunity of this date to write about my take on Team Topologies: the good, the (probably) bad, and the ugly. The first post will be about the good, which are also the reasons why I chose to implement it at one of the highest quality railway companies on earth.
The second post will be about the (probably) bad: Where and why I think it might have missed the mark.
The third post will be about the ugly.
Whenever I publish a new post I take the liberty to iterate on the older ones, leaning a bit towards evergreen posts. The posts are not prewritten and will take some time, so I kindly ask for your patience as they develop.
Let’s get to the good parts of Team Topologies. Team Topologies provides a framework for team-first organizational structures, especially suited for enterprises with formerly siloed departments. It also emphasizes people and quality first. “If software is poorly designed—or more importantly, if there is a mismatch in the interaction of the software, the provider, and the customer—people will be adversely affected.” (see Part I: Teams As the Means of Delivery, page 3). With that, its authors often refer to sociotechnical design, which is more or less “achievement of both excellence in technical performance and quality in people’s work lives“.
Of course, the book’s core are team types. The most important-to-know team types are “stream-aligned”, “enablement” and “platform”. A strong focus is put on end-to-end value streams, being worked on by the aforementioned stream-aligned teams. The benefits of such an approach have been highlighted several years before the book’s publishing date and it is great to see it with such emphasis. Generally speaking, Team Topologies manages to be a succinct introduction to the most important aspects of DevOps in an enterprise context. It pushes value stream-based thinking and matches it up with domain-driven design. If you want to get up to speed with the most important ideas of DevOps and its meaning for Enterprise Architecture, Team Topologies is your book to go.
As stream-aligned teams have all the means to develop and deliver software by covering the whole technology value stream (development, QA, security, product, operations, in no specific order), they need other teams to help them out on a day-to-day basis. Perhaps they need other services to fulfill their goals. Meet the platform teams, providing them with compelling services in a self-service manner. Again, great concepts, well explained in Team Topologies. Big shoutout for underlining the difference between “create a compelling user experience” (see Part I: Teams As the Means of Delivery, page 3) and just providing a service. Creating not only a platform but also a product, with everything it entails, pushes team members to think about their respective customers. Additionally, providing compelling products is exciting. It is thinking about how to improve the user experience. It is implementing automation that helps the users fulfill their goals in a timely fashion. It is about discussing and fulfilling user requests, about really owning the service. Team Topologies highlights the importance of keeping everyone engaged. The emphasis on this is a much-needed ingredient the book and the accompanying lectures deliver.
And then there are the enablement teams. Here, Team Topologies is easily matchable with the idea of fitness functions, moving domain experts out of their ivory governmental roles into a customer-driven, hands-on modus operandi. They become “facilitators” with the goal of know-how transfer to the respective platform and stream-aligned teams.
The underlying cornerstone of Team Topologies is Conway’s Law which, in IT, is understood to be the theory that software architectures reflect the communication paths and “solution search space” enabled or disabled by the organization’s structure. The theory has been proven over and over again so I would say it is a solid foundation and a great aspect of the book.
There are many other important aspects you will find in the book and the additional training material. I only mentioned the aspects I found to be the most important ones. To summarize, in my opinion, the best aspects of Team Topologies are:
- It’s well written, succinctly describing today’s most important DevOps principles
- It introduces a much-needed organizational structure for DevOps to be successful, especially in large enterprises
- The accompanying videos by Skelton and Pais are a great addition to the book and show that the framework is alive and improving
- It emphasizes the importance of team member engagement and offers a solution for effective collaboration