Skelton and Pais (2019) provide a practical framework for organizing technology teams to optimize for fast flow of change. The core thesis: organizational structure determines software architecture (Conway’s Law), and intentionally designing team structures and interaction patterns produces better software outcomes than reorganizing in response to problems. The book catalogs four fundamental team types and three interaction modes.
Key Frameworks
Four Fundamental Team Types
Team Type
Purpose
Example
Stream-aligned
Delivers value along a single stream of work (product, service, feature set)
Product team owning checkout flow
Platform
Provides internal services to reduce cognitive load on stream-aligned teams
Internal developer platform
Enabling
Helps other teams adopt new capabilities
DevOps coaching team, SRE advisors
Complicated-subsystem
Owns a subsystem requiring specialist knowledge
ML model team, video codec team
Three Interaction Modes
Mode
When
Duration
Collaboration
Teams work closely together on a shared goal
Temporary — high bandwidth, high cost
X-as-a-Service
One team provides a service with clear API
Steady state — low bandwidth, low cost
Facilitating
One team helps another adopt a new capability
Temporary — enabling team assists
Conway’s Law (Inverse Maneuver)
Rather than letting architecture emerge from existing team structures, intentionally design team structures that produce the desired architecture. Team cognitive load is the primary constraint — teams can only effectively own what they can understand.
Team-First Thinking
Keep teams small (5-9 people, “two-pizza” size)
Minimize inter-team dependencies to reduce coordination costs
Match team boundaries to software boundaries
Evolve team topologies over time as context changes
Chapter Themes
Section
Key Insight
Conway’s Law
Organization structure constrains solution design
Team-First
Cognitive load is the limiting factor, not headcount
Team Types
Four types cover all organizational needs
Interaction Modes
Three modes govern how teams relate
Evolution
Topologies must change as the organization and software evolve
Actionable Takeaways
Optimize for flow of change, not resource utilization — stream-aligned teams deliver value directly
Platform teams reduce cognitive load by providing self-service capabilities — they are not shared-services teams
Interaction modes should be intentionally chosen and time-bounded — collaboration is expensive
Conway’s Law is real — if you want decoupled software, build decoupled teams
Team cognitive load is the primary design constraint — if a team cannot understand its domain, the boundary is wrong
Related
accelerate-devops — the research evidence for capabilities that Team Topologies operationalizes
elegant-puzzle — engineering management systems for the teams described here
creativity-inc — creative leadership principles complementing team autonomy