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.
- Stream Aligned
- Complicated Sub-System
- 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
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?
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?
Team coaching Mentoring Service Management Well-written documentation Process improvement