We are surrounded by and immersed in complex adaptive systems. Yet, most people don't seem aware of the concepts, even though they have to interact with these complex systems every day. This blog is a bridge between our research in complex adaptive systems and "the real world," where people can apply the knowledge from the research.
One of the problems with current strategy development techniques is that they vastly overestimate predictability. At a very high level, these techniques involve identifying the desired future state, and then listing circumstances that might help or hinder achieving that future state. Basically, this means listing challenges and figuring out in advance how to overcome them. It's called scenario development.
If the future were perfectly predictable, there would be no need for scenario development. Everyone would know what's going to happen. That isn't the case, though. The future holds uncertainty, and the scenario development is an attempt to deal with that uncertainty. In complex environments, however, the future is sufficiently uncertain that developing scenarios is, well, almost useless, other than from an understanding perspective.
If the future is perfectly predictable, our scenarios would match one-to-one with what happens. The scenarios would have a 100 percent accuracy. For example, if we play a game where we flip a coin, we have two scenarios: heads and tails. Our strategy, then, has an action for heads, and an action for tails. "Heads" and "tails" are the two scenarios, and we have 100 percent knowledge of the conditions we have to accommodate.
Business environments, however, don't deal with such simplistic conditions. The number of variables is high, they're often continuous rather than discrete, and simply listing them can be an impossible task. Scenario development, under those conditions, becomes an exercise of asking "experts" or "business leaders" what they think is likely to happen, or doing it ourselves, and then guessing at the probabilities of those events. Often, it ends up being a list of goals and a plan for accomplishing them, with two or three possible challenges for each goal, along with some ideas for dealing with those challenges. These "strategies" may have ten goals, and three or four scenarios associated with each, for a sum total of 30 or 40 scenarios. (Or, worse, they don't list scenarios at all - they just state the goals.)
Let's consider a game again. This time, two players each role a die. Their game strategy depends on the outcome of the die roll. This requires 36 scenarios.
Are we really saying that running a business is no more complex than a game involving two dice?
No? Then our approach to developing strategy is deficient!
The problem here is that people developing strategies believe A) they can predict the future very accurately, B) they have significant control over events, and C) the systems are not complex. All three of these are demonstrably wrong.
A much more effective approach is to acknowledge these realities and change the way we talk about strategy. A general strategic framework includes four things:
Robustness, as I've said before, is feature persistence across structural change. The first step in developing a strategy is to determine what features need to be persistent. These should be phrased as behaviors or characteristics, rather than specific structures. For example, state the feature as "supply chain logistics management" instead of "leverage ABF and FedEx for raw material delivery." Robust features can absorb environmental or internal changes and continue to function. If there are critical capabilities that are dependent on structure (such as a physical location), then the strategy should include enhancements to make those capabilities robust.
Dynamics are the trajectories of critical dimensions over time, and the interactions and dependencies amongst them. If your customer satisfaction and loyalty are both skyrocketing, your strategy may be to maintain that direction, but if your customer satisfaction and loyalty are plummeting, the strategy is (probably?) to change the direction. The questions to ask are, "what are the important dynamics" and "what are trends?" The follow-on questions include
What kinds of events will change these dynamics?
What do we do if those events occur?
What other things will these dynamics affect?
Sensing is our ability, and the system's ability, to foresee critical changes in the system dynamics in sufficient time to adapt to the impending change. At the Santa Fe Institute they have used the phrase "regime shift" to describe these changes. In physics it's a phase transition. Regardless, a critical change is a perturbation (exogenous or endogenous) that materially changes our ability to deliver persistent features. If our strategy has created robustness, the perturbation may not require a change in execution. If we know, however, that we must adapt or mutate in response to the perturbation, we need sufficient lead time.
Agility is the system's ability to mutate or adapt to critical changes, and it's usually measured in terms of rate of change. More agile systems can adapt quickly to changing conditions. Less agile systems need better sensing and predicting!
There are two significant challenges with this approach. First, it's still dependent on our ability to recognize and understand the dynamics; it's not clear that we can do this well. Second, we have to be able to describe and phrase the results in ways that are understandable and acceptable to non-scientists. We can't underestimate the importance of the latter challenge. Trust me - you can't go to a business leader and start talking about "exogenous perturbations" without losing their attention. It's the translation and presentation problem that seems to be the most difficult to overcome.
One of my current areas of research is strategy development, with the intent of using lessons from complex systems research to guide or advice the development of business strategy. I had a wonderful discussion with Denise Easton yesterday, with a good amount of time spent on this topic. I realized during this discussion that many of the ideas I have on this subject are, surprisingly, not common knowledge.
A major problem with current strategy development is in the predictability of the system. Complex adaptive systems are notoriously difficult to predict, primarily because
There are often an overwhelming number of variables to consider.
The dynamics of the systems create emergent behaviors, which cannot be predicted from decomposing the system into individual components.
The dynamics of the systems are generally poorly understood.
Fundamentally, many business strategies focus on the desired outcome. They then create a plan to achieve that desired outcome. The problem with this, of course, is that the desired outcome is just one of a large number of possible futures. From simple statistics, the probability that the future is not the desired outcome is much higher than the probability that the future is the desired outcome.
To make matters worse, the activities used to achieve the strategic goal will change the system, and those changes will be, by the very nature of complex systems, difficult or impossible to predict. In the end, the chances that a strategy will "succeed" are dramatically lower than the chances the strategy will "fail." This conclusion is supported by both Duncan Watts (in his book "Everything is Obvious, Once You Know the Answer") and Michael Mauboussin (in his book, "Think Twice").
If, then, current approaches to strategy are more likely to fail than succeed, how do we change the approach to improve performance?
There are two critical aspects to "strategy" in complex environments: robustness and agility. Shifting focus to these concepts during strategy development, instead of a particular "future configuration," improves the chances of success.
Robustness is feature persistence across structural change in the system. This means that a robust behavior will exist regardless of dramatic environmental changes, or changes in the system. For example, a robust service will continue to function if, say, 80 percent of the components are removed. Or, in a technology environment, the system will continue to exhibit the behavior if the hosting model changes.
Agility, contrary to popular usage, is not "doing stuff faster," it's a measure of the organism's ability to adapt to changing environments. It's not a "speed of execution" measure, it's a "rate of change" measure. In a biological system, it's the mutation rate that governs how quickly the organism evolves. There is also the concept of an energy boundary for an organism (or organization). If you push adaptation/mutation (or agility) beyond that energy boundary, you will, as David Krakauer says, "remove the brakes from the car," and the organism will never stabilize on an optimum - it will just keep mutating rather than stabilizing.
The key to a strategy, then, is to balance robustness and agility. To some extent, you can balance lack of robustness with increased agility: if the environment changes in a way that you can't continue to inherently provide a critical feature, it might be ok, provided you have the organizational ability to mutate to meet new conditions. The trouble appears when an organization can no longer provide critical features, and cannot adapt rapidly enough to the new environment. That's a disruptive change, and can lead to organizational failure.
The other thing to remember is that robustness comes with a price. If your organization focuses on cost optimization, efficiency metrics, and high degrees of specialization, you are by definition creating a fragile (i.e., not robust) structure. That'll make you a great competitor, provided your environment doesn't change - and the one thing we know from experience is that the environment will always change. More about this in the next post.