When a team can’t work autonomously, you notice many symptoms.

• They’re frequently blocked because of dependencies or a lack of ownership.

• The complexity of the system creates knowledge silos.

• It’s unclear who you must interact with or who can help to help you move forward.

To address these issues Matthew Skelton and Manuel Pais have written about the idea of “Team Topologies”. Please read their excellent book, which is all about organising software development teams in a manner that reduces cognitive load and improves their ability to deliver. All this, while being clear about interaction patterns across teams.

Skelton and Pais recommend organising across four kinds of teams – the fundamental topologies.

1. Stream-aligned teams. These align to a flow of work from a segment of the business. E.g., an iOS app.

2. Enabling teams. These teams help stream-aligned team to overcome obstacles. They may also help detects missing capabilities. E.g., a team specialising in test automation.

3. Complicated subsystem teams. These teams develop systems where specialised expertise is necessary. E.g., biometrics driven identity management.

4. Platform teams. These teams provide a set of underlying services and APIs to accelerate delivery from stream-aligned teams. E.g., a core banking platform.

The authors go on to describe the possible interaction patterns between such teams, so teams can communicate with each other in meaningful ways. They recommend only three interaction patterns across teams.

1. Collaboration. This is when teams work together for a specific duration on a specific charter. For example, a platform team may collaborate with a stream aligned team to agree on new API specs.

2. X-as-a-Service. This pattern emerges when one team provides, and one team consumes something “as a Service”. This kind of interaction shouldn’t need much input from the providing team. And if it does need prolonged inputs, then it may mean that the teams involved, should follow a collaboration pattern instead.

3. Facilitation. In this pattern one team with specialised knowledge helps and mentors another team. For example, the test automation team can help the iOS team build out its functional automation suite.

The above diagram summarises the four team topologies and the three interaction patterns. Work with other leaders and managers in your peer group, to investigate if it is possible to reorganise your teams into these topologies, so they have maximum autonomy to deliver their outcomes. This may not be a trivial task and it may need significant architectural changes. You may discover that don’t have the appetite for it just yet. However, keep these structural improvements at the back of your mind. That way, when the time’s right you may be able to advocate for this way of organising teams. The goal? Minimise each team’s cognitive load and limit noisy interactions.