No. 010Ways of Thinking

Cynefin

First work out what kind of situation you are in, because clear, complicated, complex and chaotic problems each need a different way of deciding.

Work out which kind of situation you are in before choosing how to decide; much architecture work is complex, where you learn by experimenting.

To an executive

Different problems need different management. Demanding a detailed plan for an uncertain problem wastes money, and experimenting on a well-understood one wastes time.

To an engineer

Before choosing an approach, ask whether the problem is clear, analysable, or only understood by trying. Use standards, expert analysis or small safe experiments to match.

The idea

Dave Snowden's Cynefin framework (a Welsh word, pronounced kuh-nev-in) sorts situations by how cause and effect relate, and gives each a way of deciding:

Clear — cause and effect are obvious. Sense, categorise, respond, using best practice.
Complicated — cause and effect can be found by analysis, often by experts. Sense, analyse, respond, using good practice; there may be several right answers.
Complex — cause and effect are only clear in hindsight. Probe, sense, respond: run safe-to-fail experiments and amplify what works. Practice is emergent.
Chaotic — no cause and effect to find in time. Act, sense, respond: stabilise first, then move the situation elsewhere. Practice is novel.

In the centre is Confusion: not knowing which domain you are in. Snowden's naming has changed over time. Older texts, including the 2007 HBR article with Mary Boone, call Clear "Simple" and later "Obvious", and call the centre "Disorder".

Why it works

The method has to fit the problem. Most failures of judgement are not bad analysis but the wrong kind of approach: a detailed plan for a problem that can only be learned, or an experiment where a checklist would do.

It legitimises experimentation. In complex situations, asking for a full business case up front is asking for fiction. Cynefin gives you a reason to fund probes instead.

It warns about complacency. Treating everything as Clear and following best practice blindly can tip a situation into chaos when the world changes.

Where it applies

Transformation and strategy, where operating model or market changes are complex, not merely complicated.
Portfolio governance, to decide which initiatives need a business case and which need a funded experiment.
Incidents and crises, where the first job is to act and stabilise, not to analyse.
Regulatory and compliance work, which is often Complicated: experts and analysis can find the answer.

How to apply

Name the domain together. Ask the group which domain the problem is in, and expect disagreement; that is Confusion, and worth surfacing.
Break it down. Large problems mix domains; split them and treat each part on its own terms.
Match the method. Standards and checklists for Clear, expert analysis for Complicated, small parallel probes for Complex, decisive action for Chaotic.
Watch for movement. As you learn, complex problems can become complicated; as conditions change, clear ones can collapse into chaos.

Example scenario

A public-sector agency wanted a five-year plan to move citizens to digital services, with fixed scope and benefits. The previous attempt had followed a detailed blueprint and delivered systems that few people used.

The enterprise architect split the work. Moving the data centre and meeting accessibility rules were Complicated, so they got expert design and a plan. How citizens would adopt the new services was Complex, so the agency funded three small pilots in different regions, measured uptake and scaled the one that worked. The steering board stopped asking for benefits it could not know yet and started reviewing what each pilot had learned.

Questions to ask

Can an expert tell us the answer, or will we only know by trying something?
Are we applying best practice to a problem that has none?
What small, safe-to-fail experiments could we run before committing?

When not to use it

Routine decisions, where the domain is obvious and naming it adds nothing.
As a sorting exercise alone. Placing problems on the diagram is not the point; changing how you act is.

How it misleads you

People tend to place their problem in the domain that suits their preferred method: engineers see Complicated, change agents see Complex. "It's complex" can also become an excuse to skip analysis that would work. Ask for the evidence that cause and effect really cannot be known before you abandon planning.