Team Topologies: Organizing Business and Technology Teams for Fast Flow

We consider the team to be the smallest entity of delivery within the organization.

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.

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist

Around five people—limit of people with whom we can hold close personal relationships and working memory Around fifteen people—limit of people with whom we can experience deep trust Around fifty people—limit of people with whom we can have mutual trust Around 150 people—limit of people whose capabilities we can remember

apply the reverse Conway maneuver: designing teams to match the desired architecture.

Most teams in a flow-optimized organization should be long-lived, multi-disciplined, stream-aligned teams.

Systems thinking focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it. Then

Teams are generally small, stable, and long lived, allowing team members the time and space to develop their working patterns and team dynamics.

Instead, teams should view themselves as stewards or caretakers as opposed to private owners. Think of code as gardening, not policing.

Teams should be stable but not static, changing only occasionally and when necessary.