Q&A on the Book Team Topologies

The book Team Topologies by Matthew Skelton and Manuel Pais shows how to arrange teams within an organization to enable effective software delivery. It describes four fundamental team types and three team interaction patterns, and dives into the responsibility boundaries of teams and how teams can communicate or interact with other teams. Team Topologies also explains why and how organizations need to listen to internal and external signals to know when to evolve team structures to meet new demands.

InfoQ readers can download a book extract of Team Topologies.

InfoQ interviewed Matthew Skelton and Manuel Pais about the obstacles to fast flow in organizations, the reverse Conway maneuver, encouraging team members to develop a team-first mindset, the four fundamental team topologies, and asked their advice regarding architects and architecture teams.

InfoQ: What made you decide to write this book?

Matthew Skelton: We’ve helped many organizations around the world to understand and improve their organization design and organization dynamics for software delivery, and we wanted to share some of the insights we’ve developed. We’ve seen people and teams in countless organizations struggle to understand how and why they should interact with other people and teams, leading to frustration and ineffectiveness. In writing the Team Topologies, book we hope to help people gain clarity and purpose.

Manuel Pais: Since the original DevOps Topologies were published in 2013, thousands of organizations from all parts of the world have found them useful. We know that companies like Netflix have used the patterns to help evolve their teams, along with Condé Nast International, Accenture, and Adidas. We realised that with the topologies patterns we had provided something very useful for the IT industry, but we wanted to move beyond the static team structures presented in the original topologies patterns to include dimensions like Conway’s Law, team cognitive load, team interaction modes, and organizational sensing for team evolution. The result is the Team Topologies book.

InfoQ: For whom is it intended?

Pais & Skelton: We wrote Team Topologies for anyone involved in building and running modern software systems. There are useful patterns in the book for engineers, testers, SREs, and Ops people, especially around team interactions and behaviours. There are key insights for architects and heads of department who are responsible for thinking about responsibility boundaries within the systems. And there are crucial concepts and themes for executives, because organization design is effectively a constraint on the "solution search space" and so for a certain organization design, some solutions will never be discovered. That’s a strategic C-level concern.

We’ve tried to write the book in a way that is accessible to everyone, with limited jargon and nice clear examples. People have told us that we’ve succeeded there, which is great.

InfoQ: What are team topologies?

Skelton: Team topologies describe how teams are arranged in an organization, including their responsibility boundaries and how they communicate or interact with other teams. The thinking in the Team Topologies book goes back to 2013 when I first used the phrase "team topologies" to describe some team patterns that seemed to work in a DevOps context. Since then, Manuel and I - together with some community involvement - curated the well-known DevOps Topologies patterns which have helped many organizations around the world to think about and optimize their teams for software delivery.

Pais: In the Team Topologies book we have greatly expanded the thinking and patterns for successful team-first software delivery. We’ve defined four key team types (which we discuss below), three key team interaction modes (Collaboration, X-as-a-Service, and Facilitating), along with many further patterns and heuristics for effective organization design. In the end, successful software delivery is not just about how you structure teams, but also how the teams interact, how you anticipate Conway's Law, how you right-size the software responsibilities, and how you set up the organization to learn and evolve.

InfoQ: What obstacles to fast flow do you see in organizations?

Pais & Skelton: A major obstacle to the fast flow of change in many organizations is the presence of functional silos: groups of people with similar skills whose input is needed for the change to happen. The problem with silos is that handovers between groups act as huge blockers to flow.

What we describe in the Team Topologies book - and what forward thinking organizations are doing - is to have the majority of people working inside cross-functional teams aligned to the stream of change (what we call Stream-aligned teams). These teams have end-to-end responsibility for the implementation of a change or piece of new functionality, including supporting the new software in Production/Live.

By removing the hand-offs and silos, we’re able to set up the organization for a fast flow of change aligned to business-relevant areas. Of course, this doesn’t automatically happen - we cover some other requirements in the book.

InfoQ: How does the reverse Conway maneuver work?

Pais & Skelton: The Reverse Conway maneuver (or Inverse Conway) is an approach to organization optimization - popularised by people like James Lewis of ThoughtWorks and Tobbe Gyllebring - that seeks to match the communication structure of the organization with the actual or desired software architecture being built by the organization. In this way, the organization is no longer fighting against the homomorphic (self-similar) mirroring force of Conway’s Law. As software expert Ruth Malan says, "The organizational divides are going to drive the true seams in the system".

An organization that employs the Reverse Conway approach first determines the most effective software architecture for fast flow, probably based on separate business bounded contexts, and probably using an architecture based on small software services. Then the organization begins to structure people into teams whose communication paths match the intended software architecture, ideally one service or one business domain at a time (but possibly more suddenly).

The Reverse Conway maneuver does not guarantee effective software delivery, but it does result in more time and effort spent on meeting business goals rather than pushing against the communication mismatches between organization and software.

InfoQ: How can we encourage team members to develop a team-first mindset?

Manuel Pais & Matthew Skelton: It’s surprising how many organizations claim to have teams but actually have just collections of people with the same manager. These days, we have plenty of techniques to help people to work as a team:

• Pair programming - helps develop close 1-to-1 working
• Mob programming - helps to develop whole-team approaches to problems
• Kanban and WIP limits - help people to focus on whole-team delivery
• Team charters - help people to get into the habit of behaving in ways that benefit the whole team
• Coaching - helps people adopt and reinforce newly-learnt behaviors for things like retrospectives and discussions

Some team-level behaviors need to be encouraged by the Human Resources (HR) department. For instance, instead of assigning a yearly training budget to each individual, assign a training budget to an entire team. In this way, if one member of the team is particularly good at attending conferences and reporting back, the team can choose to send that person again and again because the team as a whole benefits.

In the Team Topologies book we also characterise some team behavior patterns suitable for different types of teams. We did this because we found in our consulting work that many people simply did not have the experience or context to know how their team should interact with other teams. The patterns in the book provide some templates for a team-first mindset.

InfoQ: How do the four fundamental team topologies look?

Pais & Skelton: The four fundamental team types are (we believe) the only types of teams needed for modern software delivery optimized for fast flow:

• Stream-aligned team: cross-functional team responsible for a stream of changes aligned to (usually) part of the business domain. This team owns the end-to-end delivery and running of the software service it builds.
• Enabling team: a team that enables Stream-aligned teams to increase its capabilities for a period of time or to become familiar with a new technology or approach.
• Complicated subsystem team: an optional team of skilled specialists where these skills are too difficult to place into Stream-aligned teams.
• Platform team: responsible for building and running a compelling platform that accelerates and simplifies software delivery for Stream-aligned teams. The platform is a group itself probably composed of internal Stream-aligned teams and a lower-level platform - it’s fractal!

In fact, only the Stream-aligned team is really necessary - the other team types effectively support the Stream-aligned teams. In practice, within large organizations you’ll see all four kinds of team simultaneously.

A key point is that teams should be long-lived, not created and disbanded after just a few weeks. True team performance far exceeds the performance of groups of individuals, but it takes time for team dynamics to become optimal (several weeks or months usually).

InfoQ: What's your advice regarding architects and architecture teams?

Pais & Skelton: The days of separate teams of software architects and systems architects should be behind us now, thankfully. The idea of designing a software system apart from the daily feedback received by software teams feels anachronistic. However, there are still important roles for people with the bigger-picture architect aptitude:

1. At the team level, experienced architects can be part of Enabling teams to help Stream-aligned teams to increase their architecture awareness and address operability, testability, and so on. In this role, architects will also feed information into Platform teams because they will detect gaps in capabilities within Stream teams and within the platform so are ideally placed to help bridge those gaps.
2. At the enterprise level, architects can help to shape the team interactions and organization design in a way that takes Conway’s Law into account, and therefore avoiding a mismatch between organization communication and intended software architecture.  

When you understand the implications of Conway’s Law, you realise that anyone who has influence over the organization design is also acting as a software architect. Do you want HR people or managers designing your software architecture by accident? Probably not! So architects have a crucial role to play if they address not only the technical architecture, but also the human and social architecture.

About the Book Authors

Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Head of consulting at Conflux (confluxdigital.net), he specialises in continuous delivery, operability and organisation dynamics for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software. He holds university degrees in Computer Science & Cybernetics, Neuroscience, and Music, and is a Chartered Engineer (CEng). Skelton can be found on Twitter and Linkedin.

Manuel Pais is a DevOps and delivery coach and consultant, focused on teams and flow first. He helps organizations adopt test automation and continuous delivery, as well as understand DevOps from both technical and human perspectives. Pais has been in the industry since 2000, having worked in Belgium, Portugal, Spain, and the UK. Pais is the co-author of Team Guide to Software Releasability (2018). Pais holds a BSc in Computer Science from the Instituto Superior Técnico and an MSc in Software Engineering from Carnegie Mellon University. Pais can be found on Twitter and Linkedin.