Start With Teams

Have you ever read a book that made you laugh, cry, and kept you on the edge of your seat all at the same time? Has a non-fiction book ever done that? 

I recently finished reading Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manual Pais. The timing of this book's release was remarkable. It was the just book I needed at the moment I needed it. In some ways it validated my preconceived beliefs, and in other ways it challenged them. Important books, I think, are supposed to do that. The thesis of the book is that teams--not individual contributors or even executive decision makers--are the fundamental units of value delivery. Therefore, team structure and communication patterns are among the most important considerations of a value delivery system. 

By now, nearly everyone in tech has heard of Conway's Law. There has, in recent years, been a resurgence of interest in this somewhat obscure article that was rejected by Harvard Business Review (and published in Datamation). Sometimes, even when leading institutions laugh at you, you're simply right, and even though Mel Conway published this in the early days of software engineering, it applies profoundly in the modern cloud and DevOps world. Team Topologies begins by showing how Conway's Law is the foundation upon which good organizational structure, team design, and team communication patterns rest. It teaches a systems view of software architecture that includes teams. It teaches us that the ways in which teams communicate reflect how the software components built by those teams interface with each other. If you have a separate database team, middleware team, and front-end team that builds their features in silos, you are likely to end up with three discrete components of an application that work fine in isolation, but don't work as a single functioning system. Considering team design should therefore be the first consideration of any system architecture. Having this systems view of architecture means that we need to take a step back and consider the whole system.

What is a system? For the answer, we can turn to perhaps the greatest modern systems thinker (researcher, professor, practitioner, "father of quality," etc.) W. Edwards Deming:

A system is an interconnected complex of functionally related components, divisions, teams, platforms, whatever you call them, that work together to try to accomplish the aim of the system.

Deming, W. Edwards, and Joyce Nilsson. Orsini. The Essential Deming: Leadership Principles from the Father of Quality Management. New York: McGraw-Hill, 2013.

Notice that Deming includes teams that work together in his definition of a system. For Deming, people are an essential part of a system, and must understand and find joy in their contribution to the system. Team Topologies helps the reader understand what types of teams work in a value delivery system, how those teams can have visible, measurable contributions to the whole system, and how the organization of teams directly correlates to the success of the system. There are four--and only four--types of teams, and three team interaction modes.

Types of Teams

1. Stream-aligned teams

2. Enabling teams

3. Complicated subsystem teams

4. Platform teams

Stream-aligned teams

Stream aligned teams are aligned to a value-stream. That is, they are aligned to something that delivers business value: a single product, feature-set, service, or business capability. In some cases, these might be called "product teams." In a large software development organization, multiple stream-aligned teams work in concert to deliver software, each one working on their component, capability, or feature-set in open collaboration with other stream-aligned teams. Every other type of team exists to support stream-aligned teams, because stream aligned teams keep us in business--they make money.

Complicated subsystem teams

Complicated subsystems are offered "as a service" through APIs and other integrations. The teams that run complicated subsystems are experts and specialists in that system. Complicated subsystems are almost always internal products; they aren't feature-sets of the external product or service that the organization delivers. Stream-aligned teams use complicated subsystems to build the product or service. Consider storage or network systems offered as internal products that the stream-aligned teams use to deliver value. 

Enabling teams

Enabling teams exist across all other types of teams. They are made up of selected members from all other teams, and they exist to support stream-aligned teams' experimentation and education. Enabling teams are often referred to as communities of practice, guilds, or councils.

Such teams cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.

Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. Portland, OR: IT Revolution, 2019.

Platform teams

All stable structures require foundations. From the stone foundations of the smallest one-story homes, to the bedrock embedded piles that support huge superstructures, without a solid foundation, the structure built upon it will crumble to the ground. A platform is the foundation of value delivery. It isn’t always a physical thing, and in fact, we should seek out what the book calls a "minimum viable platform." Quoted in the book is Evan Bottcher who describes platforms like this:

A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.

Notice that a platform offers self-service APIs, tools, service, knowledge, and support. This is where platforms are significantly different than complicated subsystems. 

What about SRE teams?

The importance of SRE teams should not be underestimated. For large products with many users, SRE teams work alongside stream-aligned teams to measure, support, automate, and improve products. They are a stream-aligned team. Team Topologies describes SRE teams like this:

SRE teams have a strong relationship with one or more application-development teams, a kind of affinity. In this respect, we can see the SRE model as a special kind of stream-aligned team.

What About DevOps Teams?

One of the sources for this book is DevOps Topologies, which describes different ways to incorporate DevOps teams into existing development and operations teams. DevOps topologies describes nine different ways to use DevOps teams, and the “promised land” is to have development and operations work together in “smooth collaboration between Dev teams and Ops teams, each specializing where needed, but also sharing where needed.” This is the goal that organizations should strive for.

In my opinion, if you have a long-term DevOps team, you're doing it wrong. DevOps is not meant to be a team or a job title. DevOps is a philosophy; it is a way of life. DevOps exists within all four of these team types. You'll find job titles that help facilitate a DevOps culture, like release engineer and automation architect among others, but these jobs exist within one of the four existing team topologies. I believe that a DevOps team can help an organization grow into one of the four team types, but that it should be a temporary enabling team.

Each type of team interacts in specific ways to other types of teams. There are three modes of team interaction:

Team Interaction Modes

1. Collaboration

2. As-a-service

3. Facilitating

Collaboration

In this mode, teams with different expertise work closely together to solve a problem or build a product or service. This mode allows for trial and error and joint problem solving among teams and people with a diverse set of expertise. In collaboration, there is no hand-off to another team-–all involved teams are working on the same problem. This is the default mode for stream-aligned teams who work together to deliver a product or service.

As-a-service

In this mode, teams make use of the expertise of another team. There is still collaboration, but it looks more like a consulting partnership rather than collaboration among teams who are each building part of the whole. In fact, as the book says, these services "just work," and stream-aligned teams use the services offered to build their product or service. This is the default mode of complicated subsystem teams.

Facilitating

In the facilitating mode, teams that are made up of members of all other team types come together to experiment, learn, and try new ways of doing things. In facilitating mode, teams fill the skills and tooling gap that can exist in stream-aligned teams. This is the default mode of enabling teams.

Theory is Fine, but Can This be Applied in Real Life?

Team Topologies is packed with case studies--real life organizations who have successfully implemented these team types. But even with these examples, the burning question for me was "but how can a regular person implement this in a regular, real life organization?"

To implement these types of teams in your organization, I recommend the following:

1. Find out where these teams *already* exist within your organization. You might, for example, have clear stream-aligned teams but call them something different (as I said above, these are often called "product teams").

2. Try a "soft" organization: start small and don't seek to officially change the org chart. Big disruptions can cause a lot of anxiety and resistance. Bring people loosely together in these four team types, and experiment with what works for you and your people. Start getting those glorious *small wins*, and then you have evidence that a larger organizational change would deliver value more quickly than ever before.

In my experience tech and business books exist on a spectrum of terrible to amazing. Some are difficult to get through and they offer little of value, some are worth reading and contain a few nuggets of goodness and wisdom, and others-the really rare ones-knock you off of your feat; they challenge your beliefs and make you think in new ways. For me, Team Topologies was one of those rare exciting and important books. 

(Cross-posted at dev.to/adam_frisbee and LinkedIn)