Walking down the same, old street to discover something new.

Isn’t it funny, how we can live in the same neighborhood for years, walking up + down its streets, sidewalks, stairways, straightaways + curves only to discover something new, something so obvious yet we’re seeing for the very first time? It might be something as small yet significant as a street sign that’s always been there, or something big + surprising, like a house we’ve never noticed before but walked past a thousand times.

Such as it was my feeling the first time I discovered + began to learn more about the Cynefin framework only just three short years ago from a pal who turned me onto it when I expressed my frustration over members of my team relentlessly trying to solve things the same way, even when the situation didn’t fit. Having walked up + down the streets of Lean + Agile methodologies, it was startling that so many years had passed without my having stumbled upon something so useful. Needless to say, it’s become the foundation for how I think about + design solutions for problems of all sorts.

Major hat tip to Dave, or else I’d still be letting others continue to make their own mistakes, but not in a productive way. Sometimes we all need a little nudge in a new direction, your humble author included. Enter: Cynefin.

Wait. What?

How do you pronounce Cynefin? Say it like this:


Evel KnievelIt sounds a little bit like Mr. Knievel’s last name but without the hard ‘e’ sound + followed by vin.

The word comes from the Welsh word for ‘habitat’. Dave Snowden invented this elegant concept while working at IBM back in 1999 to help them manage an unwieldy amount of intellectual capital within the organization.  But wait, you still haven’t heard the best parts.

What’s so great about it?

In a nutshell, it’s powerful because it posits something obvious but often overlooked:

Different problems warrant different solutions.

How often do you watch someone doing their own, so-called version of agile + kanban + lean + scrum + whatever to try to solve a complex challenge in an overly-simplistic way + then be utterly confused when it fails? Yeah, that mostly that has to do with how we typically react to the unknown. Often, the more unknown a problem is, the more we default to trying to solve it in ways that are most familiar to us. This is not always the best approach.

What can we do about our natural tendencies to fall back on what’s worked before in a world increasingly full of problems that require new approaches to solve for the methods + solutions that may have even created them in the first place?

The Cynefin framework

You can see in the diagram over there that there are 5 domains. As in real life, Disorder is at the center. If that’s not an elegant expression, I just don’t know what is. Hat tip for the swell diagram by @_richardshy

The 5 domains explained

Cynefin categorizes situations into 5 domains…

  • Obvious (formerly known as Simple) is the simplest, most ideal domain of best practices.
    @_richardshy's iteration of the Cynefin framework
    Gratitude to @_richardshy for the swellest illustration of this I’ve seen.
    • Characteristics: Problems are well understood + solutions are evident. Solving problems in this domain requires minimal expertise.
    • Approach: Problems in this domain are well known. The approach is to sense the situation, categorize it into a known bucket + respond with a well-known, potentially scripted, solution.
  • Complicated is, well, more complicated. This is the domain of good practices.
    • Characteristics: A general idea of the known unknowns exists — we may likely know the questions we need to answer + how to get the answers. We can assess the situation with some expert knowledge + determine a course of action. Given some time, we can reasonably identify risks + devise a relatively accurate plan. Expertise is required but the work is iterative so we will learn as we go.
    • Approach: First, we sense the problem. Then, analyze what we find to determine our course of action. Last, we respond by executing our plan. Iterations are often implied.
  • Complex gets more complex. It’s the domain of emergent solutions.
    • Characteristics: There are now unknown unknowns — we don’t even know questions to ask, yet. Even beginning to understand our challenge requires iteration + experimentation. The final solution will only be clear once discovered. In hindsight it is always obvious but never apparent at the beginning. No matter how much time we spend in analysis, it’s not possible to identify all the risks or accurately predict the solution + effort required to solve the problem. We have to keep moving, though, keep trying things, making mistakes, collecting information + experience with the problem in order to better understand, define it + move to designing the right solution.
    • Approach: First step is probe. This means tinker with it to gather more information, experience + knowledge. Sense + evaluate. Repeat. As we gather more knowledge, we can determine our next steps + respond. Repeat, repeat, repeat, with the goal of moving our problem into the “Complicated” domain.
  • Chaos is just what it says. It’s the domain of novel solutions.
    • Characteristics: The typical + immediate priority is containment. Our initial solution may not be the best but it’s only temporary until a real one can be realized. This is Workaroundville. Once we’ve stabilized the patient, we can take a breath + a step back to determine a proper course of action.
    • Approach: First, we need to act. Once we achieve some semblance of control, we can sense  or assess the situation to determine how we respond with next steps. It’s important to take action + iterate quickly to remediate or move the problem to another, more manageable domain.
  • Disorder is everything right smack in the middle. Like life!
    • Characteristics: If we don’t know where we are, approach-wise, we’re likely in Disorderville. The only goal here is to move the problem into a known domain + reiterate until we get there.
    • Approach: Gather more info or sense + evaluate to identify what we do + don’t know. Probe all over the place. Collect enough info to level up to a more well-defined domain where we can respond.

Keep in mind the boundaries of domains are not fixed or so rigid they can’t be fluid. Based on our activities, characteristics + approaches can bounce back + forth between domains or live across two at once, depending on the situation.

So, what now?

Cynefin framework drawn by Richard Shy
Cynefin framework drawn by Richard Shy

Cynefin provides us with a great guide for how to approach a set of different situations + the characteristics of each, which are useful for helping us recognize what sort of situation we’re in, which refreshingly gives us a great deal of context.  I’ll restate the obvious because it bears repeating: solutions applied in the wrong context, regardless of how elegant, intentional + well-crafted, can be worthless at best + harmful at their worst. Context is pretty much everything.

Pairing the right approach with the right context can help us all achieve successful outcomes across many applications. Cynefin was thoughtfully designed with this in mind. Gratitude to Dave Snowden + his team for their continued work in forwarding + refining such a great perspective. Thank you. No small thing.

Cynefin Resources