At the end of the last post, I said I was building Cynefin diagram support for Mermaid next. Before I get into the implementation, I want to talk about the framework itself, because it deserves a proper introduction.
How I Found Cynefin
Years ago at the Wikimedia Foundation, my Director Faidon Liambotis introduced me to the Cynefin framework. He used it to map and manage the complexity of the ecosystems we operated in: infrastructure serving billions of requests, volunteer communities with their own dynamics, legacy systems interacting with bleeding-edge deployments.
I was skeptical at first. Another management framework? But Cynefin isn’t about managing. It’s about making sense, understanding what kind of problem you’re facing before you decide how to solve it. That distinction changed how I think.
What Is Cynefin?
Cynefin (pronounced “kuh-NEV-in,” a Welsh word meaning “habitat” or “place”) is a sense-making framework created by Dave Snowden. It doesn’t tell you what to do. It tells you what kind of situation you’re in, so you can choose the right approach.
The framework has five domains:
Clear (formerly Simple/Obvious) The relationship between cause and effect is obvious. Best practices apply. You see the problem, you categorize it, you respond with the known solution. Runbooks live here. Restarting a crashed service lives here.
Complicated Cause and effect exist but require analysis. You need expertise to find the answer, but an answer exists. This is the domain of engineers, architects, and analysts. Good practice, not best practice, because there are multiple right answers and you need someone who understands the options.
Complex Cause and effect are only visible in retrospect. You can’t analyze your way to a solution because the system is emergent. It behaves differently depending on how you interact with it. The approach: probe, sense, respond. Run small experiments. See what happens. Amplify what works.
Chaotic No relationship between cause and effect at the system level. The house is on fire. There’s no time to analyze or experiment. You act to stabilize, then sense where you are, then respond to move toward complexity or complication. Novel practice. Incident response at 3am when everything is down and nothing makes sense.
Confusion (formerly Disorder) The center of the framework. This is where you start when you don’t know which domain you’re in. The most dangerous place, because people default to whatever approach they’re most comfortable with, regardless of whether it fits.
Why This Matters for Engineering
Most engineering organizations act as if every problem is Complicated. Bring in experts, analyze the system, design the solution, execute the plan. And for a lot of infrastructure work, that’s right.
But some of the hardest problems in technology are Complex, not Complicated:
- Microservice architecture evolution: you can’t fully predict how 200 services will interact under new load patterns. You probe with canary deployments. You observe. You adapt.
- Team dynamics during a reorg: no amount of org chart analysis predicts how humans will actually collaborate. You try something, watch what emerges, adjust.
- Market strategy: will users adopt this feature? You don’t know until you ship it. Probe-sense-respond.
- Incident response: a cascading failure across multiple systems. The runbook doesn’t cover this combination. You’re in Chaotic territory. Act first, stabilize, then figure out what happened.
Treating a Complex problem like a Complicated one (spending weeks analyzing before acting) wastes time and gives false confidence. Treating a Complicated problem like a Complex one (running experiments when you could just ask an expert) wastes different time.
Cynefin helps you match the approach to the problem.
The Boundaries Matter
The transitions between domains are as important as the domains themselves. Snowden identifies a critical asymmetry: the boundary between Clear and Chaotic is a cliff. If you’re in Clear territory and become complacent, assuming things are obvious when they’re not, running on autopilot, you don’t slide gradually into Complicated. You fall off the cliff into Chaos.
This maps perfectly to operational reality. The system that’s been running fine for years, that nobody monitors closely anymore, that has the outdated runbook? When it breaks, it doesn’t break gently. It breaks catastrophically, because all the institutional knowledge about how to handle its failure modes has evaporated.
The Gap
I’m sold on Cynefin as a thinking tool. I use it regularly. But like Wardley Maps before, the tooling for creating and sharing Cynefin diagrams is poor:
- Whiteboards work in person but don’t travel
- Drawing tools produce images that can’t be version-controlled
- There’s no text-based DSL for Cynefin anywhere
That last point is the key one. Wardley Maps at least had OnlineWardleyMaps and MapScript. Cynefin has nothing text-based. No way to put a Cynefin diagram in a README, diff it in a PR, or embed it where developers actually work.
This is the gap I’m building into.
What a Text-Based Cynefin Would Look Like
Imagine writing this in a markdown file:
cynefin-beta
title Incident Response Posture
complex
"Investigate root cause"
"Run chaos experiment"
complicated
"Analyze performance data"
"Capacity planning"
clear
"Restart service"
"Apply known fix"
chaotic
"Page on-call immediately"
confusion
"Unknown failure mode"
complex --> complicated : "Pattern identified"
clear --> chaotic : "Complacency"
Five domains with items. Transitions showing how situations move between domains. The cliff between Clear and Chaotic. All in plain text, version-controlled, renderable anywhere Mermaid runs.
Nobody has built this. I’m building it.
Resources
If you want to go deeper on the Cynefin framework:
- Cynefin.io, Dave Snowden’s organization
- A Leader’s Framework for Decision Making, the original HBR article
- Cynefin St David’s Day 2024, updated framework description
- Wardley Mapping 101, the companion strategy framework in this series
