Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

Teams are always works in progress, but they are also your best shot at delivering value continuously and sustainably by aligning them with the business.

Much like a software architecture document gets outdated as soon as the actual software development starts, an org chart is always out of sync with reality.

Fast flow requires restricting communication between teams. Team collaboration is important for gray areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead.

Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.

an organization should never assign work to individuals; only to teams.

Dunbar found fifteen to be the limit of the number of people one person can trust deeply.5 From those, only around five people can be known and trusted closely.6

If we stress the team by giving it responsibility for part of the system that is beyond its cognitive load capacity, it ceases to act like a high-performing unit and starts to behave like a loosely associated group of individuals, each trying to accomplish their individual tasks without the space to consider if those are in the team’s best interest.

A simple and quick way to assess cognitive load is to ask the team, in a non-judgmental way: “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?”

The assumption that the software-development process has little or nothing to learn from how the software runs in the live environment is fundamentally flawed.

Non-blocking dependencies often take the form of self-service capabilities

three different categories of dependency: knowledge, task, and resource dependencies.

A thick platform might consist of the combination of several inner platform teams providing a myriad of services. A thin platform could simply be a layer on top of a vendor-provided solution.

Interestingly, unlike other organizations, we have never embedded Ops people in Dev squads. Instead, we have an Ops “squad buddy” for each Dev squad, a person from Ops who regularly works with specific Dev squads, attending their standups and providing the “glue” between Dev and Ops.

Sometimes a particular area is so complicated that a dedicated complicated-subsystem team is needed (see earlier in this chapter). But such teams never sit in the flow of change; instead, they provide services to stream-aligned teams.

In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse.

software developers love building platforms and, without strong product management input, will create a bigger platform than needed.

collaboration, X-as-a-Service, and facilitating.

Intermittent collaboration found better solutions than constant interaction.

The collaboration interaction mode is good for rapid discovery of new things, because it avoids costly hand-offs between teams.

“someone who claims to be an Architect needs both technical and social skills. . . . They also need a remit that is broader than pure technology—they need to have a say in business strategies, organizational structures, and personnel issues, i.e., they need to be a manager too.

Unnecessary collaboration is particularly expensive, especially as it can mask or hide deficiencies in underlying platforms or capabilities.

This reinforcing cycle of specialization is a local optimization (“get this request delivered quickly”) that can negatively affect the team’s overall flow of work when planning gets dictated by “who knows what” rather than “what’s the highest priority work we need to do now.”

Systems thinking: optimize for fast flow across the whole organization, not just in small parts

Increasingly, software is less of a “product for” and more of an “ongoing conversation with” users.