Explaining Cynefin for strategy and decision making
I have been teaching the Cynefin framework for a number of years now. Like Dave Snowden i learn as much or more from needing to share it than I do from actually deploying it. I find myself sharing the framework for three applications: strategy and decision making, leadership and basic understanding of complexity. Because the framework is both simple to describe and supported by a deep set of theory and practice, it is always a challenge to make my description simple enough to be understood, but full enough to be appreciated.
So I thought I would put out some step-by-step guides based on how I explain Cynefin to clients and in teaching situations. This is the first one, on using Cynefin to introduce complexity and it’s implications for strategy and decision making. I would love feedback in the comments, especially if I have used terms that are defined poorly or hard to understand, and also if I have made any leaps in logic that are too large to understand in one bound. The goal is simplicity and clarity in description.
Cynefin, complexity and decision making.
1. There are two kinds of systems and problems: ordered and unordered.
2. Ordered problems are predictable and knowable, unordered problems are unpredictable and unknowable. It is important to understand this point deeply, because this is a fundamental distinction that has massive implications.
3. Ordered systems have a reliable causality, that is, causes and effects can be known, and usually display a clear finish line. Sometimes this causality is obvious to everyone, such as turning a tap to control a flow of water. Sometimes this causality is only obvious to experts, such as knowing what causes your car engine to start making strange noises.
4. Unordered systems throw up complex problems and chaos. Complex problems such as poverty and racism, have causality that that only be understood retrospectively, that is by looking back in time, and they have no discernible finish line. We do a reasonably good job of seeing where it came from, but we can’t look at the current state of a system and predict what will happen next.
5. Chaotic problems are essentially crises in which the causality is so wild, that it doesn’t really matter. For example, in the middle of a riot, it does you no good to understand causes until you can get to safety.
6. Because ordered systems display predictable outcomes, we can more or less design solutions that have a good chance of working. We just need to understand the system well enough and enlist the right experts if it’s unclear what to do. Once we have a solution, it will be transferable from one context to another. Designing and building a car, for example.
7. Because unordered systems are unpredictable we need to design solutions that are coherent with the context. For example, addressing the role of stigma in the health care system requires a solution to emerge from the system itself.
8. Complex problems can be addressed by creating many small probes: experiments that tell us about what works and what doesn’t. When a probe has a good result, we amplify it. When it has a poor result, we dampen it. Strategies for amplification and dampening depend on the context, and the problem.
9. In ordered systems, linear solutions with well managed resources and outcomes will produce desired effects. We can evaluation our results against our intentions and address gaps.
10. In complex systems, we manage attractors and boundaries and see what happens. An attractor is something that draws the system towards it. A boundary is something that contains the work. For example addressing the effects of poverty by creating a micro-enterprise loan program that makes money available for small projects (attractor) and requires that it be paid back by a certain time and in a certain way (boundaries). Then you allow action to unfold and see what happens.
11. When you have a solution in an ordered system that works, you can evaluate it, create a process and a training program around it and export it to different contexts.
12. When you have a solution that works in a complex system, you continue monitor it, adjust it as necessary and extract the heuristics of how it works. Heuristics are basic experience based, operating principles that can be observed and applied across contexts. For example, “provide access to capital for women” provides a heuristic for addressing poverty based on experience. Heuristics must be continually refined or dropped depending on the context.
Hello Chris! I’m just starting to read this.
Number 1) I always use the word ‘situations’, instead of problems or systems. For me, that is easier to access for a lot of people. Many people don’t know what is meant with the word systems; and you don’t want to name it only problems, because that really it is not. – it’s situations in my perspective.
– isn’t there a point – 0? – before this. That it is good to know, understand and realize that not all situations are the same, and not all practices apply everywhere.
– 10) – I miss here the point that you need multiple attractors, and not just rely on one – like the micro loans. Isn’t the point of first noticing to where the people are attracted to?
12) so, I would not talk about ‘solution’ here, but either keep the word attractor, or find another word or stress the “a” solution (because even I read it first as “the” solution!)
my little two cents!
from a paradise spot in Greece!
Ria
Thank you Ria!
Hi Chris
Thank you for sharing, it’s very useful!
Some points I’ve found helpful in explaining Cynefin in context of decision making and strategy are:
– the difference between dealing with probablilities in order and millions of possibilities in complex
– desiging a fail-safe solution for one of millions of possible outcomes is a waste of time; multiple paralel safe-to-fail experiments help us discover more about the disposition of the system. Switch from idealised future design to managing the present and finding the potential for evolving forwards. I use the metaphor of laying out a park – you can use a landscape architect to design the ideal layout and have people create their own footpaths between the laid out paths. Or you can plant the grass first, see where people walk and then lay create your paths over the emergent ones.
Hope this is useful!
Terrific. Enjoying this co created search for simplicity.
Chris, I would tend to use constraints instead of boundaries as they cover the general situation. Garvey Berger and Johnston in ‘Simple Habits for Complex Times’ use the term guard rails in place of constraints which is another take.
Great. Looking for dirt simple terms for constraints. Guard rails helps.
Dear Chris, dear everyone. Thank you thank you for all of the clarity you are bringing to the cynefin framework. I use it, I talk about it, I struggle with it, and often wonder wtf I am in it!
Thanks for making the terms and concepts more accessible (dirt simple). Much appreciated.
Contrasts I’ve learned from Cynefin, lectures by David Snowden and others, and Rob England’s “Plus! Standard+Case Approach” (and just now added boundaries vs. constraints from above comments):
Ordered Unordered
Standard Non-standard
Efficiency Effectiveness
Fit for use Fit for purpose
Management Leadership
Training Education
Information Knowledge
Reductionist view Holistic View
Analysis Synthesis
Boundaries Constraints
Rules Heuristics
Processes Frameworks
Robustness Resilience
Quantitative Qualitative
Hi Joseph. There is an effort to make some of these distinctions clear. Some of these I’d take issue with. For example, quantitative and qualitative are both useful in ordered and unordered domains, as are processes and frameworks, information and knowledge, and management and leadership.
Boundaries and constraint are not opposites, but the idea of governing constraints vs. enabling constraints is well articulated in the Cynefin literature.
Hi there Chris,
Thanks for this and all other comments.I also find it important to distinguish between explore and exploit .. and often use the practical example that in complex space we establish learning teams and processes to explore new ideas, while in complicated, project teams will exploit ( and use more traditional project planning and execution type systems and methodologies).