The Cynefin Framework

What does the word ”Cynefin” mean?

The word “Cynefin”, pronounced ki-neh-vin, is a Welsh word that cannot be directly translated into English. However, it is commonly translated as ‘habitat’ or ‘place’ and means a place of multiple belongings. We are all rooted in many different pasts which profoundly influence who we are, but of which we are only partially aware. i.e. geographic, tribal, religious, cultural, etc.

Origins of Cynefin

Cynefin was first developed by Dave Snowden in 1999 in the context of knowledge management and organisational strategy. By 2002, it had developed to include complex adaptive systems theory. It was further developed and elaborated with Cynthia Kurtz as part of their work with the IBM Institute of Knowledge Management, and by Mary Boone to extend the model to Leadership. It appeared as the cover feature in the Harvard Business Review in 2007 in the context of leadership.

What is Cynefin?

Cynefin is a decision framework that recognises the causal differences that exist between different types of systems, proposing new approaches to decision making in complex social environments. Cynefin is also a sense-making model, not a categorisation model. In a categorisation model, the framework precedes the data. This is good for exploitation but not exploration. In a sense-making model the data precedes the framework, making it good for exploration.

The 3 basic types of systems involved in Cynefin are; ordered, complex and chaotic. Ordered systems are divided into 2; simple and complicated. There are 5 domains in total; Simple, Complicated, Complex, Chaotic and Disorder (in the middle of the image above).

Before we move on to describe the various domains, I hope that the two sentences below will help you understand why Cynefin can be so beneficial for us:-
We need to think differently about different problems. There is no one size fits all approach and the actions you take depend on which domain you are in.

1. The Simple Domain

In the simple domain we are in an ordered system where the relationship between cause and effect exists, is predictable in advance and is self evident or obvious to any reasonable person.

We apply best practises and the approach is to:-
SENSE — CATEGORISE — RESPOND
Sense           – See what’s coming in
Categorise  – Make it fit predetermined categories
Respond     – Decide what to do

Eg. A clerk in a banking institution calculating compound interest. Best practise is applied in terms of predefined formulae and given an input the results are always the same.

2. The Complicated Domain

In the complicated domain we have an ordered system where there is a right answer and where a relationship does exist between cause and effect, however, the answer is not self-evident and requires analysis and/or the application of expert knowledge. There can be several different ways of doing things in this domain, with the right expertise.

We apply good practise and the approach is to:-
SENSE — ANALYSE — RESPOND
Sense      – See what’s coming in
Analyse  – Investigate or analyse, using expert knowledge
Respond – Decide what to do

Eg. Anything that can be solved with professional training or external consulting services, like the need to develop software in a specific language (ie. C# or Java).

3. The Complex Domain

In the complex domain we have unorder where the relationship between cause and effect can only be perceived in retrospect and the results are unpredictable. Complex systems are therefore dispositional and not causal. Here, we need to create safe to fail experiments and not attempt to create fail safe design. We cannot solve complex problems with best or good practices alone. While conducting safe to fail experiments, we must dampen the parts that fail and amplify the parts that succeed. In this domain we get emergent order and practice that is often unique.

Emergent practice, behaviour or order results and the approach is to:-
PROBE — SENSE — RESPOND
Probe      – Experimental input
Sense      – Failures or successes
Respond – Decide what to do ie. amplify or dampen

Eg. Most types of innovation. Professional training or best practices are replaced with probing different approaches and ideas, sensing the results/feedback to see what works and what doesn’t, and responding appropriately (by amplifying and dampening our probes).

4. The Chaotic Domain

In the chaotic domain no cause and effect relationship can be determined. We have to stabilise the position very quickly!

We discover novel practice and the approach is to:-
ACT — SENSE — RESPOND
Act           – Attempt to stabilise
Sense      – Failures or successes
Respond – Decide what to do next

Eg. A medical emergency situation.

Note: It is possible for a problem to fall into more than one domain simultaneously. I will show an example of this at the end of the post.

5. The Domain of Disorder

This domain includes the state of not knowing what type of causality exists or what space you are in. The problem here is that we interpret and assess the situation we are in based on our personal preference for action, reverting to our own comfort zones.

For the sake of completeness

Transitions can occur from the Simple to the Chaotic domains. Here you ‘fall over the edge’ and any recovery is extremely expensive. For this reason, we should attempt to manage things in the complicated and complex domains.

Using Cynefin

Cynefin has been used for analysing policymaking within the George W Bush administration and the impact of religion in that process, the nature of response to bioterrorism, as well as aspects of measurement in the British National Health Services. It’s also been used for the retrospective study of emergency situations and to study the interaction between civilians and the military during disaster control.

That’s all great – you might be thinking – but how can I use it?
Consider this: – if you spend 2-3 years in a process based bureaucratic role, you’ll tend to see all problems as failure of process. If you’re an expert in a particular field, you’ll tend to see any problem as a failure to give you the necessary time or resources to do your expert analysis. We therefore have a natural tendency to categorise problems based on our own knowledge, skills and previous experiences.

Let’s take the subject of software quality as an example.

You might be forgiven for thinking that by applying best practice techniques such as BDD, TDD, Pair Programming, Code Analysis (cyclomatic complexity, etc), Automated Integration Testing, Automated Regression Testing, that you will be able to build a near bug free software product. However, what if for example, your business logic is contained in your database layer’s code in stored procedures? If you could unit test the stored procedures would you still need your 90+% unit test coverage in your application code? Would you still need as many automated integration tests? Or would you even perhaps decide to put even more effort into the automated integration testing and not unit testing? Software quality has elements in all the Cynefin domains. There are best practices and good practices that we should make use of. However, in context of the discussion here; in my opinion, the complex parts require us to create safe to fail experiments, trying different approaches, observing their results, and then dampening or amplifying elements of your experiments along the way to see what works best in your context.

Conclusions

When you’re next faced with a problem, question your immediate problem solving approach. See if the problem can indeed be tackled with best or good practice or whether you need to do a little probing, sensing and responding. Finally, we probably all agree that the incremental delivery of software with frequent short feedback loops is the approach we should use; releasing small bits of high value software, receiving feedback, reflecting, adapting, and repeating. Does this not sound complex to you?

Written by: Mark Nilsen of Derivco