Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

Q&A on the Book Team Topologies

Key Takeaways

Static team structures are no longer enough for software delivery success

The Team Topologies book is intended for a wide range of people within IT and outside IT; anyone involved in shaping teams and organizations

Traditional organization designs that have functional silos impede fast flow of change - we need new flow-oriented approaches like those in the Team Topologies book

The Reverse Conway Maneuver can help to avoid a mismatch between organization architecture and software architecture, a major source of friction

Separate “architect” silos are a thing of the past - modern software architects need to shape organization design as well as software design

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 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).

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:

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.

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.