Not a lot of people know about this, though everyone in the software industry really should.

The C's of Cynefin

The Cynefinpronounced ki-nev-in. It's Welsh, and means 'habitat'. framework is a way to describe problem spaces. Just like you can describe terrestrial terrain as smooth, hilly, marshy, or mountainous, so too can you categorize problems and situations you face as being in one of the following domains: clear, complicated, complex, chaos, and confusion.

Knowing which domain a problem lies in helps select the most appropriate strategy for navigating that domain and arriving at a solution. It also affords a common vocabulary to discuss the issues with others, and set proper expectations of what is required to arrive at a solution.

What follows is by no means an exhaustive treatment, but rather a teaser introduction to the basics.


Perhaps the most mundane is the clear domain (previously known as simple). Here the problems tend to be of the variety that can be easily articulated and even categorized and cataloged. The solution is usually rote, verging on cookbook approaches to solve familiar and well-understood problems.

Many laws, practices, and policies hope to reduce the world into this domain. This is because when people aren't familiar with the other domains, they tend to assume all problems can and do lie here, and thus assume all things can be solved using the plan of approach that works here, namely sense, categorize, and respond.

Within the simple clear domain, all things are known, and there can be—and usually are—rules or guidelines that can be applied to arrive at the clear solution. That said, few if any interesting problems...ignoring, for the moment, Artificial Intelligence, and automation, which seems well suited for this domain. in software development—aside from the most banal and pedestrian—lie here, so let's not consider it further.


Next to consider is the complicated domain. This builds upon the clear domain's notion that all things are known—or at least easily knowable—and while the path to a solution is not necessarily as clear as the clear domain, it exhibits many of the same characteristics: best practices can be established, and experts familiar with the problem can provide guidance, as some analysis of the situation, and decision-making to select the best of a number of alternatives, will be necessary. Here, the clear domain's strategy of sense, categorize, and respond gives way to sense, analyze, and respond.

Traversing a labyrinth, while complicated, is possible with turn-by-turn instructions provided before entering—or even an algorithmic approach—and it's possible that some can develop expertise to navigate toward a solution from any point within the maze.

Similarly, building a shoe factory, while a complicated undertaking, is sufficiently well understood that a blueprint can be drawn up in advance, and resources can be brought to bear on building such a thing fairly mechanically. Sure, complications can arise—supply chain disruptions, weather, legal issues, and so on—but the responses to these are seldom more than selecting which of a handful of established solutions to apply.

Some software development (products that have been built before, maybe KTLOKeep The Lights On, or routine maintenance efforts that only marginally alter the product. work) dwell here, and in fact much advanced training prepares business leaders to work in this domain.


Alas, the bleeding edge of software development does not dwell in the complicated domain. If it's novel, innovative, and exploring previously unsolved problems, it likely lives in the complex domain instead.

Here, not all things are known, nor necessarily can be predicted ahead of time. There are no best practices, though by the strategy of probe, sense, and respond, some reasonable practices might emerge (and evolve). There may likely be iterative probe-and-sense cycles while the issues become better understood.

Unfortunately, this can frustrate leadership that might not be equipped to work in this domain; you see this when they demand fixed schedules be met. They may rely upon practices and predetermined plans appropriate for the complicated domain, but which invariably fail here. While "I don't know" might be looked down upon in the complicated domain, it's very much the norm for the complex domain. Here, the best thing leadership can do is ensure that the phrase is actually "I don't know yet", and while the complete path to the solution may not be completely drawn up nor even fully known far in advance, their guidance should direct efforts toward the complicated domain to ensure the path doesn't lead to the one other domain to discuss....


The place where nobody wants to be: the domain of chaos, where quite literally all hell breaks loose. In this space of crisis, the strategy is act, sense, respond: there is no time for deep analysis, just take some immediate action to change circumstances. Relying on gut-level instinct likely is better than taking no action. Just get out of this domain into one of the others as quickly as possible.

The nature of chaos means you don't have the luxury of analyzing too much: what you learn from analysis can become uselessly out of date quickly, and new events unfold that close off options you had before. For example, in a crumbling building, you instinctively want to get out by means of the nearest exit; you're less concerned about whether that lets you out on the street with your favorite restaurant nearby, you just want to get out of the building. Similarly, falling into a wild river headed for a waterfall, you don't take time to analyze whether that branch you're approaching is too weak, you just grab it and buy time to do the next thing.

While a gut-level response may be called for, this should not be construed as permitting panic (which is never good.) Remaining level-headed but biased toward action is what's called for: taking in enough about the immediate situation to act quickly.

A catch-all domain, confusion, is the no-man's-land where it's not obvious which other domain is most applicable. Arguably, it's not fully a domain of its own, and indeed the heuristics to identify which of the others a problem more rightly belongs within is beyond the scope of this page. There are many resources available on Cynefin, which, now that you're aware it exists, you can learn more about.