How Adaptive are Team Topologies?

Roland Flemm
Published in
22 min readMar 6


This is a series of articles (among them are Spotify’s Tribes and Squads and Marty Cagan’s Empowered Product Teams) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions.

For our analysis, we are using a map of seven archetypes, that we call Org Topologies™.

This is a long read because we analyze and debunk the claims made by the authors of Team Topologies.

The key idea from Team Topologies:

  • Team Topologies’ promise is to optimize for the fast flow of change.
  • For the flow of change to grow, the teams’ Cognitive Load ought to be minimized.
  • And for this, it is suggested that teams go with narrow service code ownership.
  • Team Topologies claim that with such a strong focus on architectural concerns, the negative effects of Conway’s Law will be reduced.

We conclude (with the analysis of this article):

  • To make a change for a customer feature, typically several services and components need to change.
  • So despite the fast flow of change at the component level (as promised by Team Topologies), the flow of change at the feature level might not improve or even get slow.
  • The slowness of the R&D and due to narrow code ownership policies, Conway’s Law might get reinforced by Team Topologies.
  • The idea of a developer’s Cognitive Load is overplayed and analyzed very one-sidedly in Team Topologies.
  • Instead of introducing narrow service code ownership, one could as an alternative work to decrease product and engineering complexity by applying modern engineering ideas from companies like Google.
  • Team Topologies don’t seem to offer a strong vision to improve an engineering organization, but instead might let leaders accept mediocrity.

In general, applying ideas from Team Topologies might have serious negative side effects that leaders need to be aware of. And even without those side effects, we find there is too much talk about teams and too little about customer value and how to make the whole organization more adaptive and innovative.

Towards Detailed Analysis of Team Topologies

Roland Flemm

Making the working place of software development less miserable