All right, guys, let me start with the first question for you, Dave. I’ll be asking some basic questions during our conversation, but I think these are important for our community, especially for people in Brazil, to have clarity. Some of these may seem basic to you, but they are essential for us to gain a better understanding.
The first question I’d like to bring up is: What is the difference between complex thinking and systems thinking? There is often confusion between these concepts, so how do you explain it? Are they different, or are they the same?
There are also some very sensitive perspectives on this subject. Some people are easily offended. So, how do you respond to this distinction?
Complex Adaptive Systems vs. Systems Thinking
First of all, the key aspect of a complex adaptive system—which people need to understand, and which is actually quite difficult if you’ve had a European or North American education—is that complex adaptive systems do not have linear material causality. This means that the same thing won’t happen the same way twice, except by accident.
Complex systems are dispositional but not causal. I can measure their dispositional state and say, “These things are more likely, these things are less likely, the energy cost of making this change is low, whereas the energy cost of this change is high.” I can make all sorts of valuable statements, but I can never say, “If I do X, it will produce Y.”
This contradicts a whole body of work that came out of cybernetics. However, I want to pay tribute to some of its founders, such as Stafford Beer. I read Beer, I love Beer, and I believe that if Beer had known about complexity science, he would never have produced the VSM model. Beer intuited the concept that systems could be non-causal, but his intellectual tradition didn’t permit that, so he produced something with structured feedback mechanisms.
On the other end of the spectrum, cybernetics and systems dynamics have developed into two extremes: a hard, engineering-focused side (seen in business process re-engineering and Six Sigma) and a soft, abstract side (seen in learning organizations and Theory U). This dichotomy is dangerous. From my point of view, complexity is a natural science, not a social science, whereas cybernetics originates from social science, relying on hypotheses, conclusions, and observations without repeatable experiments.
The Evolution of Complexity Thinking
We must distinguish complexity from systems thinking because complexity represents a quantum shift—a phase shift in how we think about business. Some argue that systems thinking already encompasses complexity, claiming that these ideas were known 100 or even 200 years ago. However, the reality is that just because people observed a phenomenon does not mean they had a scientific explanation for it. When Newton formulated the laws of gravity, the world’s understanding of falling apples fundamentally changed.
Another issue with homogenizing everything under systems thinking is that if "systems thinking" just means "thinking systematically," then it becomes meaningless—because, of course, everyone should think systematically. Distinctions matter in human cognition. We struggle with gradients but understand boundaries clearly.
Additionally, systems dynamics sometimes adopts an engineering model of the human brain, which fails to recognize that human sentiment can be radically different. This also leads to the emergence of what I call “new age fluffy bunny thinking.” Because some things can’t be engineered, ideas like Peter Senge’s and Otto Scharmer’s theories emerge—concepts that, frankly, I see as nonsense. At the extreme end, you have the outright mysticism of Ken Wilber.
What complexity science does is bring these two extremes together. It recognizes that this false dichotomy—between rigid engineering and idealized leadership—is dangerous. And I’ll stop there because that was a far-too-long answer.
Complexity and Business Agility
That was a wonderful explanation, Dave. You clarified a lot of things. Considering that we’re speaking to the Business Agility Brazil community, these are people who are concerned about how complexity connects with agility. Based on your explanation, we see that complexity is about understanding the present moment rather than trying to predict the future. Is that correct?
Yes, in a complex system, you can’t have a future goal because you can’t predict the future. If you set a future goal, the only thing you know for certain is that (A) you won’t achieve it, and (B) goal-seeking behavior will produce unintended consequences that you can’t manage.
So, in complexity, we don’t set fixed future goals. Instead, we start a journey with a sense of direction while remaining open to new ideas along the way. A large part of what we do involves mapping the present, identifying which pathways are possible, and understanding which are not.
Most systems thinking starts with the assumption, “This is where we want to be, and as soon as possible, we need to get there.” But in complexity, that approach is dangerous. Managing complexity requires dealing with the present, not forcing a rigid path to a future state.
Challenges in Scaling Agile
The problem with Agile is that it originated in software development, which is an engineering environment. The mistake is trying to apply Agile as it is—without adaptation—to a business strategy environment. In reality, corporate strategy is 90% politics and 10% evidence. The idea that you can reduce it to two-week sprints and structured Kanban boards is, frankly, nonsense.
That doesn’t mean businesses shouldn’t be agile. Agile scaled only because of its structured approach—Scrum, in particular. If Agile had remained rooted in XP (Extreme Programming), we wouldn’t even be talking about it today. However, the irony is that codifying Agile to scale it results in loss.
The biggest issue is when Agile becomes rigid and over-engineered, like in SAFe. SAFe is essentially Six Sigma on steroids. It allows companies to claim they are Agile without actually being Agile, and it survives because executives invest millions in it—so they can’t admit it failed. Often, by the time its inefficiencies are exposed, those executives have already moved on to another job.
Scaling Complexity in Organizations
You scale a complex adaptive system through decomposition and recombination, not through aggregation or imitation. The key is identifying the lowest possible unit and allowing it to recombine with other components.
For example, if you want to scale Scrum, Scrum itself is too granular. Instead of scaling Scrum as a whole, you need to break it down into its fundamental components and allow those components to recombine in different ways, much like how four simple chemicals combine to form complex organic life.
Final Thoughts
One key takeaway is that different techniques work in different domains, but not all techniques are equally valid. The concept of coherence is crucial—some ideas may be incorrect but still coherent with existing facts, whereas others are entirely incoherent and should be disregarded.
Another important insight is that Kinevin is not a categorization framework; it’s a sense-making framework. It’s about understanding that we exist in multiple domains at the same time, and our perspectives must be fluid rather than rigid.
Thank you for this discussion, and I hope this helps our community navigate the complexity of business and agility.