#8 Notes for: Team Topologies, Chapter 5— The Four Fundamental Team Topologies

This post is part of my 30-day note-taking experiment. The notes are my work, the original piece is obviously not.

Summary

In software development, all works can be expressed, by categorizing the teams into the following fundamental types: stream-aligned, platform, enabling, and complicated sub-system. Stream-aligned teams deliver business value and as such, they are both the most frequent and the most important. The rest of the teams are there to support and enable the stream-aligned teams and to reduce their cognitive load.

You can vastly simplify and focus teams by aligning them to these four archetypes. For bigger products, you can also use a fractal of these. For example, the platform team itself is composed of stream aligned at platforms teams (where the customers are the rest of the developers in the organization).

Key Takeaways

The four archetypes

• stream-aligned team
• platform team
• enabling team
• complicated sub-system team

There is no “Ops” team, each team is capable and responsible for operating its products.

Stream-aligned teams

Each team is aligned to a stream of work. It is both the most frequent and most important team type since they’re creating business value. This team is empowered to deliver customer value end-to-end and quickly, and without handover to another team. To achieve this each stream-aligned team requires a wide set of capabilities, and they mostly consist of generalists plus a few specialists.

Expected behaviors

• consistent delivery, with ideally 0 handoff
• ability to experiment, but also course-correct quickly based on feedback
• they must have enough time and cognitive capacity to address and improve and iterate on code quality.
• they should be on the path to achieving Dan Pink’s “autonomy, mastery, purpose”

Enabling teams

Enabling teams are composed of specialists and their goal is to collaborate with and help stream-aligned teams. It’s important that they guide, not execute to avoid becoming an ivory tower of knowledge. Typical enabling team areas: continuous-delivery best practices, security, or test-automation. Again: they’re not silos, they work with the team for a short amount of time, to enable them.

Expected behaviors

• proactively seeks to understand what stream-aligned teams will need and stay ahead of the curve in new approaches, tooling, and practices in their area of expertise
• keeps up with and delivers both good (“a new V8 update will make our web app a lot faster”) and bad news (“ the JS lib we’re using getting deprecated”)
• enables and curates team learning, facilitates knowledge sharing

Complicated-Subsystem Team

A complicated-subsystem team is responsible for building and maintaining a system that is so complex that most of the team members in the team have to heavily specialize. It wouldn’t be cost-effective (or possible) to embed the knowledge in the stream-aligned teams. These teams are very rare, and you most likely only need zero or one. Good examples for these subsystems are working on video-codecs, real-time trade reconciliation, or working with mathematical models. The decision to have them is driven by team cognitive load, not by the perceived opportunity to share components.

Expected behaviors

• their primary goal is to make the stream-aligned team’s work easier
• they use different interactions modes for giving help for different stage of the development (collaboration at the beginning, X-as-a-service for later in the lifecycle)
• they correctly prioritize the demands of various stream-aligned teams, based on the business’ goals

Platform teams

The platform team provides cross-cutting, enabling services that allow the stream-aligned teams to stay autonomous. The platform should be considered an internal product, with the rest of the developers as customers. It has to put “ease of use” and DevEx on the forefront and use proven software delivery practices to deliver this internal product. In a large organization, the platform itself will need to be broken into multiple teams. In that case, you should create a fractal of teams, where the internal platform team also has stream-aligned teams, and maybe even an internal platform team.

Expected behaviors

• collaborate strongly with stream aligned teams, by relying on fast prototyping and quickly gathering feedback on what works
• focus on “ease of use” (UX), developer experience (DevEx), and reliability for their services
• they use the services they provide internally, use best practices, and generally lead by example
• they make sure the platform is there to serve the needs of the other teams, not the other way around
• make it easy for dev teams, to get things done, and do them the right way

By making sure we have loosely coupled, modular groups that conform to these team patterns, we can avoid silos. Furthermore breaking up and re-organizing our existing teams into these archetypes can give them the focus that is needed for rapid and safe flow.

My thoughts

I have certainly seen parts of this work very well. We even had teams that were pretty close to the responsibilities of the 4 Team Topologies teams. I think the idea of having a platform team consists of other internal product stream-aligned teams are really good, and I wish I had thought of that when leading an internal tooling team in my previous job.