Cynefin Framework

The Welsh Word That Changed How I Coach

Cynefin - pronounced “kuh-NEV-in” - is Welsh for “habitat” or “place of multiple belongings.” Dave Snowden created it in 1999 while working at IBM’s Institute for Knowledge Management, and it has since become one of the most useful sense-making tools I carry into coaching engagements.

Here’s the thing about Cynefin: the core insight is almost embarrassingly simple. Not all problems are the same - and treating them as if they were leads to consistently poor outcomes.

A production deployment with a scripted pipeline is a fundamentally different animal than launching a product in a market nobody understands yet. But leaders routinely reach for the same playbook regardless. They demand certainty when none exists. They call for analysis when they should be running experiments. They apply best practices to situations where best practices cannot possibly apply.

If you’ve spent any time coaching teams, you’ve watched this happen. Three sprints of over-analysis on a problem that could only be solved by shipping something and seeing what happens. Cynefin gives you the vocabulary to name that mismatch - and a visual model to catch it before it burns weeks of effort.

The framework reached a wide audience through the 2007 Harvard Business Review article Snowden co-authored with Mary Boone, “A Leader’s Framework for Decision Making.” That HBR piece remains one of the most practical introductions to the model. Snowden continued refining it through his consultancy (originally Cognitive Edge, later renamed The Cynefin Company) and published the comprehensive reference Cynefin: Weaving Sense-Making into the Fabric of Our World in 2020.

One terminology note: in 2020, Snowden renamed the “Simple” domain to “Clear” to reduce the patronizing implication that problems in this space are beneath serious attention. Some older references - including the card image below - still use “Obvious” or “Simple.” Same domain, better name.

Five Domains and One Cliff

Cynefin organizes situations into five domains. Four are named, each with a distinct decision-making approach. The fifth - Disorder - is the state of not knowing which domain you’re in. That turns out to be the most dangerous one.

Clear (formerly Simple/Obvious)

In the Clear domain, cause and effect is obvious. Everybody can see it. You flip the switch, the light turns on.

Think of it like making coffee. You know the inputs - pod, water, mug, electricity. You follow the same steps every morning. You get the same cup every time. Once you hit that button, there’s no mid-course correction. That’s a defined process. The Clear domain is where defined processes live.

The decision-making approach is sense-categorize-respond. See the situation, slot it into an established category, apply the known best practice. Checklists, standard operating procedures, scripted deploy pipelines - all Clear domain.

Best practices govern here. If a genuine best practice exists and the situation clearly calls for it, use it. Don’t over-engineer. Don’t convene an expert panel. Just follow the process.

The danger? Complacency. When things feel predictable for too long, teams stop paying attention. They over-constrain, build rigid bureaucracies, and lose the ability to detect when the ground has shifted. Which brings us to the cliff.

Complicated

In the Complicated domain, cause and effect exists - but it’s not immediately obvious. You need expertise, investigation, or analysis to find the answer. There may be several valid approaches, and figuring out the right one takes work.

The approach is sense-analyze-respond. Perceive the situation, bring in expertise, choose a response based on what the analysis reveals. This is the domain of architects, consultants, and senior engineers. A team designing a database schema for a new microservice? Complicated. The problem is solvable through analysis, and expertise makes the difference.

Good practices (not “best” practices) apply here. Two competent architects might design different solutions to the same problem, and both might work well. There’s no single right answer - there’s a range of viable ones that expert judgment can evaluate.

The trap is analysis paralysis. Because the problem is analyzable, teams can fall into endless analysis - seeking a perfect answer that doesn’t exist or isn’t worth the time to find. Watch for teams that keep requesting “one more spike” before committing. At some point, the analysis hits diminishing returns and you just need to decide.

Complex

Here’s where things get genuinely interesting for agile practitioners - because this is where most product development work actually lives.

In the Complex domain, cause and effect can only be understood in retrospect. You can’t analyze your way to the answer because the answer doesn’t exist yet. It emerges through interaction.

Think of it like sailing. The wind changes direction. The current shifts. A sea lion decides your planned route is actually his personal sunbathing spot. You can’t follow an index card half-asleep - you adjust sails, change course, use the motor if you have to. You couldn’t have predicted the right path at the dock. You discovered it on the water.

The approach is probe-sense-respond. Design small, safe-to-fail experiments. Observe what happens. Amplify what works, dampen what doesn’t. This is the domain of emergent practices.

This maps directly to agile thinking. Sprints are probes. A/B tests are probes. Prototypes, MVPs, spikes - all probes. The entire empirical process at the heart of Scrum (build an increment, inspect the results, adapt the plan) is a probe-sense-respond cycle.

Here’s the critical distinction between Complicated and Complex: in the Complicated domain, an expert can examine the situation and tell you the answer. In the Complex domain, no expert can - because the answer hasn’t emerged yet. Bringing in a consultant and asking them to predict outcomes in a complex system often produces confident-sounding analysis that turns out to be wrong.

This is why agile coaches need Cynefin. It gives you the language to explain why “just bring in an expert to tell us the right architecture” won’t work when the problem is genuinely complex. You’re not being difficult - you’re being accurate.

Emergent practices characterize this domain. Patterns will form, but only after experimentation. Document what works, but hold those patterns loosely. What works today in a complex system may not work tomorrow - and that’s not a failure of your documentation. It’s the nature of the domain.

The framework also carries an important epistemological stance that agile coaches should love: the relationship between cause and effect is not always knowable in advance. This runs counter to the implicit assumption in many management traditions that with enough data and enough planning, you can predict outcomes. Cynefin says: sometimes you can’t. And the appropriate response isn’t more planning - it’s deliberate experimentation and rapid learning. That’s empiricism. That’s Scrum. That’s sailing.

Chaotic

In the Chaotic domain, there’s no discernible cause and effect at the system level. Things are in too much flux for analysis or experimentation to gain traction.

The approach is act-sense-respond. Act first to stabilize. Then sense what you have to work with. Then respond to move the situation into Complex or Complicated where you can think more deliberately.

This is not the time for retrospectives, planning meetings, or consensus-building. Someone needs to make a call. A production system is down and customers are affected. A key team member has left abruptly mid-sprint. A global event has invalidated your entire product roadmap overnight.

Novel practices emerge from Chaos. Some of the most innovative breakthroughs come from chaotic situations that forced people to try something they never would have attempted under normal conditions. But the goal is not to stay here - it’s to stabilize enough to move somewhere you can think.

(One nuance worth noting: Snowden has pointed out that leaders sometimes deliberately push situations into Chaos to break entrenched patterns. High-risk move, occasionally valid - particularly when an organization is stuck in complacent Clear-domain thinking and can’t be dislodged by persuasion alone.)

Disorder

Disorder is the space in the center of the Cynefin diagram. It’s the state of not knowing which domain you’re in.

This is actually the most dangerous domain - because people in Disorder default to whatever decision-making approach they’re most comfortable with, regardless of whether it fits.

An analytical thinker defaults to Complicated-domain responses: “We need more data.” An action-oriented leader defaults to Chaotic-domain responses: “Just make a decision and go.” A process-oriented manager defaults to Clear-domain responses: “We need a standard procedure.” None of these is wrong in itself. All of them are wrong when applied to the wrong domain.

The way out is to break the situation into its component parts and assign each to the appropriate domain. Most real-world situations aren’t purely in one domain. A product launch might involve Clear-domain logistics, Complicated-domain engineering, Complex-domain market response, and Chaotic-domain crisis management if the launch goes sideways. Decomposing the situation and matching each component to its domain - that’s the core sense-making move.

The Cliff You Didn’t See Coming

The boundary between Clear and Chaotic deserves special attention because it’s the only sharp boundary in the framework. Every other transition is gradual. This one is a cliff.

When teams get overly reliant on established practices, stop monitoring for change, and settle into “we’ve always done it this way” - they create the conditions for a catastrophic shift. The complacency is the setup. A sudden change in conditions is the trigger. And the result is a freefall into Chaos with no buffer.

Think of a bank relying on standardized risk models right up until a systemic crisis makes those models meaningless overnight. Or a team that’s run the same release process for three years - until the infrastructure migration renders every assumption invalid.

This is one of the most practically useful insights from Cynefin. It explains why well-run organizations can suddenly find themselves in crisis. And it argues for maintaining healthy vigilance even when - especially when - things seem to be running smoothly.

What This Changes About Your Coaching

Cynefin isn’t a methodology. It doesn’t tell you what ceremonies to run or how to structure your backlog. It’s a diagnostic lens - and once you have it, you start seeing domain mismatches everywhere.

In Retrospectives

When a team surfaces impediments, try this: “Which domain does this belong to?”

That single question transforms the conversation.

An impediment in Clear (build pipeline is slow because the cache config is wrong) has a known fix. Assign it, fix it, move on. An impediment in Complicated (API response times are degrading under load) needs expert analysis - assign a spike. An impediment in Complex (team morale is declining and nobody knows why) needs probes - try a few different things, see what moves the needle. An impediment in Chaotic (cloud provider outage right now) needs immediate action, not discussion.

Categorizing retro items by domain prevents the failure mode where everything becomes an action item with an owner and a due date - or everything gets discussed endlessly without resolution.

In Refinement

Cynefin sharpens refinement conversations. Stories in Clear can be estimated with reasonable confidence. Stories in Complicated benefit from a spike first. Stories in Complex probably shouldn’t be estimated at all - time-box the experiment and evaluate the outcome.

This helps teams stop agonizing over estimates for genuinely uncertain work. If a story is Complex, the honest answer to “how long will this take?” is “we don’t know yet, but we’ll know more after we run a two-day experiment.” That’s a more useful answer than a story point estimate that creates false precision.

When Coaching Leaders

Many leaders have a dominant style that works in one domain and misfires in the others. A directive leader excels in Chaos but stifles emergence in Complex. A collaborative leader thrives in Complex but frustrates teams in Clear where a simple decision is all that’s needed.

Here’s an exercise that works well in one-on-ones: when a leader describes a challenge, ask them to place it on the Cynefin diagram. Then ask, “Is your current approach matched to that domain?” The mismatch - when it exists - is often immediately visible once they have the lens.

In Agile Transformations

Agile transformations are almost always Complex-domain work, yet organizations routinely approach them with Complicated-domain thinking. They hire consultants to analyze the org, design a target operating model, and roll out a change plan. That assumes the organization is a machine that can be re-engineered through analysis.

Cynefin argues that organizational change is Complex - the outcome emerges from interactions between people, teams, policies, and culture that cannot be predicted through top-down design. The appropriate response is safe-to-fail experiments: try things, see what takes, amplify what works. This has a fundamentally better track record than the big-bang transformation playbook.

If you’ve ever watched a “transformation office” produce a beautiful 90-slide deck that nobody on the ground floor recognizes as their reality - that’s Complicated-domain thinking applied to a Complex-domain problem. The deck isn’t wrong. It’s just not how change actually happens in a living system.

In Incident Response

When production incidents hit, teams naturally enter the Chaotic domain. Cynefin makes the response pattern explicit: act first (restore service, mitigate impact), then sense (gather data on what happened), then respond (move into Complicated for root cause analysis).

The post-incident review - or blameless postmortem - is essentially the transition from Chaotic to Complicated. Now that the crisis is over, you can analyze what happened and what you can do to prevent it.

Coaches can use Cynefin to help teams build better incident habits by making the domain transitions visible. The team in Chaos should not be debating root causes. The team in the postmortem should not be applying emergency patches. Each phase has its own appropriate behavior - and naming the phase helps everyone stay in it.

What It Looks Like in the Room

Keiko had been a Scrum Master for about three years - mostly at large enterprises, usually juggling three or four teams at once. When her company spun up a new team to build a patient engagement platform for their healthcare division, she finally got the one-team assignment she’d been asking for.

The team was solid. Two senior engineers, a clinical subject-matter expert on loan from operations, a product owner who genuinely understood the regulatory landscape, and a junior developer who asked the best questions in every refinement. For the first two sprints, they moved fast - building integrations with the existing patient records system, setting up the infrastructure, knocking out the Clear-domain work with a confidence that felt earned.

Sprint three was where it changed.

The product owner came to refinement with a set of stories about patient communication preferences - how to surface the right message, in the right channel, at the right time. The team’s instinct was to analyze. The clinical expert pulled up research papers. The senior engineers proposed data models. The PO started sketching decision trees.

Three refinement sessions later, they were still sketching. Estimates kept getting revised upward. Every analysis uncovered more variables. The clinical expert found a study that contradicted the previous study. The engineers discovered that the data they needed wasn’t available from the upstream system in the format they’d assumed.

Keiko recognized the pattern. The team was treating a Complex problem like a Complicated one - reaching for analysis when the situation called for experimentation.

She asked for fifteen minutes at the next sprint planning. She drew the Cynefin diagram on the whiteboard and asked the team to place their current backlog items on it.

The infrastructure stories went straight to Complicated. No argument - those were solvable through good engineering and expertise. But when the team started placing the patient communication stories, something shifted. One by one, those cards migrated from Complicated to Complex.

The PO said it out loud: “We’ve been trying to analyze something that can only be learned by trying it.”

Over the next thirty minutes, the team redesigned their approach. Instead of a fully specified communication engine, they defined three small experiments - each one time-boxed to a few days. A basic preference survey for fifty patients. A concierge-style manual outreach for ten cases. A set of structured interviews with the nursing staff who actually handled patient calls.

Two sprints later, the concierge experiment revealed something the research papers had missed entirely. Patients didn’t care about channel preference nearly as much as timing - they wanted messages that arrived before appointments, not after. That insight redirected the entire product strategy.

At the retro, the clinical expert - the one who’d originally pushed hardest for more analysis - put it simply: “We stopped pretending we could research our way to the answer and started learning from actual patients.”

The Cynefin diagram stayed on the whiteboard for the rest of the quarter. Whenever someone proposed an approach, someone else would ask, “Which domain are we in?” It became a habit that took seconds to apply and saved weeks of misdirected effort.

That’s the thing about Cynefin. It doesn’t give you answers - it gives you better questions. And better questions, in my experience, are worth more than most answers anyway.

Go Deeper

• Snowden, D.J. & Boone, M.E. (2007). “A Leader’s Framework for Decision Making.” Harvard Business Review, November 2007. The most accessible introduction. Start here.

• Snowden, D.J. (2020). Cynefin: Weaving Sense-Making into the Fabric of Our World. The comprehensive reference by the framework’s creator.

• Kurtz, C.F. & Snowden, D.J. (2003). “The new dynamics of strategy: Sense-making in a complex and complicated world.” IBM Systems Journal, 42(3), 462-483. The original academic paper. More theoretical, but essential for understanding the intellectual roots.

• The Cynefin Company. thecynefin.co. Ongoing research, training, and community resources.

Use of Dave Snowden’s or Cognitive Edge material does not imply endorsement from Dave Snowden or The Cynefin Company. The Cynefin framework is developed by The Cynefin Company (formerly Cognitive Edge), shared under a Creative Commons Attribution-NonCommercial-NoDerivs license.