Book Notes: Team Topologies: Organizing Business and Technology Teams for Fast Flow
Overview
This post contains my notes on the book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton, Manuel Pais, and Ruth Malan.
You can find the book on Amazon
I’ll be adding my notes to this post as I read through the book. The notes will be organized by chapter and will include key concepts, code examples, and any additional insights I find useful.
Chapter 1: The problem with org charts
Overview:
- Conway’s law: Software architecture and team structure are similar forces
- Team Topologies
- clarifies team purpose and responsibilities
- Humanistic approach to building software systems
There are 4 fundamental team types:
- Stream-aligned team
- Enabling team
- Complicated subsystem team
- Platform team
Team structures must match the desired software architecture.
Cognitive Load: The total amount of mental effort being used in the working memory.
When cognitive load exceeds a team’s capacity, it leads to burnout and reduced productivity.
Obstacles to fast flow:
- blockers
- disengaged teams
- pushing against conways law
- software too big for teams
- confusing org design
- team pulled in too many directions
- Painful re-orgs
Chapter 2: Conways Law and why it matters
Overview:
- Conway’s law: organizations design systems that mirror their communication structure
- organization constraints impact software architecture
- everyone communicating with everyone is not scaleable
- choose team structures that align with desired software architecture
- limiting communication paths improves flow
Team assignments are the first draft of the architecture.
For a safe rapid flow of change, team structures must align with the desired software architecture.
Not all communication and collaboration is good.
Repeated re-orgs damage team morale and productivity, create fiefdoms, and lead to loss of institutional knowledge.
Conways law is a fundamental principle that must be considered when designing both software systems and organizational structures.
Chapter 3: Team First Thinking
Overview:
- Teams are more effective than individuals for software delivery
- Multi-team groomings should follow Dunbars number
- Max cogntive load for a team should be less than the total cognitive load of its members
- Establish clear team boundaries and responsibilities
- For success, change the team working environment
Small long-lived teams are more effective than large short-lived teams. Smaller size creates better trust Needs of the team:
- Arrive for stand-ups on time
- Keep discussions and investigations on track
- encourage a focus on team goals
- unblock other team members
- mentor new or less experienced team members
- avoid “winning” arguments - explore options together
Limit the number and type of domains per team
- assign each domain to a single team
- single team should be able to accommodate 2-3 simple domains
- team responsible for a complex domain should not have any more domains assigned to them
- avoid a single team responsible for two complicated domains
Match software boundary size to team cognitive load Design Team APIs Facilitate team interactions to build trust Engineering Practices are foundational
Chapter 4: Static Team Topologies
Overview:
- constant change in team structures is detrimental
- critical considerations for team design
- Technical/Cultural maturity
- Org scale
- Engineering discipline
- feature team/product team works in a supportive environment
Anti-patterns:
- Ad Hoc Teams
- Shuffling team members
Design For Flow Change
- low friction software delivery
- Spotify Model
- squads
- tribes are collection of squads
- testers across squads are a chapter
Shape team intercommunication to enable flow and sensing
- organization optimized for flow of change avoids transition handoffs
DevOps and the DevOps Topologies
Successful Team Patterns
- Feature Teams require high engineering maturity and trust
- Product teams Need a support system
- Cloud teams don’t create application infrastructure
- SRE makes sense at scale
Considerations when choosing team topologies
- Technical/Cultural Maturity
- Organization Size, Software Scale, Engineering Maturity
- Split responsibilities to break down silos
- Dependencies and wait times between teams
Chapter 5: The Four Fundamental Team Topologies
Stream-Aligned Teams
- continuous flow of work aligned to a business domain or organizational capability
- aligned to a single, valuable stream of work
Could be:
- product or service
- single set of features
- single user journey
- single user persona Different Streams:
- specific customer
- business-area
- geography
- product
- user-persona funded:
- long-term
- sustainable
- no handoffs to other teams
Capabilities
- App Security
- Commercial
- Design/Architecture
- Development/Coding
- Infra/Operation
- Metrics/Monitoring
- Product management and ownership
- Testing/quality
- UX
Stream-Aligned naming incorporates the sense of flow
Behaviors:
- produce steady flow of work
- course correct based on feedback
- learn and adapt
- zero handoffs
- evaluated on sustainable flow
- time and space for quality
- reaches out to fundamental-topologies teams
- Goal: autonomy, mastery, purpose
Enabling Teams
- Composed of specialists in a given technical domain and bridge capability gap
Behaviors:
- seek to understand need of stream-aligned teams
- stay’s on top of developments in their domain
- messenger of both good news and bad news
- proxy for services (internal/external)
- promotes learning
Complicated Subsystem Teams
- responsible for areas that require specialized knowledge and expertise
Behaviors
- mindful of current stage of development
- collaborates closely with stream-aligned teams
- higher delivery speed and quality
Platform Teams
- enable the stream-aligned teams to deliver work
Behaviors
- stream-aligned teams
- fast prototyping techniques and involves stream-aligned teams for feedback
- focus on usability and reliability
- leads by example
- understands adoption not immediate
Good platforms
- force multiplier
- standards
- templates
- APIs
- best practices
Thinnest Viable Platform (TVP)
- balance between keeping platform small and ensuring platform helps accelerate software delivery
- don’t let the platform dominate the discourse
- reduces complexity while exposing functionality
Platforms:
- built on a platform mindset (platforms all the way down)
- has users and defined active hours => reliability targets
- designed for long term user needs
Common Team Conversion
- Most teams should be long-lived, multidisciplined, stream-aligned teams
- Infra teams -> Platform Teams
- Components teams -> Platform or other teams
- Tooling Teams -> Enabling or Platform Teams
- Architecture team -> Enabling Team
Chapter 6: Choose Team First Boundaries
Overview:
- Monoliths can be hidden by team boundaries
- Consider software boundaries when necessary and suitable
Flow:
- difficult when teams interactions are complicated
Team First Approach to Software Responsibilities
software delivery problems
- unclear boundaries between teams & responsibilities
- tight coupling between teams
monolith -> loosely coupled services
- consider affect to teams
Hidden Monoliths
- Application Monoliths: single, large application w/ many dependencies
- Joined at the database Monoliths: multiple applications sharing a single database
- Monolithic Builds: one gigantic continious-integration to build a version
- Monolithic Release: smaller components bundled together into a release
- Monolithic Model: single domain langauage and representation
- Monolithic Thinking: one size fits all approach to team design
- Monolithic Workplace: single, open office layout for all teams
Software Boundaries or Fracture Planes
Fracture Plane: natural seam, allows system to be split into parts
- Business Domain Bounded Context: e.g. Domain Driven Design
- Regulatory Compliance: Split on sub-systems that are in different scopes of regulation
- Change Cadence: separate parts of the system that change at different rates
- Team Location: separate teams in different locations
- Risk: subsystems with different risk profiles
- Performance Isolation: subsystems with different performance requirements
- Technology: subsystems using different technologies
- User Personas: subsystems serving different user personas
