Contents
Use this when you're about to act on a problem and need to know what kind of problem it actually is. The Cynefin Framework sorts situations into domains — clear, complicated, complex, chaotic, and disorder — so you can match your response to the nature of the challenge rather than defaulting to the same playbook regardless of context.
Section 1
What This Tool Does
The most expensive mistake in decision-making isn't choosing the wrong option. It's applying the right answer to the wrong kind of problem. A founder who treats a complex market-entry challenge like a complicated engineering problem will build beautiful plans that shatter on contact with reality. A crisis leader who treats a chaotic supply-chain collapse like a complex system requiring patient experimentation will watch the building burn while gathering data. The mismatch between problem type and response type destroys more value than any individual bad decision — because it doesn't just produce the wrong answer, it produces the wrong kind of answer, and the team won't even recognise the error until the damage is done.
Dave Snowden developed the Cynefin Framework (pronounced kuh-NEV-in, from the Welsh word for habitat or place) in 1999 while working at IBM's Institute for Knowledge Management. His insight was deceptively fundamental: not all situations have the same relationship between cause and effect, and the appropriate decision-making approach depends entirely on which cause-and-effect relationship you're facing. In a clear domain, cause and effect are obvious to everyone — sense, categorise, respond. In a complicated domain, cause and effect exist but require expertise to identify — sense, analyse, respond. In a complex domain, cause and effect are only coherent in retrospect — probe, sense, respond. In a chaotic domain, there is no perceivable relationship between cause and effect — act, sense, respond. And then there's disorder: the state of not knowing which domain you're in, which is where most teams actually operate most of the time.
The framework's core intervention is forcing you to diagnose the nature of the situation before prescribing a response. That sounds obvious. It isn't. The default human behaviour is to treat every problem as if it belongs to the domain you're most comfortable in. Engineers default to complicated-domain thinking: analyse, find the right answer, implement. Entrepreneurs default to complex-domain thinking: experiment, iterate, pivot. Military commanders default to chaotic-domain thinking: act decisively, establish order, then assess. None of these defaults is wrong — each is perfectly suited to its native domain. The damage happens when the default gets applied to the wrong domain. An engineer's analytical rigour becomes analysis paralysis in chaos. An entrepreneur's experimental mindset becomes reckless in a complicated system where the right answer is knowable. A commander's decisive action becomes destructive in a complex system where the intervention itself changes the dynamics.
Snowden's framework has evolved since 1999. The "simple" domain was renamed "clear" (and later "obvious" in some versions, then back to "clear") to avoid the implication that the problems themselves are trivial. The boundaries between domains — which Snowden calls "liminal zones" — received more attention, particularly the cliff edge between clear and chaotic, where complacency in seemingly obvious situations leads to catastrophic failure. The framework is not a 2×2 matrix. It's not a spectrum. It's a sense-making model — a tool for understanding what kind of understanding is even possible in your current situation.
Section 2
How to Use It — Step by Step
Instructions on the left. Worked example — "A Series B fintech company must decide how to respond after its primary banking partner announces it will terminate their BaaS (Banking-as-a-Service) agreement in 90 days" — on the right.
Step 1 — Assess
Identify the cause-and-effect relationship in your situation
Ask the diagnostic question: can we determine the relationship between actions and outcomes? If the answer is "yes, and it's obvious to everyone," you're in the clear domain. If "yes, but we need expert analysis," you're in complicated. If "only in retrospect — we can't predict outcomes in advance," you're in complex. If "there is no discernible relationship right now," you're in chaotic. If you can't agree on which of these is true, you're in disorder — and your first job is to break the situation into parts that can be classified separately. Most real situations contain elements in multiple domains simultaneously.
Worked example
Fintech BaaS termination
The team maps the situation and realises it spans multiple domains. Chaotic: the company has 90 days before its core infrastructure disappears — customers can't transact without a banking partner, and there's no backup. Immediate survival is at stake. Complicated: evaluating and integrating a new BaaS provider is a technical and regulatory challenge with knowable answers — the right partner exists, but finding and vetting them requires expertise. Complex: how customers, regulators, and competitors will respond to the transition is unknowable in advance. The team resists the urge to treat the entire situation as one domain.
Step 2 — Decompose
Separate the situation into domain-specific components
Most strategic challenges are not purely in one domain. Break the situation into its constituent parts and classify each independently. A product launch might have clear elements (regulatory filings with known requirements), complicated elements (engineering architecture decisions), and complex elements (market adoption dynamics). Treating the whole situation as one domain is the most common Cynefin error. The framework's power comes from applying different approaches to different parts of the same problem simultaneously.
Worked example
Decomposing the BaaS crisis
The team creates three workstreams, each mapped to its domain. Chaotic workstream: immediate customer communication and interim transaction handling — act now, stabilise, then assess. Complicated workstream: BaaS provider evaluation — assemble a team of compliance, engineering, and partnership experts to analyse options and select the best replacement. Complex workstream: customer retention and competitive positioning during the transition — design small, safe-to-fail experiments (beta migration cohorts, competitor monitoring, customer sentiment probes) rather than committing to a single grand retention strategy.
Step 3 — Match
Apply the domain-appropriate response pattern
Each domain has a prescribed decision sequence. Clear: sense → categorise → respond. Apply best practice. Don't overthink it. Complicated: sense → analyse → respond. Bring in experts. Evaluate options. Choose the best (not perfect) answer. Complex: probe → sense → respond. Run safe-to-fail experiments. Amplify what works, dampen what doesn't. Accept that you cannot predict outcomes. Chaotic: act → sense → respond. Stabilise first. Any action that reduces harm is better than waiting for perfect information. Analyse later. The critical discipline is resisting your default response pattern when it doesn't match the domain.
Worked example
Matching responses to domains
Chaotic response: The CEO records a video for all customers within 24 hours — honest, specific, with a concrete interim plan. The engineering team activates a manual transaction-processing fallback. No committee approval, no legal review of the script. Speed over polish. Complicated response: The CTO assembles a four-person evaluation team. They create a weighted decision matrix for seven potential BaaS providers, scoring on API compatibility, regulatory coverage, migration timeline, and pricing. They schedule deep-dive calls with the top three. Complex response: The head of growth launches three parallel experiments — a loyalty incentive for high-value customers, a transparent "migration diary" blog series, and a private beta of the new platform with 200 power users — to learn what actually drives retention during disruption, rather than guessing.
Step 4 — Monitor
Watch for domain shifts and adjust your approach
Domains are not static. A chaotic situation stabilises and becomes complex. A complex market matures and becomes complicated. A clear process gets disrupted and becomes chaotic. The most dangerous transition is the cliff edge from clear to chaotic — when a team becomes complacent in a seemingly stable environment and fails to notice the ground shifting beneath them. Build explicit checkpoints to reassess which domain each component of your situation occupies. The response that was correct last week may be catastrophically wrong this week.
Worked example
Domain shifts during the 90-day window
By week three, the chaotic workstream has stabilised — the manual fallback is working, customers are informed, churn is elevated but not catastrophic. That component shifts from chaotic to complex: the team can now experiment with different communication cadences and support models rather than just firefighting. By week six, the complicated workstream delivers its recommendation: a specific BaaS provider with a 45-day integration timeline. That component shifts from complicated to clear: the integration steps are documented, the API specs are known, execution follows a defined playbook. The complex workstream — customer retention — remains complex throughout. No amount of analysis will make customer behaviour predictable during a platform migration. The team keeps probing.
Section 3
When It Works Best
✓
Ideal Conditions for the Cynefin Framework
| Dimension | Best fit |
|---|---|
| Situation type | Multi-faceted challenges where different components require fundamentally different approaches. Mergers, market entries, crisis responses, organisational transformations — any situation where the team's instinct is to apply a single methodology across the board. |
| Decision stage | The very first step — before any analysis, planning, or action. Cynefin is a pre-diagnostic tool. It determines what kind of thinking is appropriate, which means it must precede the thinking itself. Using it after you've already committed to an approach is like checking the map after you've driven for an hour. |
| Team dynamics | Teams with diverse functional backgrounds who default to different problem-solving approaches. Engineers, salespeople, and operators will instinctively classify the same situation differently. Cynefin gives them a shared language for that disagreement — which is often more valuable than resolving it, because the disagreement itself reveals that the situation spans multiple domains. |
| Uncertainty level | Highest value when uncertainty is high and the team is unsure whether more analysis will reduce it. The framework's complex domain explicitly acknowledges that some uncertainty is irreducible — you cannot analyse your way to an answer, only experiment your way toward one. This permission to stop analysing and start probing is often the most valuable output of a Cynefin assessment. |
| Organisational maturity | Organisations that have enough process discipline to follow different playbooks simultaneously. Cynefin asks you to run best-practice execution, expert analysis, and safe-to-fail experiments in parallel — on different parts of the same problem. That requires operational sophistication. Teams that can only do one thing at a time will struggle to implement the framework's recommendations. |
| Stakes | High-stakes situations where applying the wrong approach is more dangerous than the wrong specific decision. A startup burning cash on elaborate scenario planning for a chaotic market (when it should be acting and learning) is a Cynefin failure. So is a regulated enterprise running "move fast and break things" experiments in a complicated compliance domain where the right answer is knowable and the cost of getting it wrong is existential. |
Section 4
When It Breaks Down
⚠
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| Misclassification bias | Teams classify situations into the domain that matches their preferred working style, not the domain that matches reality. Data-driven teams call everything "complicated" because they want to analyse. Startup teams call everything "complex" because they want to experiment. The framework becomes a mirror of team identity rather than a diagnostic of the situation. | Use external facilitators or red-team the classification. Ask: "What evidence would prove we're in a different domain?" |
| Static classification | The team classifies the situation once and never revisits. Domains shift — sometimes rapidly. A chaotic situation stabilises. A clear process gets disrupted. Teams that lock in their initial classification miss these transitions and keep applying an outdated response pattern. | Build weekly domain-reassessment checkpoints into any multi-week initiative |
| Whole-problem classification | The team treats the entire situation as belonging to a single domain instead of decomposing it. "Our market entry is complex" — but the regulatory filing is clear, the competitive analysis is complicated, and only the customer adoption dynamics are truly complex. Single-domain classification leads to under-responding on some components and over-responding on others. | Decompose the situation into 3–5 components and classify each independently |
| Complexity as excuse for inaction | Teams use the "complex" classification to avoid commitment. "We can't predict outcomes, so let's just keep experimenting" becomes a permanent state. The complex domain calls for safe-to-fail probes — but probes must have defined success/failure criteria and timelines. Perpetual experimentation without convergence is not complexity-appropriate; it's indecision wearing a sophisticated label. | Pair with OODA Loop to enforce decision tempo even in complex domains |
| Framework as taxonomy only | The team uses Cynefin to label the situation — "this is complex" — but doesn't change their behaviour. They still build detailed plans, still seek expert consensus, still try to predict outcomes. The classification becomes an intellectual exercise rather than a behavioural intervention. The value of Cynefin is entirely in the response it prescribes, not the label it assigns. | For each domain classification, write down the specific response protocol and hold the team accountable to it |
| Disorder avoidance | The central domain — disorder, the state of not knowing which domain you're in — is the most common real-world state and the one teams are least willing to acknowledge. Admitting "we don't know what kind of problem this is" feels like weakness. So teams force a classification prematurely, and the wrong classification produces the wrong response. Disorder is not a failure state; it's the honest starting point. | Spend time in disorder deliberately. Use Reframing or Abstraction Laddering to explore the problem from multiple angles before classifying |
The most dangerous failure mode is misclassification driven by organisational identity. It's not that teams can't understand the framework — the domains are intuitive, the logic is clean. The problem is that classification feels objective but is deeply subjective. A consulting firm will classify almost any client situation as "complicated" because their entire business model is built on expert analysis. A venture-backed startup will classify almost any challenge as "complex" because their culture valorises experimentation and iteration. Neither is lying. Both are seeing the situation through the lens of their capabilities rather than the lens of the situation's actual dynamics.
The protection is adversarial classification. After the team agrees on a domain, assign someone to argue for a different one. If the counter-argument is easy to dismiss, the original classification is probably right. If it's uncomfortably persuasive, you may be in disorder — and the honest response is to decompose further before committing to a response pattern.
Section 5
Visual Explanation
Cynefin Framework — populated with the fintech BaaS termination worked example. Each domain shows the appropriate decision sequence and the specific workstream mapped to it.
Section 6
Pairs With
Cynefin is a meta-tool — it tells you what kind of tool to reach for next. Its value is almost entirely upstream: it shapes the approach, then hands off to domain-specific methods for execution.
Use before
Reframing
Before you classify a situation into a Cynefin domain, challenge whether you're framing the situation correctly. A problem that looks chaotic ("our revenue collapsed") may reframe into something complicated ("three enterprise clients churned for identifiable reasons") or complex ("our market category is being redefined"). The domain classification is only as good as the problem framing that precedes it.
Use after
OODA Loop
In chaotic and complex domains, the OODA Loop (Observe, Orient, Decide, Act) provides the operational tempo that Cynefin prescribes but doesn't specify. Cynefin tells you to "act, then sense" in chaos — OODA gives you the rhythm for doing that repeatedly at speed without descending into reactive thrashing.
Use after
Decision Matrix
Once Cynefin identifies a complicated-domain component, a Decision Matrix is the natural next step. The complicated domain calls for expert analysis and option evaluation — exactly what a weighted scoring matrix delivers. Don't use a Decision Matrix in the complex domain, though. You can't score options when you can't predict outcomes.
Use after
Pre-Mortem
In the complex domain, where outcomes are unpredictable, a Pre-Mortem helps you design better safe-to-fail experiments. Before launching a probe, imagine it has failed spectacularly. What happened? This surfaces risks you wouldn't have considered and helps you define the "fail" criteria that make a safe-to-fail experiment actually safe.
Use after
Second-Order Thinking
Complex-domain situations are defined by emergent, non-linear dynamics. Second-Order Thinking — asking "and then what?" — helps you anticipate how your probes might interact with the system in unexpected ways. Your experiment doesn't just gather data; it changes the system you're studying.
Mental model
Reversible vs. Irreversible Decisions
This pairs naturally with Cynefin's domain logic. In the complex domain, favour reversible experiments — probes you can unwind if they fail. In the chaotic domain, irreversibility matters less than speed; any stabilising action is better than none. In the complicated domain, invest more analysis in irreversible decisions because the right answer is findable.
Section 7
Real-World Application
Spotify — scaling engineering culture across domains
The scenario
By 2012, Spotify had grown from a small Swedish startup to a company with hundreds of engineers distributed across multiple cities. The challenge wasn't technical — it was organisational. How do you coordinate hundreds of engineers building interdependent features without creating the bureaucratic overhead that kills the speed that made you successful? Henrik Kniberg and Anders Ivarsson, working as agile coaches inside Spotify, documented the company's approach in their widely circulated 2012 white paper on Spotify's engineering culture. What they described, though they didn't use the Cynefin label explicitly, was a system that treated different types of engineering work as belonging to different domains — and applied different coordination mechanisms accordingly.
How the tool appliedSpotify's "Squad" model gave small, autonomous teams (6–12 people) ownership of specific features or components. Squads operated in the complex domain: they were building products for users whose behaviour couldn't be predicted, so they ran rapid experiments, shipped MVPs, and iterated based on real usage data. Probe, sense, respond. But the infrastructure those squads depended on — shared platforms, data pipelines, core APIs — operated in the complicated domain. These systems needed expert architecture, careful analysis, and coordinated releases. Spotify handled this through "Chapters" and "Guilds" — cross-squad groups of specialists (backend engineers, data scientists, QA) who maintained shared standards and made expert-driven decisions about platform architecture. The clear domain showed up in operational processes: deployment pipelines, incident response protocols, on-call rotations. These followed documented best practices. No experimentation needed.
What it surfacedThe insight was that a single coordination model — whether top-down planning or bottom-up autonomy — would fail because different parts of the engineering organisation faced fundamentally different types of problems. Squads needed autonomy because product development is complex. Platform teams needed coordination because infrastructure is complicated. Operations needed standardisation because deployment is clear. Applying one approach across all three would either strangle product innovation with unnecessary process or destabilise infrastructure with unnecessary experimentation.
The non-obvious factorThe model's most underappreciated feature was how it handled the transitions between domains. When a squad's experimental feature became a stable, widely-used product, it gradually shifted from complex to complicated — and the coordination mechanisms shifted with it. More documentation, more cross-squad alignment, more architectural review. Spotify didn't treat domain classification as permanent. The same feature could move from complex (early experimentation) to complicated (scaling and hardening) to clear (mature, stable operation) over its lifecycle. This dynamic reclassification — not the squad structure itself — was what made the system work. Most organisations that tried to copy Spotify's model copied the structure but missed the underlying sense-making logic about which parts of the system needed which kind of governance.
Section 8
Analyst's Take
Faster Than Normal — Editorial View
Cynefin endures because it solves a problem that no amount of analytical sophistication can solve: the problem of applying the wrong kind of analysis. Every other decision tool in this library assumes you already know what kind of situation you're in. A Decision Matrix assumes the options are knowable and comparable. Scenario Planning assumes the future is uncertain but explorable. The 5 Whys assumes causes exist and can be traced. Cynefin sits upstream of all of them, asking the question they take for granted: is this a situation where analysis will help, or one where it will actively mislead you? That question is worth more than most frameworks' entire output.
The failure mode I see most often is what I'd call "domain flattery." Teams classify their situation as complex because complexity sounds sophisticated and justifies the experimental, iterative approach that most modern organisations already prefer. Calling something complicated feels pedestrian — it implies there's a right answer and you just need to find it, which is less exciting than "emergent dynamics" and "safe-to-fail probes." The result is that genuinely complicated problems — where expert analysis would yield a clear best option in a week — get subjected to months of experimentation that produces the same answer the expert would have given on day one. Complexity is not a compliment. It's a specific diagnosis with specific implications. If your situation has knowable cause-and-effect relationships that an expert could map, it's complicated, and the appropriate response is to hire the expert, not to run experiments.
The highest-leverage technique: use Cynefin as a team exercise, not a solo classification. Give each team member five minutes to independently classify the situation's components into domains, then compare. The disagreements are the most valuable output. When the CTO says "this is complicated" and the head of product says "this is complex," they're not wrong — they're seeing different facets of the same situation. The CTO is looking at the technical architecture (complicated). The head of product is looking at user adoption (complex). Both are right. The framework's real power isn't in producing a single classification — it's in making visible the fact that different parts of the organisation are operating in different domains and need different decision-making protocols simultaneously.
Section 9
Top Resources
01
Academic paper
The single best introduction to Cynefin for practitioners. Published in Harvard Business Review, this article distils the framework into its essential components with clear examples from government, military, and business contexts. Snowden and Boone explain each domain's decision protocol and — critically — the dynamics of moving between domains. Start here. Most people who claim to know Cynefin are actually working from second-hand summaries of this piece.
02
Cynefin: Weaving Sense-Making into the Fabric of Our World — Dave Snowden & friends (2020) [VERIFY]
BookSnowden's own book-length treatment of the framework, co-authored with a group of practitioners. Covers the theoretical foundations (complexity science, anthropology, narrative research) that underpin the model, plus detailed guidance on facilitation techniques for Cynefin workshops. Dense and occasionally academic, but essential for anyone who wants to use the framework beyond surface-level classification. The chapters on liminal dynamics — what happens at the boundaries between domains — contain insights you won't find anywhere else.
03
Book
The cognitive science foundation for why Cynefin is necessary. Kahneman's System 1 (fast, intuitive) and System 2 (slow, analytical) map loosely onto Cynefin's domain logic: System 1 works in the clear domain, System 2 in the complicated domain, and neither works reliably in the complex domain — which is precisely why that domain requires experimentation rather than analysis or intuition. Understanding the cognitive biases Kahneman documents (especially overconfidence and the illusion of understanding) explains why teams misclassify domains so predictably.
04
Book
Grove's concept of "strategic inflection points" — moments when the fundamentals of a business change — is a practical illustration of the cliff edge between Cynefin's clear and chaotic domains. Intel's transition from memory chips to microprocessors is a case study in recognising that a situation has shifted domains and that the old response pattern (optimise the existing business) must give way to a fundamentally different one (act decisively in chaos, then rebuild). Read this for the emotional and organisational reality of domain transitions.
05
Book
Horowitz never mentions Cynefin, but his book is the best available account of what it feels like to operate in the chaotic domain as a startup CEO. The chapters on wartime vs. peacetime CEO — where the same leader must adopt fundamentally different decision-making approaches depending on the situation — are Cynefin in practice. His core insight aligns perfectly: the approach that makes you successful in stable conditions will destroy you in crisis, and vice versa.
Decision Tools Library — Browse by phase
FramingHard Choice ModelCynefin FrameworkReversibility TestReframingAbstraction LadderingSWOT Analysis
Why this matters next
mental modelsSecond-Order Thinking
Reframing applied the Second-Order Thinking mental model
mental modelsLeverage
Reframing applied the Leverage mental model
mental models5 Whys
Reframing applied the 5 Whys mental model
mental modelsOODA Loop
Reframing applied the OODA Loop mental model
mental modelsNarrative
Reframing applied the Narrative mental model
mental modelsIntuition
Reframing applied the Intuition mental model
Continue exploring
HMRDREALSA
Decision tool
Hard Choice Model
Determine what kind of decision you're facing (no-brainer, apples vs. oranges, b
Decision tool
Reversible vs. Irreversible Decisions
Determine whether this is a one-way or two-way door, and calibrate how much anal
Decision tool
Reframing
Restate the problem from a different angle to ensure you're solving the right th
Decision tool
Abstraction Laddering
Move up (why?) or down (how?) levels to find the right altitude for your problem
Decision tool
SWOT Analysis
Map internal strengths/weaknesses against external opportunities/threats to unde
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.