KEY TAKEAWAYS

CHAPTER 4

• Ad hoc or constantly changing team design slows down software delivery.
• There is no single definitive team topology but several inadequate topologies for any one organization.
• Technical and cultural maturity, org scale, and engineering discipline are critical aspects when considering which topology to adopt.
• In particular, the feature-team/product-team pattern is powerful but only works with a supportive surrounding environment.
• Splitting a team’s responsibilities can break down silos and empower other teams.

CHAPTER 5

• The four fundamental team topologies simplify modern software team interactions.
• Mapping common industry team types to the fundamental topologies sets up organizations for success, removing gray areas of ownership and overloaded/underloaded teams.
• The main topology is (business) stream-aligned; all other topologies support this type.
• The other topologies are enabling, complicated-subsystems, and platform.
• The topologies are often “fractal” (self-similar) at large scale: teams of teams.

CHAPTER 6

• Choose software boundaries using a team-first approach.
• Beware of hidden monoliths and coupling in the software-delivery chain.
• Use software boundaries defined by business-domain bounded contexts.
• Consider alternative software boundaries when necessary and suitable.