A new bible for engineering management?

Maybe not, but I'm convinced that Team Topologies will eventually end up next to Domain-Driven Design, Accelerate, and even The Mythical Man Month. Team Topologies is a practical, step-by-step, adaptive model for organizational design and team interactions. What DDD does for business modelling, Team Topologies does for team modelling.

I'm not the only one who seems to like it: according to Book Authority, it currently ranks #3 on Best Product Management Books of All Time and it debuted in Best New Management Books 2021. It was recommended for consideration by Gene Kim, one of the authors of the  "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations", and it very much follows in the tradition of combining data and actionable insight for organization value stream optimization.  Wow, how's that for some business jargon!

On a different tack, here's a nice quote from a Greg Burrell:

“When your teams encounter friction and bottlenecks it can be tempting to throw more people, tooling, and process at the problem. Your solution likely lies in a new team topology. But what should that look like? Team Topologies provides a much-needed framework for evaluating and optimizing team organization for increased flow. Teams that have the right size, the right boundaries, and the right level of communication are poised to deliver value to the company and satisfaction to the team members. Team Topologies combines a methodical approach with real-world case studies to unlock the full potential of your tech teams.” -- Greg Burrell, Senior Reliability Engineer at Netflix

The theory of Team Topologies starts with the following assumptions:

• Dunbar's number: There's a cognitive limit to the number of people with whom one can maintain stable social relationships.
• Conway's law: That organizations design systems which mirror their own communication structure.
• Cognitive load: Software that is "too big for our heads" works against organizational agility.

Teams. Team Topologies asserts that teams are always independent of reporting structure. It doesn't matter if you are currently calling your whole department of 40 engineers a team. It's not a team. It's a large group. Specifically, a team is a small group of 5-9 people with a single mission, kept together for an extended period of time. They learn to work together, they share information, they improve on how they work together, and distractions are minimized.

Cognitive Load. Data has shown that modern software teams have too many dependencies, and are expected to do too many things autonomously, without the skillsets or required knowledge to do the job effectively. What is missing is balance between autonomous teams and support teams that can provide the right types of abstractions for the platform of software delivery. We want to limit the size of software services to the cognitive load that the team can handle.

Fast Flow of Change. Teams that own business concerns need to be able to adapt quickly to new information. When teams are responsible for the runtime success of software, they build in the correct feedback mechanisms. The incentives are aligned to prioritize operability and reliability when software is both being planned and built. This is increasingly relevant in a context of a live distributed system. The story is only beginning when the system goes live –

Measurement of Velocity. Team Topologies very much builds on the wisdom of "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations". We can measure the velocity of software using the following four key metrics:

• lead time
• deployment frequency
• mean time to restore (MTTR)
• change fail percentage

Team Topologies: Matthew Skelton and Manuel Pais identify four fundamental team types and three team interaction patterns. These types and patterns represent different modes of activity that fit the changing needs of the organization.

• Stream-aligned team: this maps well to a product team which needs to have a clear picture of the business domain. For these teams to be successful they need to know how the product must adapt over time, and they also must own the runtime operation of the product.
• Enabling team: this maps well for temporarily shoring up weaknesses on a product team, either through training or addressing technical debt.
• Complicated Subsystem team: this reduces the cognitive load of the stream-aligned team, enabling them to focus on delivering value.
• Platform team: this maps well to a DevOps team, responsible for infrastructure and environments.

Organizations want to optimize for as many stream aligned teams as possible, as these are the teams with the most direct relationship to revenue. As the org grows the need for the additional fundamental team types will emerge, and this is evident by a drop in their velocity as they scramble with growing complexity and dependencies.

In many organizations, teams do not understand how or why they should interact with other teams. To reduce confusion and to bring clarity and expectation to team interactions, the following three core interaction modes are identified:

• Facilitating: an enabling team that facilitates process of another team.
• Collaboration: working together can briefly raise the cognitive load, but ensures the right thing is built for the audience at the right time.
• X-as-a-service: clear expectations around providing a service or consuming a service.

Team topologies is how to organize people in an organization for fast flow of change, which enables both velocity of delivery as well as fast response in live operations.

Domain Driven Design: DDD is how to model business operations into separate contexts and value streams in a meaningful way that enables sensible, reliable, and fault tolerant software systems.

Reverse Conway manuever. If a desired software architecture can be determined, then the teams should be set up in a way that supports the designed architecture. The desired software architecture can be influenced by DDD modelling, or driven by change velocity or risk, whatever the preference. The important point is that the organization will evolve over time, and therefore team types and their interaction modes will change as well.

Organization as an organism. With Team topologies and interactions, you give yourself the space to evolve over time. Adopting the tools means that an organizational landscape is achieved, and can therefore be surveyed. Are we doing enough, in terms of up-skilling and supporting existing teams as external pressures change? Can we identity what kinds of skills are missing, or what kinds of dependencies between teams have become sources of friction? These are the new concerns of engineering managers – to stay vigilant, and continuously think about how do we improve where we are today, and how to enable change in the future.