What Is Cynefin?
Cynefin (pronounced kuh-NEV-in) is a sense-making framework developed by Dave Snowden at IBM in 1999 and refined over the following two decades. The word is Welsh, loosely translated as "habitat" or "place of belonging" - the idea being that we are always embedded in contexts that shape how we perceive and respond to problems, often without realising it.
The framework does not tell you what to do. It tells you what kind of situation you are in - and therefore what kind of thinking, process, and leadership stance is appropriate. That distinction is more valuable than it sounds. Most organisational dysfunction stems not from a lack of capability but from applying the wrong approach to the wrong type of problem. Cynefin is a corrective to that.
It describes five domains: Clear, Complicated, Complex, Chaotic, and Confused. Each requires a fundamentally different operating model.
The Five Domains
Clear (formerly Simple or Obvious)
In the Clear domain, the relationship between cause and effect is self-evident. Everyone can see it. The correct response is categorisable and repeatable. Sense → Categorise → Respond.
This is the domain of best practices. You identify what type of problem it is, apply the known solution, and move on. Examples include: processing a standard expense claim, resetting a user's password, deploying via a well-rehearsed runbook.
The danger of this domain is complacency. Because things feel stable and obvious, teams stop questioning the rules. They build elaborate processes and then assume those processes are correct forever. Snowden calls this the risk of being "lulled into the Clear" - and then being blindsided when the context shifts and the situation has actually become Chaotic. Best practice has a shelf life. The mistake is treating it as permanent truth.
Complicated
The Complicated domain is the home of expertise. Cause and effect exist, but the relationship requires analysis, investigation, and specialist knowledge to understand. The right answer is knowable - but not by everyone, and not without effort. Sense → Analyse → Respond.
This is the domain of good practices (plural, not singular). There is more than one right answer, and experts can legitimately disagree. Engineering architecture, legal strategy, financial modelling, surgical decisions - these are Complicated problems. You need the right people in the room, and you need time for analysis.
The danger here is expert overconfidence. Experts trained in Complicated thinking tend to reach for analysis when the situation is actually Complex. They apply known models to genuinely novel situations, and then wonder why the models keep failing. The more credentials a person has, the more susceptible they can be to this trap - because their whole identity is built around having the right answer.
Complex
The Complex domain is where cause and effect can only be understood in retrospect. There is no correct answer in advance. The system is adaptive - it changes in response to being observed and influenced. You cannot simply apply known solutions because the problem has never existed in quite this form before. Probe → Sense → Respond.
This is the domain of emergent practice. The right approach is to run safe-to-fail experiments - small, parallel probes designed to amplify what works and dampen what does not. You do not plan in detail. You create conditions, observe outcomes, and adapt.
Most of software product development lives here. So does organisational change, team culture, market positioning, and strategy. These are not Complicated problems that more analysis will solve. They are Complex problems that require humility, experimentation, and iteration.
The failure mode in Complex is attempting to import Complicated-domain tools - detailed upfront planning, exhaustive requirements, fixed delivery commitments - into a domain where those tools do not apply. This produces the illusion of control whilst generating actual chaos.
Chaotic
In the Chaotic domain, there is no perceivable cause-and-effect relationship. The situation is turbulent. You do not have time to analyse. Act → Sense → Respond.
The goal in Chaos is not to find the right answer - it is to move the situation out of Chaos into a domain where sense-making is possible. Leaders in this domain must act decisively, even without full information. Novel practices are the norm because there is no time for anything else.
Production incidents, security breaches, and organisational crises often start here. The instinct to do nothing whilst gathering information is the worst response. Act first - even if imperfectly - then learn.
Once stability is achieved, resist the urge to immediately formalise what worked as a procedure. What helped in Chaos was a response to Chaos. It may not be appropriate in Complicated or Complex conditions.
Confused (The Centre)
Confused is the domain in the middle - the state of not knowing which domain you are in. It is not a stable place; it is a transitional state of disorientation.
The danger of Confused is that people default to their preferred domain. Engineers default to Complicated and reach for analysis. Leaders who prefer stability default to Clear and reach for process. Those who are comfortable with ambiguity may drift toward Complex when the situation is actually Chaotic. Confused is where the most consequential mistakes happen, because the response feels appropriate to the individual even when it is entirely wrong for the context.
The discipline of Cynefin is learning to recognise which domain you are in before choosing a response - and doing so honestly, not based on preference.
Why This Matters for Key Results
OKRs have been adopted widely enough that the word "key result" is now almost meaningless. In most organisations, key results are actually outputs - tasks completed, features shipped, tickets closed. That is not a key result. That is a to-do list with a deadline.
The reason this happens is that people are uncomfortable with uncertainty. If you write a key result as "increase customer retention by 12%", you do not know yet how you will achieve it. That feels vulnerable. So teams hedge: they write "ship the onboarding redesign by Q3" - something they can control. The output becomes the goal.
Cynefin exposes exactly why this instinct, though understandable, is wrong.
In Complex domains, you cannot specify outputs in advance. The whole point of operating in complexity is that you do not know which actions will produce which results. Writing output-based key results in a Complex environment is a category error. You are pretending you are in the Complicated domain - where cause and effect are knowable - when you are actually in the Complex domain, where they are not.
The correct response is outcome-based key results. Define the change you want to see in the world - the customer behaviour, the business result, the capability shift. Then run experiments to probe toward it. Some probes will work. Most will not. The ones that work become your next iteration.
This is not a licence for vagueness. A good outcome-based key result is measurable, meaningful, and challenging. "Increase the percentage of users who complete a second session within seven days from 34% to 55%" is outcome-based, measurable, and clearly anchored in real user behaviour. It does not specify the solution. It should not. In a Complex domain, specifying the solution before you have run experiments is hubris disguised as planning.
Matching Operating Models to Domains
| Domain | Nature of the problem | Appropriate practice | Leadership stance |
|---|---|---|---|
| Clear | Cause and effect are obvious | Best practice | Delegate and monitor |
| Complicated | Cause and effect require analysis | Good practice | Consult experts |
| Complex | Cause and effect emerge retrospectively | Emergent practice | Experiment and learn |
| Chaotic | No discernible cause and effect | Novel practice | Act decisively |
| Confused | Domain unknown | Identify the domain first | Slow down and sense-make |
The most consequential thing a leader or team can do is resist the pull to collapse all problems into their preferred domain. The Complicated thinker who treats every problem as a puzzle to be solved, the visionary who treats every problem as an invitation to improvise - both are dangerous when deployed in the wrong context.
Cynefin in Engineering Practice
Several concrete engineering practices make more sense when viewed through a Cynefin lens:
Definition of Done is a Clear-domain tool. It codifies agreed standards so that teams do not have to relitigate what "done" means on every story. It is appropriate because code quality standards, testing requirements, and deployment criteria genuinely are categorisable.
Architecture Review Boards are a Complicated-domain tool. They bring expert analysis to bear on decisions that require it. The danger is when they are applied to Complex problems - product strategy, team topology, organisational design - where expert opinion should be an input to experimentation, not a gate.
Feature flags and trunk-based development are Complex-domain tools. They make experimentation cheap and reversible. They allow teams to probe at scale, to run A/B tests, to ship incrementally and observe what happens, to roll back without ceremony. These are the engineering primitives of operating safely in complexity.
Incident response must bridge Chaotic and Complicated. The initial response is Chaotic - act fast to restore stability. The retrospective is Complicated - analyse what happened and why. Conflating the two (trying to do root cause analysis during the incident, or acting with Chaotic urgency during the retrospective) produces worse outcomes from both.
The Deeper Lesson
Cynefin is not primarily a project management framework or a way of categorising your backlog. It is a way of thinking about the nature of knowledge and control.
The assumption embedded in most management practice - that problems are knowable, that planning produces predictability, that process produces outcomes - is a Complicated-domain assumption. It is appropriate in Complicated domains. It is actively harmful in Complex ones.
Most of the interesting and important work organisations do is Complex. Strategy is Complex. Culture change is Complex. Product-market fit is Complex. Building high-performing teams is Complex. None of these can be planned, specified, and delivered. They can only be shaped - through deliberate experimentation, honest observation, and the humility to change course when the evidence demands it.
That is what outcome-oriented key results are really expressing: not "we do not know what we want", but "we know what success looks like, and we are honest enough to admit we do not yet know the path." In Complex domains, that is not weakness. It is the only intellectually honest position available.
The framework cannot make Complex problems simple. Nothing can. But it can help you stop pretending they are - and that is a significant first step.
