Stop Team Topologies
Reevaluating Team Topologies: A Critical Perspective on Organizational Strategies
The highly valued “Team Topologies” (TT) book provides a clear, practical framework for optimizing team structures in software development. Written by Matthew Skelton and Manuel Pais, the book addresses the complexities of modern software delivery by emphasizing the importance of team interactions and boundaries. It introduces the concept of “Team Topologies,” which includes four fundamental team types and three core interaction modes, guiding organizations on how to design and evolve their team structures for improved flow and delivery—seemingly aligning seamlessly with Agile principles by promoting a culture of collaboration, autonomy, and continuous improvement. Furthermore, the book offers actionable insights and limited real-world examples, making it an attractive resource for Agile practitioners to simplify their lives by reusing other people's solutions to their organisational challenges.
Guilty as charged
I, too, found myself drawn to its compelling framework for optimizing team structures. The book’s practical advice and emphasis on effective team interactions are undeniably attractive. However, as Dave Snowden and the Cynefin framework remind us, the complexity of our world means that we cannot simply reuse solutions from others for our own unique problems. Snowden’s insights highlight the necessity of understanding the context-specific nature of the challenges we face. In the complex domain of Cynefin, solutions must emerge from probing, sensing, and responding rather than from applying predefined frameworks. This perspective encourages us to adapt and tailor our approaches to fit our distinct environments and needs rather than relying solely on the success of others’ strategies.
Product teams
Team Topologies favours stream-aligned teams over traditional product teams because stream-aligned teams are designed to optimize the flow of work and value delivery across an organization. Stream-aligned teams are structured around a continuous flow of work, rather than being focused on a single product. The main reason given in the book is that modern teams often don't have products as such. In a multi-channel, highly connected context, a “product” can mean very different things, making it hard to understand what the responsibilities of a “product team” are. In my experience, this is often the case. However, I have found it tremendously valuable to have faced this challenge with the team and think of our work as contributing to the Product, even if it is conceptual.
What problem are we trying to solve?
While team alignment with the flow of value is essential for optimizing workflow and value delivery, the purpose of a team can often be more effectively positioned as a conceptual product with targeted users, a Job-to- be-Done, and specific value propositions. This perspective ensures that each team’s efforts are directly tied to delivering tangible outcomes that meet the needs of their users. By conceptualizing a team’s purpose as a product, organizations can clarify goals and expectations, making it easier to prioritize tasks, measure success, and align efforts with user needs and business objectives. This approach fosters true End-to-End ownership of the user journey and the specific problems or opportunities that exist in the product domain, thereby driving more focused innovation and delivering higher value. It bridges the gap between operational efficiency and strategic impact, ensuring that the work of stream-aligned teams translates into meaningful and user-centric outcomes. It creates the notion of clear product boundaries and the need for a working physical interface between products, thus preventing handovers of work and enabling greater autonomy within teams. I think it's also telling that after discarding Product Team as a good title for your core user-facing stream-aligned teams, most of the examples in the book are about product teams, and the word itself still appears over 200 times.
Cognitive load
In TT, one of the main drivers is to limit cognitive load using relative domain complexity; it is essential to understand the three types of cognitive load: intrinsic, extraneous, and germane. Intrinsic cognitive load pertains to the fundamental aspects of the task itself, such as understanding the structure of a Java class or creating a new method. Extraneous cognitive load relates to the environment in which the task is performed, including questions like how to deploy a component or configure a service. Germane cognitive load involves the aspects of the task that require special attention for learning or achieving high performance, such as determining how a service should interact with another service like the ABC service. By distinguishing and managing these types of cognitive loads, teams can optimize their performance and learning efficiency.
Cognitive Creativity
This interpretation takes a very unconventional view of Cognitive Load Theory, which was developed in the late 1980s by John Sweller through his study of problem-solving. Sweller argued that instructional design can reduce cognitive load in learners. In cognitive psychology, cognitive load refers to the amount of working memory resources used. It is crucial to distinguish this from the actual construct of Cognitive Load (CL) or Mental Workload (MWL), which are widely studied across various disciplines. Research in instructional design and pedagogy identifies three types of cognitive load: intrinsic cognitive load, which is the effort associated with a specific topic; extraneous cognitive load, which pertains to the way information or tasks are presented; and germane cognitive load, which involves the effort put into creating a permanent store of knowledge (schema). Over the years, the additivity of these cognitive load types has been questioned, and it is now believed that they influence each other in a circular manner. This loose interpretation and framing of Cognitive Load Theory to fit the TT model might be symptomatic of the book's approach.
Domain Driven Design
We probably all agree with TT that reducing cognitive load is essential for most teams and organisations. However, I feel Domain-Driven Design (DDD) offers a more effective approach than the out-of-context use of Cognitive Load Theory for reducing cognitive load in software development because it directly addresses the complexity of the business domain and aligns the development process with it. By focusing on the creation of a clear, shared understanding of the domain through ubiquitous language and bounded contexts, DDD simplifies communication and ensures that all team members are on the same page. This reduces the need to constantly translate domain knowledge into technical terms, thus minimizing intrinsic and extraneous cognitive load. Additionally, DDD emphasizes modularity and the strategic partitioning of the domain, which makes it easier to manage and reason about complex systems, ultimately fostering better learning and more efficient knowledge retention (germane cognitive load) within teams.
If you don't know the Why you can't scale the What
Team Topologies is fundamentally grounded in anecdotal practices, which have been extracted from the complex domain where the interactions and variables are highly interconnected and unpredictable, necessitating strategies that are both more flexible and adaptive than TT. This approach emphasizes the importance of understanding the nuanced and often context-specific reasons behind why certain practices succeed. Extracting them as good practices to ordered domains, where systems and problems are more linear and predictable, can only be effectively applied if there is a clear comprehension of the underlying mechanisms that make them work repeatably. This understanding allows practitioners to adapt and implement these practices in a way that aligns with the specific challenges and constraints of their environment, ensuring they are not merely copying methods but also appreciating the principles that drive their success. Labelling these as best practices and restricting topologies to just four team types and three interaction modes without demonstrating a proven causal effect grounded in fundamental principles is undeniably harmful.
From the field
My experiences with Team Topologies have been mixed. The book’s perfectly digestible and lightweight nature often drives people to seek overly simplistic solutions, leading to its rapid spread across an organization. Given how rare it is for traditional management to read books on organizational design in relation to agile, we seized the opportunity because the book does contain some valuable concepts, such as Conway’s Law, Dunbar’s Number, and Cognitive Load, all of which are beneficial in their own right.
Big Transformation, small impact
We used Team Topologies in a larger organization to initiate discussions about breaking down silos and establishing Value Streams. Matthew Skelton even facilitated some excellent workshops, leading to significant progress. However, I felt that the introduction of more advanced topics came too soon. This was clearly highlighted during a slightly agitated debate on the concept of DevOps, which is assumed to be a given in Team Topologies but was not established in our organization. Additionally, many managers and teams were drawn to the enabling team topology, which, while appealing, should be used sparingly and temporarily. Stream alignment also assumes that streams have already been mapped, so combining these two exercises proved to be challenging. It often felt like playing chess blindfolded, with cautious participants wary of the consequences of reorganization decisions. Ultimately, I believe Team Topologies advanced the organization, but it did not result in an actual map of clearly defined teams and interaction modes.
Small Transformation, big impact
I introduced the book at a smaller company, but it did not gain much traction. Instead, I shifted the focus to the fundamental concepts underpinning it: Conway’s Law, Dunbar’s Number, and reducing cognitive load using Domain-Driven Design (DDD) principles. This approach proved to be far more successful, even if it wasn’t directly comparable. We restructured the organization from ten skill-based teams and eleven Chapters to three customer-facing product teams, two platform teams, one platform/enabling team, and four chapters. This strategy avoided the issue of people oversimplifying by feeling compelled to choose a specific topology and stick to it rigidly. We discussed interaction modes, but our teams lacked the cross-functional capabilities needed to manage the complexity of the legacy in the system within such rigid constraints. Instead, we conducted a broader exercise inspired by Simon Sinek’s “Start with Why.” This exercise delved into the fundamental purpose, principles, and practices of each team, helping to define the “How” in a more comprehensive manner than simply focusing on inter-team interactions.
Conclusion
George Box famously quipped, “All models are wrong; some are useful.” By this logic, Team Topologies is inherently flawed: complex organizations cannot be reduced to just four types of teams and three types of interactions. Team Topologies serves as a tool that encourages organizations to evolve towards more effective ways of operating. It allows stream-aligned teams to maximize their flow by reducing cognitive load, thereby enhancing overall efficiency and productivity. Be very aware of the Dunning-Kruger effect, where people, book in hand, start to restructure the organisation without understanding the underlying fundamentals.
Please read the book, stick it in your toolbox, and design your approach tailor-made and evolving for your specific organisation. Avoid big design upfront approaches with Team Topologies, however tempting the simplicity might be. Go back to the basic proven physiological principles like Conway’s law and Dunbar's number or even tools like DDD or XP. Experiment in context and evolve, do Agile Transformations Agile.
List of useful Laws, Patterns and Frameworks:
- Conway’s law: The structure of any system designed by an organization is isomorphic to the structure of the organization. Consiencly design your system architecture and your organisation hand in hand and let them evolve together.
- Dunbar’s number: 150. The cognitive limit to the number of people with whom one can maintain stable social relationships — relationships in which an individual knows who each person is and how each person relates to every other person.
- Cynefin: Cynefin offers five decision-making contexts or “domains” — clear, complicated, complex, chaotic, and confusion — that help people to identify how they perceive situations and make sense of their own and other people’s behaviour.
- Jobs to Be Done Theory: The theory that helps innovators understand how and why people make decisions.
- Parkinson’s law: Work expands so as to fill the time available for its completion. Do shorter Sprints, Cycles, meetings, Timeboxes, etc.
- Parkinson’s law of triviality: The time spent on any agenda item will be in inverse proportion to the sum of money involved.
- Theory of Constraints: “A chain is no stronger than its weakest link.” Identify the system constraint. Exploit the system’s constraint. Subordinate everything else to the above decision. Elevate the system’s constraint. Rinse and repeat.
- Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. Don't build or fix a complex system as a whole. Find the right granularity and introduce simple elements that work and keep the system working at all times.
- Engelbart’s law: The intrinsic rate of human performance is exponential. Start small and slow to "get better at getting better.”
- Little’s Law: Service time is the bottleneck that creates the queue.
- Strangler fig pattern: Wrapping old code, with the intent of redirecting it to newer code—bonus points for Skunk Works cultural wrapping.
- Brooks’s law: ”Adding manpower to a late software project makes it later.”
- Dunning–Kruger effect: People who are unskilled in some area wrongly believe their ability is higher than average. They don't know what they don't know.
- Occam’s razor: Entities must not be multiplied beyond necessity. Keep your teams as simple and small as possible.
- Pareto principle: For many phenomena, 80% of consequences stem from 20% of the causes.
- Vierordt’s law: Retrospectively, “short” intervals of time tend to be overestimated, and “long” intervals of time tend to be underestimated.
- Larmans Law: Organizations are implicitly optimized to avoid changing the status quo.
What law am I missing? Let me know in the comments.
