Guest Post from Matthew Skelton, co-author of Team Topologies
Key Takeaways:
1. New team-based organizational designs are proving valuable across the IT industry.
2. Adopting new team structures is only part of the picture: it’s the interactions between teams that really counts.
3. Since 2013 many organizations have used the DevOps topologies patterns to explore different team models.
4. The new book Team Topologies by Matthew Skelton and Manuel Pais addresses important organization dynamics around team-based software delivery.
Team-First is the New Normal for Enterprise Software Delivery
High-performing organizations have been adopting a team-first approach to software delivery for many years, and this approach is now becoming more widely adopted. The eagerly-anticipated 2019 State of DevOps Report emphasizes the importance of empowering teams to accomplish outcomes that align to organizational goals, noting that such organizations significantly outperform organizations that have not adopted modern practices.
There is an increasing body of evidence from industry and research to show that the functional silos of the 1990s and 2000s are no longer appropriate for the fast-moving world of modern software delivery. Charles T. Betz, Principal Analyst at Forrester Research, says that the “integrated, semiautonomous, multi-skilled product team is here to stay. It is the most effective means for discovering and delivering value to customers.”
The need for new team types and team structures is being driven partly by the need to optimize for the reliable flow of change; handovers between teams of specialists can block flow and cripple delivery performance; instead, many organizations are adopting models that align teams to the streams of change.
Patterns for Team-Based Delivery Can Help Significantly
These days I spend much of my time helping organizations optimize and evolve their teams for better software delivery. My interest in this space goes back many years: I’ve performed music in bands, choirs, and orchestras since I was at school, and I think I have developed a deep sense of how different groups need to work together to make a bigger whole emerge (whether through music or software).
Between 2006 and 2011 I was Technical Director at digital agency in London where we often worked together with other suppliers to deliver large-scale ecommerce systems for global brands and financial services clients. This gave me a practical awareness of how collaboration and service boundaries affect software designs (in good and bad ways).
In 2013 I first published the DevOps topologies patterns that have become the de facto industry standard for discussing team-based software delivery for modern enterprises. These patterns (and anti-patterns) explore different ways of arranging collaboration and service boundaries for IT teams and the implications for organizations. Together with Manuel Pais and others, these patterns evolved as a community resource to be used by many forward-thinking organizations around the world, including Netflix, Condé Nast International, Adidas, and Accenture.
For instance, here is Philip Fisher-Ogden, Director of Engineering at Netflix describing how the topologies patterns have helped Netflix:
The patterns have also helped global publisher Condé Nast International. Here is Crystal Hirschorn, VP Engineering, describing why they found the patterns useful:
The DevOps topologies patterns resonate with people because they help to stimulate conversations about the different kinds of dynamics that different responsibility boundaries and collaboration approaches can bring. They are a great starting point for thinking about modern enterprise software delivery, but what’s missing?
Team Interactions and Collaboration Boundaries Matter More than Static Structure
When Manuel Pais and I were working with various organizations around the world (China, USA, Europe), we realized that the static team boundaries in the DevOps topologies patterns didn’t tell the whole story. Some organizations had adopted the well-known “Spotify model” but found that software delivery had not really improved. We realized that there are many dimensions around software delivery—not just team structure—that organizations need to address to be successful, including:
- Conway’s Law
- Team cognitive load (see our DOES EUR 2019 talk on team cognitive load)
- Team interactions
- Dynamic organization evolution
In fact, the legend of systems thinking, Russell Ackoff, famously said that:
“An organization is a system and the performance of a system depends more on how its parts interact than on how they act when taken separately.” —Russell Ackoff, Management f-LAWS, 2007
This is borne out by the experience of many forward-thinking organizations building and running software today. Success lies not simply in creating a new organizational design but in defining clearly how the different teams should interact and collaborate and—crucially—the “why” behind these patterns.
With our 2019 book Team Topologies we have aimed to move forward the conception of team-based software delivery by explicitly addressing the ways in which teams should interact for effective delivery with a set of patterns that are easy to recognize. This enables us to detect problems and adjust team interactions to meet new market or regulatory challenges quickly, treating the organization as “a complex and adaptive organism,” in the words of organization design expert Naomi Stanford. Organizations around the world are finding the Team Topologies approach very illuminating and useful for improving their software delivery capabilities.
Matthew Skelton and Manuel Pais both run training courses and consulting based on the Team Topologies approach. Find out more at teamtopologies.com
