Acknowledging the Shortcomings

I, too, was captivated by the book's compelling framework for optimizing team structures. Its practical guidance and focus on productive team interactions are indeed enticing. However, as Dave Snowden and the Cynefin framework illustrate, the complexity inherent in our world means we cannot simply adopt solutions crafted by others for our distinct issues. Snowden's insights stress the importance of recognizing the context-specific nature of the challenges we encounter. In the complex domain outlined by Cynefin, effective solutions must evolve from exploration, observation, and adaptation rather than from applying fixed frameworks. This viewpoint urges us to modify and personalize our strategies to cater to our unique circumstances and requirements rather than relying on the successes of others.

Reevaluating Product Teams

Team Topologies advocates for stream-aligned teams instead of traditional product teams since these teams aim to enhance the flow of work and value across an organization. Stream-aligned teams are organized around a continuous work stream rather than being tied to a single product. The book argues that in today's multi-channel and interconnected environment, the term "product" can take on various meanings, complicating the understanding of a product team's responsibilities. In my experience, this often rings true. Nevertheless, I have found great value in collaborating with my team to view our efforts as contributing to the overarching Product, even if it is a conceptual framework.

Identifying the Core Issue

While aligning teams with the flow of value is vital for optimizing workflows and value delivery, defining a team's purpose as a conceptual product with specific users, tasks, and value propositions can be more effective. This view ties each team's contributions to delivering concrete outcomes that address user needs. By framing a team's mission as a product, organizations can clarify objectives and expectations, which facilitates task prioritization, success measurement, and alignment with user requirements and business goals. This method promotes genuine End-to-End ownership of the user journey and the distinct challenges present within the product realm, encouraging innovation and maximizing value. It establishes clear product boundaries and emphasizes the importance of a functional interface between products, reducing handovers and enhancing team autonomy. It is noteworthy that despite abandoning "Product Team" as a fitting title for user-facing stream-aligned teams, the book predominantly discusses product teams, with the term appearing over 200 times.

Understanding Cognitive Load

In Team Topologies, a primary aim is to minimize cognitive load by considering relative domain complexity. Recognizing the three types of cognitive load—intrinsic, extraneous, and germane—is crucial. Intrinsic cognitive load relates to the fundamental aspects of the task, such as understanding Java class structures or creating methods. Extraneous cognitive load pertains to the context in which tasks are executed, including deployment or service configuration queries. Germane cognitive load involves aspects requiring focused attention for learning or achieving high performance, such as determining interactions between services. By identifying and managing these cognitive load types, teams can enhance their performance and learning efficiency.

Rethinking Cognitive Load Theory

This perspective provides a fresh interpretation of Cognitive Load Theory, established by John Sweller in the late 1980s through his exploration of problem-solving. Sweller posited that instructional design could alleviate cognitive load among learners. In cognitive psychology, cognitive load refers to the working memory resources utilized. It is vital to distinguish this from the broader concepts of Cognitive Load (CL) or Mental Workload (MWL), which have been extensively studied across disciplines. Research indicates three cognitive load types: intrinsic cognitive load, the effort linked to a particular topic; extraneous cognitive load, the manner in which information or tasks are presented; and germane cognitive load, which involves the effort to establish long-term knowledge retention. Recent discussions have challenged the additive nature of these cognitive load types, suggesting they influence one another in a circular fashion.

Domain-Driven Design as a Solution

While I concur with Team Topologies on the necessity of reducing cognitive load for teams and organizations, I believe that Domain-Driven Design (DDD) provides a more effective strategy than the Cognitive Load Theory framework for alleviating cognitive load in software development. DDD directly addresses business domain complexities and synchronizes the development process with these complexities. By fostering a shared understanding of the domain through ubiquitous language and bounded contexts, DDD streamlines communication and ensures that all team members are aligned. This reduces the need for continual translation of domain concepts into technical language, thus lowering intrinsic and extraneous cognitive load. Furthermore, DDD promotes modularity and strategic domain partitioning, simplifying the management and comprehension of complex systems, which ultimately enhances learning and knowledge retention within teams.

Understanding the "Why" for Scaling the "What"

Team Topologies is deeply rooted in anecdotal practices derived from complex domains where interactions and variables are highly interconnected and unpredictable. This necessitates strategies that are both flexible and adaptive. It emphasizes understanding the nuanced and context-specific reasons behind the success of certain practices. Extracting these as best practices for more orderly domains, where systems and issues are predictable, can be effectively applied only when there is a clear understanding of the mechanisms that underpin their effectiveness. This comprehension allows practitioners to adapt and implement these practices in a manner that aligns with the specific challenges and constraints of their environment, ensuring they are not merely mimicking methods but also grasping the principles that drive their success. Labeling them as best practices and confining topologies to merely four team types and three interaction modes without demonstrating a well-founded causal effect based on fundamental principles can be detrimental.

Reflections from Experience

My encounters with Team Topologies have been varied. Its concise and accessible nature often leads individuals to seek overly simplistic solutions, contributing to its rapid adoption within organizations. Given the rarity of traditional management engaging with literature on organizational design related to Agile practices, we seized the opportunity, as the book contains valuable concepts like Conway's Law, Dunbar's Number, and Cognitive Load, which stand on their own merit.

Large Transformation, Minimal Impact

We utilized Team Topologies within a larger organization to spark conversations about dismantling silos and establishing Value Streams. Matthew Skelton facilitated insightful workshops, resulting in notable advancements. However, I felt that the introduction of more complex topics occurred prematurely. This was particularly evident during a somewhat heated debate regarding DevOps, which Team Topologies assumes is a given but was not established within our organization. Additionally, many managers and teams were attracted to the enabling team topology, which, while appealing, should be employed sparingly and temporarily. Stream alignment also presupposes that Streams have been mapped out, and merging these exercises proved challenging. It often felt like engaging in a game of chess blindfolded, with cautious participants concerned about the repercussions of reorganization decisions. In the end, I believe Team Topologies moved the organization forward, yet it did not yield a "perfect" delineation of clearly defined teams and interaction modes.

Small Transformation, Significant Impact

I introduced the book at a smaller company, but it didn't resonate widely. Consequently, I redirected focus toward the foundational concepts it encompasses: Conway's Law, Dunbar's Number, and the reduction of cognitive load through Domain-Driven Design principles. This pivot proved to be far more effective, even if not directly comparable. We reorganized 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 approach mitigated the tendency for individuals to oversimplify by feeling compelled to adopt a specific topology rigidly. We briefly touched on interaction modes, but our teams lacked the necessary cross-functional capabilities to manage the intricacies of legacy systems within such strict confines. Instead, we conducted a broader exercise inspired by Simon Sinek's "Start with Why," which examined the fundamental purpose, principles, and practices of each team, enabling us to define the "How" more comprehensively than merely concentrating on inter-team interactions.

Final Thoughts

As George Box famously stated, "All models are wrong; some are useful." By this logic, Team Topologies has its flaws: complex organizations cannot be reduced to just four team types and three interaction types. Team Topologies serves as a valuable tool that encourages organizations to evolve towards more efficient operational methods. It enables stream-aligned teams to maximize their flow by minimizing cognitive load, thereby improving overall productivity and effectiveness. However, one must remain vigilant against the Dunning-Kruger effect, where individuals, book in hand, begin restructuring organizations without a solid grasp of the fundamental principles.

I encourage you to read the book, incorporate it into your toolkit, and design your approach tailored to your organization's specific needs. Resist the temptation to embrace large upfront designs with Team Topologies, no matter how appealing the simplicity may seem. Revisit foundational principles like Conway's Law and Dunbar's Number or tools like DDD or XP. Experiment within your context and adapt, ensuring that Agile transformations are genuinely Agile.

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. Intentionally design your system architecture and organization in tandem, allowing them to evolve together.
• Dunbar’s Number: 150. The cognitive limit to the number of individuals with whom one can maintain stable social relationships—relationships in which each person knows who everyone else is and how they relate to one another.
• Cynefin Framework: Offers five decision-making contexts or "domains"—clear, complicated, complex, chaotic, and confused—that help individuals identify how they perceive situations and understand their own and others' behaviors.
• Jobs to Be Done Theory: A framework that aids innovators in comprehending how and why individuals make decisions.
• Parkinson’s Law: Work expands to fill the time available for its completion. Shorten sprints, cycles, meetings, and timeboxes.
• Parkinson’s Law of Triviality: The time allocated to any agenda item will be inversely proportional to the sum of money involved.
• Theory of Constraints: "A chain is no stronger than its weakest link." Identify, exploit, subordinate, and elevate the system's constraint. Repeat this process continuously.
• Gall’s Law: A complex system that functions well is invariably derived from a simple system that worked. Avoid building or fixing a complex system as a whole. Identify the right granularity and introduce simple, effective elements to keep the system operational at all times.
• Engelbart’s Law: The intrinsic rate of human performance is exponential. Start small and gradually improve to "get better at getting better."
• Little’s Law: Service time is the bottleneck leading to queues.
• Strangler Fig Pattern: Encapsulating old code with the intent of redirecting it to newer code—bonus points for promoting a Skunk Works culture.
• Brooks’s Law: "Adding manpower to a late software project makes it later."
• Dunning-Kruger Effect: Individuals lacking skills in a certain area may mistakenly believe their abilities are above average; they often do not know what they do not know.
• Occam’s Razor: Entities should not be multiplied beyond necessity. Keep your teams as simple and small as possible.
• Pareto Principle: In many cases, 80% of outcomes arise from 20% of causes.
• Vierordt’s Law: Retrospectively, "short" time intervals tend to be overestimated, while "long" intervals are often underestimated.
• Larman's Law: Organizations are implicitly optimized to maintain the status quo.

What laws or frameworks am I missing? Feel free to share your thoughts in the comments.