Discovering Cynefin – Trying to Make Sense of a Complex World
Recently at the YOW conference, I was introduced to the Cynefin Framework through a presentation by Liz Keogh. Created by David Snowden, it is a sense making framework, designed to assist understanding and describing problems, situations and systems.
Within my role at Speedwell, I’m often responsible for evaluating, understanding, solving, prioritising and documenting many new experiences, problems and situations. Constantly I experience new clients, new user considerations, new technologies, new techniques, new team members, new team structures, new processes.
I felt this framework will help in my evaluation of situations to help prioritise and act on the data I have, data I need and my instincts.
Cynefin an introduction
Sense making framework vs categorisation framework
The purpose of the framework is to make sense of the data not to categorise it into typically seen classification quadrants. Within a sense making framework, the data precedes the framework instead of the framework categorising the data.
For the Cynefin Framework the lines blur between the areas (except in the case of simple to chaos that’s covered a little later)
Dave Snowden, released under CC BY 3.0
There are three major systems that make up the framework; Complex, Ordered and Chaotic. Ordered is split up into two sections, Complicated and Simple.
In the simple domain, the relationship between cause and effect are predictable and repeatable. This means items can be determined in advance and results are predictable. Within this area, across the board “best practice” procedures can be followed by all involved no matter what expertise they have.
Within Speedwell I see things like fire evacuation procedures and leave form procedures fitting within this area.
Within the complicated domain, there is still a clear and predictable relationship between cause and effect, but these are not self evident and require expertise to determine. This is the area of “good practice” where there are many valid solutions to solving a situation.
Programmers love to live within this area. Cause and effect are clear with expertise and situations are solvable. When we do things over and over in this area, we start to solve how to create libraries and patterns. Caution must be noted that when spending most of the time within the domain, solutions can be prescribed before understanding the underlying complexity of the situation. Our test team are great at asking the “what about” questions and moving solutions back into the complex domain.
Cause and effect are only obvious in hindsight within the complex domain. Often there are many relationships that emerge after investigation that change the model as it grows. In this domain, safe fail experiments are used to solve situations.
Within Speedwell I see our Account Managers and Solution Architecture team working mostly in this domain; probing, sensing and responding. The response is usually asking more questions until enough data is understood that the situation moves its way to the complicated and ordered domain.
There are two ways to enter chaotic. The most common is by accident, for example production issues. The second is by a deliberate decision to innovate and break out of predetermined ideas. These situations are not predictable nor can a clear cause and effect be determined. Decisive action is called for.
Boundaries and the clef
It is important to remember that these domains are not segmented and situations and problems move within the space smoothly. The one area that is different is between simple and chaotic. This is represented with the little clef. It is very easy for a simple situation to push over into chaos if not watched. If there is over-dependence on order and simplicity, complication and complexity may not be recognised and responded to appropriately. When a situation arises that no rule covers, then chaos is the result.
Disorder is not understanding which domain the situation/problem sits within. When in this domain, people will fall to their own desire and reactions. For example:
- Those used to a mandated corporate environment will try to solve by simply claiming more processes are needed.
- Those who work often in the complicated area (analysts and programmers) will cite a lack of time for analysis.
- Those who often work in the complex area (managers, politicians) will try to pull a lot of people together.
- Those who work in the chaos area will go into dictator mode expecting everyone to follow their exact instructions.
In an analyst role, I’m often challenged with bringing very wide client ideas into reality. During this process, prioritisation is required to investigate the unknowns.
This can sometimes feel overwhelming. Part of Liz’s presentation was on prioritisation giving the parable of the streetlight effect as an introduction.
A policeman sees a drunk man searching for something under a streetlight and asks what the drunk has lost. He says he lost his keys and they both look under the streetlight together. After a few minutes the policeman asks if he is sure he lost them here, and the drunk replies, no, that he lost them in the park. The policeman asks why he is searching here, and the drunk replies, “this is where the light is.”
As this ended, I recognised that I have been guilty on occasion of this in the past. It is very easy to get lost in creating systems that you can see the solution to instead of investigating the underlying more complex problems that will cause bigger failure later down the track.
Liz presented the concept of using the framework to model the known data. I often map out systems and components in order to understand the bigger picture so I’m keen to try placing this data in this system and growing a model showing which areas need focus first.
Remembering that models are there to assist understanding not dictate categorisation, I believe Cynefin can help us become aware of the current situation, assist in evaluating priorities and give direction on the action required.
References and further reading
The Cynefin Framework – Presentation by David Snowden