Team Topologies

What it was about:

How to setup teams within your organization for success. People who are on the teams matter, the team structure matters, and the team structure will influence the product architecture

Key Points:
 

Conway’s Law:

  • “Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations”
    • aka “Organizations design systems that mirror their communication structure”
    • aka “Organizations are constrained to produce designs that reflect their communication paths”

Organizational Design:

  • The design of the organization will constrain the software designs possible
  • Limiting communication paths to well-defined team interactions produces modular, decoupled systems
  • Org charts
    • Org charts do not reflect the actual communication structures that teams/individuals use
    • This lateral/horizontal communication structure needs to be nurtured for the benefit of the org, not restricted to optimizing for top-down/bottom-up communication and reporting
  • Systems Thinking: focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it
  • Technical leaders should be included when designing orgs or when doing a reorg

Designing Organizations (Guide to Organization Design: Creating High-Performing and Adaptable Enterprises” by Naomi Stanford”)

  1. Design when there is a compelling reason
  2. Develop options for deciding on a design
  3. Choose the right time to design
  4. Look for clues that things are out of alignment
  5. Stay alert to the future

Communication:

  • Restrict Unnecessary Communication
    • Not all communication and collaboration is good
    • Mike Cohn’s questions to assess the health of inter-team communication within an org
      • Does the structure minimize the number of communication paths between teams?
      • Does the structure encourage teams to communicate who wouldn’t otherwise do so?
      • Really Addressing:
        • If two teams shouldn’t need to communicate based on the software architecture design then something must be wrong if the teams are communicating. Is the API not good enough? Is the platform not suitable? Is a component missing?
    • Everyone does not need to communicate with everyone. This will lead towards monolithic, highly coupled systems that do not support fast flow. More communication may have the unintended consequences for lack of modularity between subsystems

Leave a Comment

Your email address will not be published. Required fields are marked *