Key Takeaways from “High‑Performance Team Patterns” – Designing Effective Team Topologies for Software Delivery

1. Teams Are the Most Effective Software Delivery Unit, Not Individuals

Traditional org charts fail to reflect real communication patterns; a more practical diagram is needed to show expected and actual interactions between individuals and teams. Optimizing only part of an organization ignores upstream and downstream impacts, making local optimizations ineffective for end‑to‑end value delivery.

Conway’s Law states that if system architecture and organization structure misalign, the organization wins, leading to siloed functional teams that hinder end‑to‑end workflows. The architecture design order should be business → technology → organization, while implementation order is organization → business → technology.

Applying the Dunbar number to control team growth ensures teams stay within cognitive load limits, progressing from ~5‑8 members to 15, 50, 150, 500, etc.

1.1 Problem

Standard org charts do not capture real communication; decisions based solely on them lead to partial optimizations that ignore the full value stream.

1.2 Solution – Small, Well‑Designed Teams Based on Conway’s Law and Dunbar Number

Teams should be formed according to business domain complexity rather than functional silos, with clear responsibilities and well‑defined APIs (both technical and non‑technical).

Assign each domain to a single team; split if the domain is too large.

A golden‑size team of 7‑9 members can handle two or three simple domains.

Do not overload a team with additional complex domains.

Avoid assigning two complex domains to one team.

Emphasize collective ownership: reward the team, not individuals, and foster diversity.

2. Designing Team Topology Around End‑to‑End Value Streams

2.1 What Is Team Topology?

Team topology is the conscious design of team structures, defining each team’s boundaries and responsibilities to support continuous flow.

Dependencies between teams fall into three categories: knowledge, task, and resource dependencies.

2.2 Four Basic Team Topologies

The four core topologies are:

Value‑Stream Team : Aligned to a business domain, responsible for a continuous flow of work, minimizing hand‑offs.

Enabling Team : Specialists who help other teams adopt new practices, tools, or technologies.

Complicated‑Subsystem Team : Owns complex, highly specialized subsystems (e.g., video encoding, facial‑recognition).

Platform Team : Provides internal services and APIs so value‑stream teams can focus on domain work.

2.3 Boundary‑Strategy for Team‑First Design

Clear team boundaries reduce friction; align subsystem boundaries with business domains using techniques like Domain‑Driven Design, while also considering change frequency, risk, and compliance.

3. Making Team Topology Dynamic

3.1 Interaction Modes

Three interaction patterns help keep team boundaries clear:

Collaboration : Close joint work, good for innovation but blurs boundaries.

Service (X‑as‑a‑Service) : One team provides a well‑defined service, reducing the need for deep collaboration.

Facilitation : Teams help each other by removing obstacles and providing guidance.

Typical mappings: value‑stream teams use collaboration or service mode; enabling teams use facilitation; complicated‑subsystem and platform teams use service mode.

3.2 Evolving the Topology

Team topologies should evolve when a team becomes too large, delivery cadence slows, or many services depend on a single underlying system.

4. Applying the Topology – Using Wardley Maps

Wardley Maps help visualize the evolution of components (genesis → custom → product → commodity) and align teams with the appropriate stage, allowing dynamic adjustments as systems mature.

5. Summary

Team topology is a powerful tool for designing high‑performance software delivery organizations, but it must be complemented by a healthy culture, solid engineering and financial practices, and a clear business vision.