Team Topologies

Warning
Work in Progress. Please contact me if there is a certain topic or section you want to hear more about.

Team Topologies

Team topologies provides models to think about team interactions when starting your journey toward using and creating an internal developer platform. Due to Conway’s law you might design your organization to operate around hierarchy and this will result in subpar performance of your software systems. Being intentional about team design can drive better success of your efforts.

Resources

Three Models of Interaction

  • Collaboration
  • Facilitation
  • X-as-a-service

Four Types of Teams

  • Stream Aligned
  • Enabling
  • Complicated Sub-System
  • Platform

Triggers, when to change an organizational topology

  • The software has grown too large for one team
  • Delivery cadence is becoming slower
  • Multiple Business services rely on a large set of underlying services

Questions to Ask

Have we misunderstood how users need/want to behave? Do we need to change team-interaction modes to enhance how the organization is working? Should we still be building thing X in house? Should we be renting it from an external provider? Is the close collaboration between Team A and Team B still effective? Should we move toward an X-as-a-Service model? Is the flow of work for Team C as smooth as it could be? What hampers flow? Does the platform for teams D,E,F, and G provide everything those teams need? Is an enabling team needed for a period of time? Are the promises between these two teams still valid and achievable? What needs to change to make the promises more realistic?

What does a team need to:

Act and operate as an effective team? Own a part of the software effectively? Focus on meeting the needs of users? Reduce unnecessary cognitive load? Consume and provide software and information to other teams?

What skills does a team need?

Team coaching Mentoring Service Management Well-written documentation Process improvement