I found the early chapters of Team Topologies interesting and appreciated the practical insights into team interaction modes. That said, I stopped reading it after a few chapters because I noticed a fundamental flaw in the approach.
From a systems thinking perspective, Team Topologies appears to focus more on optimizing teams for speed (often in isolation) rather than improving the system as a whole.
Ackoff’s Warning:
Focusing on parts without aligning with the purpose of the system leads to dysfunction, no matter how well each part is “performing”.
For example:
- Improving individual parts of the system, like enhancing team APIs or streamlining flow within teams, doesn’t necessarily lead to improvement of the whole. See Ackoff rule of system performance in our Systems Thinking article.
- Focusing on the parts without connecting to end-user-value results in local optimizations (e.g., better developer experience, faster team-level delivery) while still falling short of alignment with customer outcomes or broader organizational goals.
- Also, TT tends to work within existing organizational constraints, rather than challenging or reimagining them. It likely does not help as I explained in Stop Fixing Symptoms.
- And, TT optimizes for speed, not for adaptability!
In contrast, a systemic approach, like Creating Agile Organizations and LeSS, starts by asking: What is the team’s role in delivering customer value? From there, the teams’ structure, organization, and interactions are all redesigned to serve that purpose. Local team performance only matters if it contributes to the performance of the whole.
The approach follows a clear, step-by-step process:
Step 1. Identify purpose from the end-customer’s point of view
Define the strategic intent and products from the outside-in: What are customers trying to achieve?
Step 2. Understand how the current organization performs against that purpose
Use tools like the Design Structure Matrix (DSM) to expose structural constraints and inter-team dependencies required to deliver on the strategy. See Design For what your Strategy Demands.
Step 3. Design the organization in function of the purpose
Organize teams around customer value, not internal functions or components. Define Product Groups, Value Area Groups, Customer Units, and Platform Services as needed. There are many ways to deal with ‘Dunbars number as I explained in Moving Beyond Size Logic.
Step 4. Put control in the hands of the teams
Enable local decision-making within Value Areas and Product Groups.
Both approaches serve different needs. For those looking to go beyond team-level optimization and align organisation design with strategy, CAO and LeSS may offer a more suitable path.
