Stop Simplisticism
Start implementing principles instead of other people's simplistic solutions like Team Topologies.
In a popular previous article and accompanying LinkedIn post that resonated in the community, we explored the advantages of grounding organizational change in the fundamental principles and laws of Team Topologies(TT) rather than merely copy-pasting the solutions in the book. This approach is crucial for several reasons:
- Emergence: Within a complex adaptive system, solutions emerge through a process of probing, sensing, and responding rather than rigidly adhering to predefined frameworks.
- Effectiveness: Optimizing a workflow without ensuring product value is wasteful. It’s crucial to ensure efforts enhance real user value rather than just optimise the flow of work.
- Dunning-Kruger effect: The book's simplistic patterns often lead managers to attempt restructuring their organizations without a solid grasp of the necessary foundational principles and prerequisites.
The article concluded with a strong recommendation: Organizations should concentrate on understanding and applying fundamental laws and principles in context rather than copying existing practices wholesale. This focus helps avoid the pitfalls of overly simplistic, one-size-fits-all solutions and promotes a more thoughtful, effective approach to organizational change.
Mildly Viral
As anticipated, my LinkedIn post about the article sparked a lively discussion among industry pundits. The conversation reached a new level of engagement when Matthew Skelton, the author of Team Topologies, contributed eight insightful comments. His interactions helped the post go mildly viral, attracting significant attention with 20k views, 84 comments and 9 reposts. This vibrant interaction underscores TT’s relevance and impact within the community.
Flack
Not all the feedback on the post was positive; some avid Team Topologies supporters were particularly vocal in their critique. The criticism largely fell into three categories:
- Clickbait Accusations: Some commenters felt the post was designed primarily to attract attention rather than provide substantive content.
- Misinterpretation and Misapplication: Others argued that the article reflected a fundamental misunderstanding of the book or an incorrect implementation of its approach.
- Optional Implementation: A third group pointed out that adopting Team Topologies is not mandatory and emphasized flexibility in its application.
Click bate
Admittedly, the title might seem a bit clickbaity, but it’s far less so than some critics assumed. It’s part of my series “Stop! Agile Transformation,” which addresses the prevalence of overly simplistic solutions for the complex problems encountered in agile transformation. This particular article drives home that very point: we need to move away from recommending generic best practices based on one's own experience for the complex domains of others without a solid theoretical understanding of the ‘Why.’ With this series, I intend to stop what I’ve coined as ‘Simplisticism’ and challenge one-size-fits-all recipes to encourage a deeper, more thoughtful approach to agile transformation.
You don't know what you are talking about
I’m somewhat perplexed by some people’s insistence that I haven’t properly understood the book. I have read the book several times, completed the Team Topologies online course, utilized the remote team interactions workbook, participated in several workshops led by Matthew Skelton himself and hosted our own workshops based on TT. Given this extensive engagement with the material, I believe I have a solid grasp of the concepts and have applied them thoughtfully within the organizations I was engaged with. I feel strengthened in this belief by the fact that Mathew actually found my article “a really good read”.
Team Topologies are prescriptive.
The book describes the team topologies as prescriptive and immutable, asserting that building and running a software system is optimally achieved using only four defined team types. It even suggests that deviating from these types might be actively harmful to an organization. Similarly, the book emphasizes that any team interactions outside the three core interaction modes are considered wasteful and indicative of poorly chosen team responsibility boundaries and poorly understood team purposes. This leaves little room for flexibility or adaptation beyond the established patterns, reinforcing the condition to adhere strictly to the topologies as defined. You can do all the organisational sensing that you want, but where is the room for adapting or expanding this model in response to unique organizational needs or evolving challenges?
You're doing it wrong.
The argument that one doesn’t need to use Team Topologies or that it’s being misapplied strikes me as somewhat akin to saying, “Guns don’t kill people; people kill people.” This kind of reasoning seems to deflect from the inherent characteristics and potential effects of Team Topologies itself, shifting the focus entirely onto how it’s being implemented. I refer to this as the “SAFallacy.”
SAFallacy
Over a decade ago, we attempted to develop a new editor for a major publisher using the Scaled Agile Framework (SAFe). Whether the project’s turbulence was directly due to the framework is hard to say; more factors played a significant part. More relevant here is that the experience was marked by relentless debates over whether we were “doing it right.” From start to finish, ongoing discussions about framework elements that supposedly weren’t implemented correctly overshadowed addressing real problems. Although not always stated by quoting the manual directly, there were frequent references to deviations from the “ideal” SAFe application. Moreover, when SAFe fails to meet expectations, ardent supporters often defend it with a familiar argument: “You’re doing it wrong.” This line of reasoning implies that the framework itself is theoretically perfect, and any failings stem solely from improper implementation.
Blame the victim
By blaming the implementation rather than considering the possibility of intrinsic limitations of fixed frameworks and methodologies in complex environments, we risk ignoring critical insights that could lead to better outcomes. Such a viewpoint can create a blind spot or obsession with some coaches to strive for perfect framework alignment and get frustrated whenever people do not seem to be doing what they are supposed to, according to the literature. It prevents organizations from critically assessing whether a given framework truly fits their unique needs or whether adjustments might be necessary for it to function optimally. Ultimately, it makes constructive conversations about an appropriate operating model and its capacity to support complex organizational environments virtually impossible.
Balancing Simplicity and Complexity
Throughout Team Topologies, the emphasis on avoiding complexity becomes increasingly apparent. However, while simplification can be beneficial, it should not be pursued as an end in itself. The goal is to reduce friction without sacrificing essential value. As Albert Einstein famously noted, “Everything should be made as simple as possible, but not simpler.” This reminds us that we must not try to strip away complexity to the point where we overlook critical challenges or fail to address the core of the problem. Not surprisingly, there is even a law for this principle; Ashby’s Law of Requisite Variety states that for a system to regulate or control another system effectively, it must have at least as much variety or complexity as the system it seeks to manage. It essentially says that to effectively manage or control a system, the controlling system must be able to respond to all the possible states or variations of the system it wants to control.
The Thermostat as a Model for Effective System Control
A classic example is a thermostat system that controls the temperature of a room. The room can experience various conditions: it might get colder because of the weather outside, warmer from sunlight through windows, or experience fluctuations from other heat sources like appliances or people entering and leaving. For the thermostat to maintain a consistent desired temperature, it must have the capability to respond to all these variations. That means it must be able to detect and measure the temperature changes and then trigger the heating or cooling system to adjust accordingly. If the thermostat can only detect changes in temperature from the outside weather but not from sunlight or other heat sources, it won’t be able to maintain the set temperature effectively. The variety in the thermostat’s responses must match the variety of temperature influences in the room to achieve effective control.
The Daily Scrum and Ashby’s Law of Requisite Variety
The Daily Scrum is an example that illustrates Ashby’s Law of Requisite Variety. This daily meeting acts as a regulator mechanism for the Sprint, ensuring the Scrum team’s control system, the people in the Daily, contains sufficient variety to regulate all the states of the Sprint effectively. Ashby’s law posits that only variety can absorb variety, meaning that the team needs a broad spectrum of skills and perspectives to handle the complexities of the Sprint adequately. If a key member such as a tester is absent, the system loses critical variety, reducing its ability to obtain and act upon essential information from the testing domain. Consequently, the system’s effectiveness in regulating and adapting to the Sprint’s various states is compromised, emphasizing the need for full participation in the Daily Scrum.
Find a balance between complexity, process and simplicity.
In the spirit of complexity theory, I like to examine what control, regulate, and even complexity mean within context to make things more concrete and actionable. Achieving the necessary variety to match a system’s complexity may not always be feasible or efficient, and it could neglect alternative approaches like leveraging simpler rules and heuristics, enabling constraints and emergent behaviours to manage complexity without mirroring it in a disjunctive control system. We don't necessarily want to bring the whole Scrum team together the entire day. We want to bring the right granularity to the Daily and continue with more detailed discussions offline. We agree upon some guiding principles and a general direction and know we will have another chance to adjust tomorrow. Actual effectiveness lies in balancing simplicity in proven practices with the need to tackle difficult but necessary complex problems.
KISS: Keep It Simple Stupid
While simplicity is a commendable quality that reduces cognitive load, speeds up decision-making, and supports adaptability, oversimplification can be risky. Gall’s Law highlights that effective complex systems tend to evolve from simpler, functional ones rather than being built in a single attempt. In a major transformation for a telecom company, we saw this firsthand: the introduction of a SpotiSAFe model completely neglected the need for fundamental cross-functional teams. While the consultant’s PowerPoint slides painted a clean, simplified vision, the reality was far more intricate. Following the reorganization, teams faced numerous dependencies without structures in place to manage them. Rather than a one-shot rollout, it would, for instance, have been far more effective to gradually introduce specific, functioning agile elements that addressed known issues, enabling the system to evolve naturally without sacrificing stability or critical complexity.
The Challenge of Adapting to Real User Needs in Product Development
I often observe a nearly instinctive, subconscious reaction when people face the necessity of change and must abandon a simplistic worldview. This concern typically stems from the fear of negating past efforts — with worries like “Will this make my previous work obsolete?” or “Will this require me to change my point of view?” frequently arising. While the preference for simplicity is natural, our primary goal is to deliver value to our customers, which often entails tackling complex, challenging tasks.
The Impact of Simplification on Product Development
This issue became starkly evident in the case of a product manager we worked with who had oversimplified a product’s functionality to secure board approval. At the time, the board received his presentation positively. However, when real users later tested prototypes, it was clear that their needs were far more complex and varied than initially portrayed. Despite this, the manager hesitated to recognize these complexities, fearing that it would damage his credibility with the board. His reluctance to revise the product vision according to real user feedback risked impeding the development of a truly valuable and functional product. Embracing these complexities, although challenging, is essential to delivering a product that genuinely meets customer needs.
Shu-Ha-Ri and Simplification: Navigating the Complexities of Organizational Change
Change in organizations is notoriously challenging, and genuine transformation is rare. I also have relied on oversimplified, rigid frameworks, embracing the Shu-Ha-Ri philosophy, but this approach frequently resulted in unsatisfactory outcomes. People often tended to see these frameworks as silver bullets rather than the beginning of a continual, iterative process. The allure of frameworks that offer clear, limited options is strong, especially when faced with the daunting complexity and variability of adaptive systems. However, embracing this complexity and moving beyond initial implementations is essential for true organizational growth and adaptation.
Hard things easy
Although I often disagree with his political views, Ben Horowitz underscores that running a business — particularly when things go wrong — is inherently difficult. In the book The Hard Thing About Hard Things, he states that avoiding challenges often leads to worse outcomes, not better ones. The real work is in tackling the hardest problems head-on, even when they are uncomfortable or complex. Cutting corners or attempting to sidestep these challenges can lead to a fragile foundation that crumbles under pressure.
Our frameworks and processes should be as simple as possible to reduce unnecessary friction, but they should not be simplistic in that they avoid dealing with hard problems. The goal isn’t to minimize effort for the sake of convenience; it’s to ensure we focus on the most critical aspects of product development and customer satisfaction. Simplification should serve effectiveness and clarity, not become an excuse to dodge complexity. I feel that tendency prevails in many transformation approaches or frameworks, not only in the book Team Topologies.
How to implement Laws and Principles?
In addition to the feedback and critiques, I received numerous inquiries about how to implement the laws and principles discussed in the article, especially in situations where traditional approaches, like fixed patterns or Team Topologies, may fall short. This raises a crucial and valid question: it’s one thing to acknowledge the relevance of certain principles or laws, but it is an entirely different thing to develop strategies or ways of working that truly embody these principles.
Flexible Frameworks
Implementing these ideas effectively demands an adaptive, nuanced approach that transcends the limitations of rigid, predetermined patterns. This requires establishing a dynamic framework capable of evolving in tandem with new insights and shifting organizational conditions. Such a framework should avoid the pitfalls of oversimplification, which often stifles innovation and adaptability.
At the core of our complex adaptive systems are humans. Contrary to popular belief, they represent the most adaptable nodes. Therefore, enhancing their inherent flexibility rather than restricting it through rigid rules and regulation is crucial. Limiting interactions, for instance, by the use of oversimplified Single Points of Contact (SPOCs) or the implementation of, linear workflows with fixed processes, can impede this flexibility. Instead, organizations should cultivate an environment that encourages purposeful interaction and collaborative problem-solving, enabling more responsive and resilient organizational structures and dynamics. By fostering such a culture, organizations can better adapt to the unpredictable challenges of today’s dynamic business landscape.
Encouraging Experimentation and Learning in Organizational Frameworks
This approach means enabling an environment where experimentation is actively encouraged, and failures are reinterpreted as opportunities for learning and growth. To cultivate such a culture, organizations can begin by empowering teams to evolve within carefully defined constraints and safe boundaries. This empowers them to align their growth and development with the fundamental laws and principles that are relevant to their specific organization and contextual needs.
Implementing this strategy effectively involves embracing iterative cycles of trial and error. Each cycle allows for continuous refinement of strategies and approaches based on real-world results and feedback from the system. Fundamentally, the successful adoption of these principles hinges on a paradigm shift from a rigid adherence to fixed patterns to a more flexible adaptation strategy. In this model, the learnings and insights gained from each attempt are crucial, as they inform and enhance subsequent efforts, thereby fostering a more agile and responsive organizational structure.
Stop! Agile Transformation
To stop simplistic solutions and foster true organizational change, it’s crucial to shift from merely copying methods to implementing fundamental principles suited to specific contexts. This shift recognizes the dynamic nature of complex systems, where solutions should emerge through adaptive processes rather than static frameworks. Engaging deeply with these principles encourages genuine agility and effectiveness, countering the pitfalls of oversimplification and promoting a thoughtful approach to transformation.
In summary, here’s list of practices to stop:
- Stop Copy-Pasting: Avoid blindly replicating solutions that might not suit your unique organizational context.
- Stop Over-Simplifying: Resist reducing complex issues to overly simplistic models.
- Stop Ignoring Systemic Dynamics: Acknowledge and address systemic factors that influence behaviour and outcomes.
- Stop Fixed Frameworks: Move away from rigid one-stop shop frameworks that restrict adaptation to shifting organizational needs.
- Stop Making Hard Things Easy: Recognize that some challenges require complex solutions and resist the temptation to oversimplify difficult tasks.
Plot twist
In a next article, I will indulge in my own self-serving expertise bias and explore examples of how I have stopped and tried to implement principles over practices.
