Gene Kim Q&A with the Authors of Team Topologies

Gene: Every company loves an org chart, but why are they really so misleading

Matthew and Manuel: Org charts are management-focused constructs, meant to funnel lines of reporting from the bottom to the top—the typical hierarchical pyramid. The fundamental problem is extrapolating this construct and assuming it actually represents the lines of communication in the organization, alignment of business goals and decision making power. 

This misinterpretation still happens in most organizations today and leads to known issues of knowledge silos, power grab, “us vs. them” mentality, lack of business alignment, and decisions made by those with a superficial (aggregated) view on the subject. 

What we’re saying with Team Topologies is that in today’s world, organizations need to expand their approach to team structures and interactions in an evolutionary way if they want to survive. Empowering people and teams to be the best versions of themselves is key to success in this era.

Gene: How can someone who’s not a manager use this book?

Matthew and Manuel: A good chunk of the material in Team Topologies focuses on behaviors and characteristics of the different types of teams and different team interaction modes (covered in Chapter 5 and Chapter 7). These sections describe, in detail, patterns and behaviors that teams can adopt to be more effective at building and running software, so these are ideal for non-managers to read. We wrote these sections to be particularly useful to developers, testers, business analysts, product owners, DevOps people, SREs, etc.—people within teams who would benefit from clearer team interactions.

We expect the team patterns in Team Topologies will help team members to detect and correct unhealthy team-to-team interactions, improving how their team works with other teams. In this way, we’re empowering people to improve their work environment through better team interactions and more defined team behaviors. 

Gene: How can someone who is a manager use this book to convince their leaders to undertake another re-org?

Matthew and Manuel: A manager can use Team Topologies to explain to their leaders why they should stop doing re-orgs! Part of the paradigm shift in dynamic organizations is understanding that re-orgs can no longer keep up with the pace of innovation in terms of technology, methodologies, and people interactions. Instead of discrete revolutions (e.g. Agile, DevOps, SRE), we need continuous evolution and feedback from team structures and interactions. 

Specifically, they can start by mapping existing teams to the four fundamental topologies, as mentioned in Chapter 5 (pages 104–109) of Team Topologies. What that enables is identifying the gaps between current behaviors, skills, and interactions in the existing teams and those expected in the fundamental types. We find that helps identify and reduce misalignment of priorities and business goals (which slow down flow), as well as increase clarity on who’s responsible for which services and how other teams are supposed to interact with them.

Once that mapping process has started, you also get a 30,000-foot view of your organization’s delivery and operational capabilities, inter-team dependencies, and intra-team cognitive load. You can then start to set up the organization to acquire missing capabilities, empower autonomous teams, and reduce cognitive load—for example, with a modern platform approach, as described in Team Topologies.

Gene: Why are the interaction modes so important?

Mathew and Manuel: The near-legendary systems thinker Russell Ackoff said, “Problems that arise in organizations are almost always the product of interactions of parts, never the action of a single part.” Organizations are sociotechnical systems, and this is especially true of organizations that build and run business-critical software systems. If you think about it, the main thrust of the entire DevOps movement since 2008 has been to improve how different parts of the organization work together, first looking at Development (Dev) and IT Operations (Ops) but then expanding beyond those groups into other parts of the organization. 

When we (Matthew and Manuel) went into organizations to help them improve the effectiveness of their software delivery, we often saw teams struggling to understand how they should relate to other teams and why. People would be told to “collaborate” without any context or clear outcomes; teams would expect a certain level of service from another team that had no idea that such service was expected of them! The lack of clarity about team interactions was (and is) causing huge amounts of waste and frustration within organizations; this in turn—via Conway’s Law—results in software architecture that is messy and poorly aligned to team responsibilities, making it difficult to evolve and support.

In Team Topologies, we decided to characterize what we see as the essential three team interactions modes, the only ways in which teams building and running software really need to interact. By adopting the three interaction modes, organizations can help their staff understand why different teams are interacting in different ways at different times, contextualizing the work in hand, and providing a way to detect misplaced boundaries and capabilities.

Using the three team interaction modes, organizations also can develop a much clearer picture of the likely software architecture that will result from the communication structures in the organization and “course correct” much sooner than in the past by adjusting skills, capabilities, and responsibility boundaries to suit the changing business demands.

Gene: Only four team types? How can that be true?

Matthew and Manuel: We asked ourselves the same question, to be honest! But as we applied the patterns in the DevOps Topologies (a catalog of contextualized team structures for DevOps) in our consulting work, and also during our research and case studies, we saw these fundamental topologies repeated across the board with different terminology but essentially the same approach. Team Topologies gives them a name and clarifies the expected purpose, responsibilities, and behaviors for each team type. Having a shared language to talk about team organization and interactions can be very powerful to convey challenges to effective software delivery and operations, as well as generate empathy between people across the organization.

We started with stream-aligned teams, a cross-functional team aligned with a business stream of work that is able to build and run a service independently (let’s say at least 80% of the time). This pattern has been proven to be the most efficient for fast flow without damaging the quality and operability of the delivered services. We don’t need to go any farther than the DOES conferences to find numerous success cases. 

Another emerging pattern are platform teams, but with a focus on DevEx and (internal) customer satisfaction rather than on standardization for the sake of standardization. In other words, the idea of “treating your platform as a product.” Organizations from Adidas to BMW, ITV, and Capital One, to name a few, have reaped the benefits of enabling stream teams to go faster with self-service platforms and also by helping them upskill their operational capabilities.

The last two team types (enabling and complicated-subsystem) are less common but also support stream teams by filling in capabilities and/or knowledge gaps, and reducing their cognitive load.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•