I read 『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』マシュー・スケルトン（著）、マニュエル・パイス（著） (“Team Topologies: Organizing Business and Technology Teams for Fast Flow” by Matthew Skelton and Manuel Pais), so I’ll introduce the insights I gained from this book.

Background: Want to Implement Reverse Conway's Law

I was interested in Ryuzee さんの訳者ということで気になっていた『チームトポロジー』 (“Team Topologies” because Ryuzee was the translator), and after seeing reviews and impressions online after completion, I felt this was essential reading for implementing reverse Conway’s law, so I read this book.

Below are quotes and notes from the most impressive parts:

PART I Teams as the Means of Delivery

Chapter 3 Team-First Thinking

Appropriate Boundaries Reduce Cognitive Load

Restrict Responsibility Scope to Match Team Cognitive Load

One of the most under-recognized factors in increasing friction in modern software delivery is the ever-increasing size and complexity of codebases that teams handle. This brings unlimited cognitive load to teams.

? The problem of cognitive load.

Limit the Types of Domains Teams Handle

There is no definitive answer to the question "What's the appropriate number and type of domains for a team?" Domains are not fixed, and team cognitive capacity changes over time. However, using relative domain complexity to make educated guesses can help determine team responsibility boundaries.

The first rule of thumb is to assign each domain to a single team. If a domain is too large for one team, rather than dividing the team's scope of responsibility within the domain, consider whether the domain can be divided into subdomains with teams assigned to each subdomain.

The second rule of thumb is that a single team following the golden rule of 7-9 people should handle two or three simple domains. Such domains are often highly procedural and can be responded to mechanically, making the cost of context switching between domains more acceptable.

The third rule of thumb is that teams assigned complex domains should not be assigned any other domains, even simple ones. This is due to the high cost of interrupting work flow (complex problem solving requires time and focus) and prioritization (simple and predictable problems are often addressed immediately, resulting in delays in tackling the most important complex problems for business).

The final rule of thumb is to avoid assigning two complicated domains to a team.

Design "Team APIs" to Promote Team Interactions

Define "Team APIs" Including Code, Documentation, and User Experience

Stable, long-lasting teams having ownership of specific parts of software systems can build stable team APIs. APIs that surround the team. An API is a specification that describes how programs interact with software. Here we extended the idea of APIs to interactions with teams.

PART II Team Topologies That Work for Flow

Chapter 5 The Four Fundamental Team Types

Stream-Aligned Teams

CASE STUDY Amazon's Strictly Independent Service Teams

By CEO Jeff Bezos's mandate, teams responsible for Amazon services and applications were required to be truly independent. This ensured, through Conway's law, that they were also independent at the team group level.

? Successful example of Conway’s law

Amazon is also known for limiting software team size to what can be fed with two pizzas.

? Two pizza rule ??

Around 2002, Jeff Bezos set clear rules for team organization in Amazon's engineering department:

・Each team takes complete responsibility for developing and operating the services they handle (services can be considered single or multiple functions of Amazon.com or AWS products) ・Each service is provided through APIs regardless of internal or external use. Teams must not interfere with other teams’ services, architecture, or technologies used, and must not set any assumptions

? AWS as a model case

Following the principle made famous by Amazon CTO Werner Vogels: "you build it, you run it," service teams (internal designation) must be cross-functional and capable of managing, specifying, designing, developing, testing, and operating their services themselves (including infrastructure provisioning and customer support).

Capabilities Stream-Aligned Teams Should Have

Generally, stream-aligned teams need to have the full set of capabilities needed to progress work from initial requirement exploration to production operation. Such capabilities include (but are not limited to):

・Application security ・Business viability analysis and operational continuity analysis ・Design and architecture ・Development and coding ・Infrastructure and operability ・Metrics and monitoring ・Product management and ownership ・Testing and QA ・User experience (UX)

? List of stream-aligned team skills

Platform Teams

The purpose of platform teams is to enable stream-aligned teams to deliver work autonomously. Stream-aligned teams have full ownership including development, operation, and modification of production applications. Platform teams reduce cognitive load by providing internal services, eliminating the need for stream-aligned teams to develop lower-level services.

Platform team knowledge is provided not as lengthy user manuals but in self-service form as web portals or programmable APIs that stream-aligned teams can easily utilize. "Ease of use" is fundamental to platform adoption. It also shows that platform teams need to treat the services they provide as products that are fit for purpose, reliable, and user-friendly, regardless of whether customers are external or internal.

Good Platforms Are "Just the Right Size"

■Thinnest Viable Platform

In any case, we should aim for a Thinnest Viable Platform (TVP). Platforms must not become constraints. Alan Kelly says "Software developers like to build platforms. Without solid information from product management, they develop platforms larger than necessary." TVP strikes the delicate balance between keeping platforms small and enabling platforms to simplify and accelerate development teams' software delivery.

※ TVP stands for Thinnest Viable Platform

? TVP

■Appropriate Platforms with Both Consistency and Persuasiveness

An extremely common pitfall in platform development is disconnecting from team needs. Platform teams need to focus on user experience (UX), especially developer experience (DevEx).

? Focus on UX, DevEx

PART III Evolving Team Interactions for Innovation and Rapid Delivery

Chapter 7 Team Interaction Modes

Three Team Interaction Modes

■X-as-a-Service: Clear Responsibilities Make Delivery Predictable, but Excellent Product Management is Required

? After building a platform, for initial implementation projects, it seems good to proceed with development in this mode with stream-aligned teams.

Chapter 9 Next-Generation Digital Operating Model

Four Team Types and Three Interaction Modes

Only four team types are needed for software system development and operation. Other team types can cause significant harm to organizations. The four fundamental team types are:

・Stream-aligned teams: Teams arranged along the main business change flow. Cross-functional and capable of delivering available features without waiting for other teams

・Platform teams: Teams handling underlying platforms that help stream-aligned teams deliver. Platforms simplify directly complex technologies and reduce cognitive load for using teams

・Enabling teams: Help other teams introduce or change software during transition or learning periods

・Complicated-subsystem teams: Teams for handling subsystems too complex for ordinary stream-aligned teams or platform teams. Formed only when truly necessary

? Four fundamental team types

Only combinations of these teams are needed for effective software delivery with fast flow. However, interaction modes between the four fundamental team types are also extremely important for understanding what effective software delivery is and achieving it.

・Collaboration mode: Two teams share goals and work together, especially while exploring new technologies or approaches. This overhead is valuable for accelerating learning pace

・X-as-a-Service mode: One team uses something provided by another team (APIs, tools, entire software products, etc.). Collaboration is minimized

・Facilitation mode: One team (usually an enabling team) facilitates other teams to promote learning and application of new approaches

Team interactions outside these three interaction modes are wasteful and indicate that team responsibility boundaries and purposes are not properly assigned.

? Three interaction modes

That’s all about wanting to practice team topology organizational theory. That’s all from the Gemba.