Team Topologies: Organizing Business and Technology Teams for Fast Flow

When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.

Research has shown that the similarity of team mental models is a good predictor of team performance, meaning fewer mistakes, more coherent code, and more rapid delivery of outcomes.

The last heuristic is to avoid a single team responsible for two complicated domains.

A further benefit of taking a team-first approach to software boundaries is that the team tends to easily develop a shared mental model of the software being worked on.

In a platform, the streams relate to services and products within the platform, which could be things like logging and monitoring services,

Dunbar found fifteen to be the limit of the number of people one person can trust deeply.

Team structures must match the required software architecture or risk producing unintended designs.

Splitting software can reduce the consistency between different parts of the software and can lead to accidental data duplication across multiple subsystems. The

By empowering teams, and treating them as fundamental building blocks, individuals inside those teams move closer together to act as a team rather than just a group of people. On the other hand, by explicitly agreeing on interaction modes with other teams, expectations on behaviors become clearer and inter-team trust grows.