Cynefin Framework - A Stuff+ Tool for Approaching Problems
One of the archetypes written into a staff+ role is the Solver. Your organisation will throw problems at you and expect you to solve them. These problems may be thrown at you quickly, requiring you to jump from one to the next, or they may come in a planned way and you will have time and space to prioritise, queue, and deal with them one at a time. You should also expect these problems to be arbitrarily complex. This is why, as a staff+ engineer, you need a tool to approach these problems. A tool that allows you to categorise this arbitrary complexity and gives you a proven way to deal with the challenge. For me, such a tool is the Cynefin Framework and I would like to introduce it to you in this issue of our newsletter.
The Cynefin Framework, created by Dave Snowden in 1999, provides you with five domains into which you can categorise your problem, and for four of these domains it suggests a methodology for approaching the problem. This is a nice structured approach that forces you to think about what you have on your plate before you dive in. And the truth is that you shouldn't always dive in - it depends on which domain the problem is in.
The Problems Domains
To classify a problem into a domain, you use your experience and what it tells you about the problem.
If the nature of the problem is immediately apparent to you (in other words “you’ve seen it before”), it’s a Clear (or a Known Known) problem.
If the nature of the problem isn’t immediately apparent, but your experience allows you to see some cause-and-effect relationships where you can apply your knowledge to start investigating, you are dealing with a Complicated (or Known Unknown) problem.
If your experience doesn’t suggest to you any cause-and-effect relationships for you to start with, but it does suggest an approach to start gathering information that will allow you to discover those relationships in retrospect, then you are facing a Complex (or Unknown Unknown) problem.
If your experience doesn’t give you even a hint of discovering cause-and-effect relationships (usually because the various aspects of the problem are rapidly changing and there is no solid point of attachment), you have a Chaotic problem.
There is also a Confusion domain. This is for situations where you are unable to classify the problem into any of the other domains. You should think of it as a last resort. It’s quite rare to end up here, because the uncertainty and unpredictability has to be really high. It's usually an indication that what you’re seeing is an overlap of multiple problems, and your job is to start breaking the situation down into separate problems that can be placed in the other domains.
Because the classification is based on your experience, it’s very specific to you and the organisation you’re in. You will classify differently over time (as your experience grows). It may also happen that once you have taken the first step from the methodology that applies to the domain, you will make a discovery that moves the problem to another domain. This brings me to the building blocks of the methodologies.
The Building Blocks of the Methodologies
The methodologies that the Cynefin framework suggests for different domains use a shared set of building blocks. I like to think about them separately, because they often give me a language that I can use to describe the steps I’m going to take even if I’m solving something outside the framework:
Sense is about gathering the information that will allow you to categorise, analyse, or iterate on an approach to respond to the problem.
Probe is about finding an approach (e.g. through further tests or experiments) that allows you to gather information about (sense) the problem.
Act is about taking immediate actions that don't solve the problem but increase stability so that you can observe their results and gather information about (sense) the problem from them.
Categorise is about using the gathered (sensed) information to choose a known way of responding to the problem.
Analyse is about working with the gathered (sensed) information to identify patterns and design a way to respond to the problem.
Respond is about applying the solution to the problem.
Knowing the steps allows you to apply the methodology mapped to a given domain.
Domain and Methodology Mapping
The way in which the Cynefin Framework defines the methodologies for the domains is illustrated below.
At first glance this may seem a bit confusing. That’s mainly because the solution (respond) to the problem has different meanings depending on the domain.
In the Clear domain, the solution should be a well-established “best practice”. The nature of the problem is apparent so the information gathered need only be used for categorisation into one of already known proven methods that you or the organisation has used in similar situations.
The problem and solution are not that obvious in the Complicated domain, but still within your area of expertise. So after gathering the information, you should be able to identify (through analysis) which of your past “good practices” can be adapted to solve the problem.
This is not the case for the Complex domain. Here you will most likely need to probe the problem (add more observability signals, increase test coverage, or try to isolate it in a lab environment) before you can gather information that will allow you to start iterating on the solution until the final one emerges.
If you see no way to begin to narrow down the problem by probing (Chaotic domain), the best thing you can do is act. Trust your instincts and take an approach that you hope will improve the situation, and gather information from it. Maybe not at first try, but this will allow you to find a solution - very often a novice one.
Cynefin Framework as a Self and Organisation Improvement Guide
The Cynefin Framework can be more than just a tool for approaching problems. You can use it as a guide to improve yourself and your organisation.
Firstly, you can use the Cynefin Framework as a guide by observing in which domain the majority of problems occur. Typically, staff+ engineers shouldn’t see too many problems in the Clear domain. And they shouldn’t see them more than once in a given organisation. If problems in the Clear domain are repeating, then the organisation may have a knowledge management challenge. If problems in Clear domain are the majority and you haven’t been hired because the organisation needs to upskill, then the organisation has an unacknowledged skills issue. At the other end of the spectrum, if you’re constantly surprised with problems from the Chaos domain (instead of those coming in the more expected way, in line with strategic moves), it’s likely that the organisation is biting more than it can chew, and it’s a signal to change approach before you drown. And if you are constantly in the Confusion domain… well.
Secondly, you should use the opportunities that problems in certain domains present to develop others. Problems in the Clear domain are great for enabling others to grow themselves by pushing them to look within the industry knowledge and find existing standard solutions. Problems in the Complicated domain are great opportunities to build mentoring relationships and develop promising individuals.
Finally, the Cynefin Framework can be used to measure the progress or decline within the organisation. If the organisation’s strategy is to venture into new areas or face the unknown, you should start paying special attention to tracking problems in the Chaotic domain. They will certainly appear, but what you should be interested in is whether and how they are progressing clockwise through the framework. This will be a signal of how your organisation is learning and adapting to these new challenges. You may also observe a counter-clockwise movement of problems through the framework. This means that your organisation is losing knowledge and experience.
But in the end, don’t forget that the Cynefin Framework is only one tool. You should have several tools and use them accordingly. Don’t bet everything on a single one.i