I've witnessed a significant shift in engineering team structures since Team Topologies (Skelton and Pais, 2019) came out. It's clear the book has had a lasting impact on how we design our teams.
At the heart of Team Topologies are four fundamental team types: Stream-aligned teams, which have end-to-end ownership of a business domain, make up the majority of teams. Platform teams reduce cognitive load for stream-aligned teams by providing self-service infrastructure and capabilities. Enabling teams help stream-aligned teams adopt new practices and capabilities, often with time-limited engagements. Complicated-subsystem teams own particularly complex components that require specialist expertise and are separated from stream-aligned teams to manage cognitive load.
The central thesis of Team Topologies is that team design should be guided by the principle of minimising cognitive load. A team that owns too many systems or too complex a system cannot develop deep expertise or work at velocity. To achieve mastery, each team should own a clearly bounded domain that fits within their cognitive capacity. Team size, scope, and complexity must be calibrated accordingly.
For instance, I have seen a team of 15 engineers struggling to maintain a monolithic architecture. After reorganizing into three stream-aligned teams of 5 engineers each, they were able to work independently and develop deep expertise in their respective domains. The cognitive load reduction was significant, and they were able to deliver changes at a much faster pace.
According to Team Topologies, team interactions can be categorised into three modes: Collaboration, where two teams work closely together to discover new things, suitable for short periods; X-as-a-Service, where one team provides a service consumed by another with minimal interaction; and Facilitating, where one team helps another improve their practice. The choice of interaction mode determines the communication overhead, with Collaboration being high overhead and X-as-a-Service being low overhead.
When implementing these interaction modes, it's essential to consider the trade-offs. For example, using APIs to enable X-as-a-Service interaction can lead to a more scalable architecture, but it may also introduce additional latency and complexity. On the other hand, Collaboration can lead to better alignment and innovation, but it requires more frequent meetings and communication.
Team Topologies explicitly highlights the implications of Conway's Law: your system architecture will mirror your team communication structure. Rather than designing the architecture independently of team structure, you should design both together. If you want a system with clear service boundaries, create teams with clear ownership boundaries. If you want a platform team's capabilities consumed as APIs, structure the team interaction as X-as-a-Service.
Designing teams and architecture together has a profound impact on both. By aligning team structure with system architecture, you can create a more cohesive and efficient organisation. It's not about imposing a rigid structure but rather finding a balance that works for your team and your business.
One of the key takeaways from Team Topologies is the importance of team size. According to Dunbar's numbers, an effective working group should have between 5-9 members. This size allows for deep expertise and collaboration without overwhelming the team. I have seen teams with 15-20 members struggle to make decisions and deliver results, while teams with 5-7 members are able to work more efficiently and effectively.
The interaction modes defined in Team Topologies – Collaboration, X-as-a-Service, and Facilitating – are not mutually exclusive. In fact, teams often interact using a combination of these modes. However, the choice of interaction mode should be guided by the type of work being done and the level of communication overhead required.
Team Topologies provides a framework for designing teams that is both flexible and adaptable. By considering team size, scope, complexity, and interaction modes, you can create a team structure that aligns with your system architecture and business goals.