Before we jump into how one can wield Cynefin, let’s first describe what it is and why one would use it. You can head to Cognitive Edge’s site here to learn more about it, watch my Product Talk video to understand the very basics, or you can skip to the paragraph below. The creator of Cynefin, David Snowden, also does a fantastic introduction on youtube.
Now that I have gotten some of the linking out of the way, Cynefin is a sense-making framework. Its goal is to guide action based on the habitat, scenario, or social situation in which you find yourself. It does not spit out an answer for you based on some input. It helps guide how to think about and tackle problems rather than telling you an answer. Any type of model that tries to spit out a distinct answer for you is going to have limited applicability and will probably stop helping you long before you stop using it. When consultants and other business folk hear about some new way of doing things, they try to apply it to everything, and you end up going through the motions of some strange new practice that doesn’t apply to selling or making widgets. You can’t apply the quadratic formula (-b±√(b²-4ac))/(2a) to everything, so it makes me wonder why consultants and others try to apply their formula to everything.
Cynefin isn’t a formula, so it won’t provide the answers. It can help guide actions. So let’s take a look:
The above model is Cynefin’s framework and a map of how we conceptually move through different domains depending on the intricacy of the situation where we find ourselves. It’s a simple layout of how you can think about the domains in which you reside at any given time. When I say domain, I am talking about the nature of a given scenario, problem, or situation. So let’s keep it simple and start with the simple domain.
The simple domain is just that, simple. It is where thoroughly categorized and defined social situations and work come into play. “Best Practices” is the most relevant here, because someone has predefined the decisions that we need to make when we encounter a simple scenario. For example, if a customer comes into my store and presents me with an item that they want to purchase, then I would complete the transaction in the following fashion:
Most transactions proceed in this fashion, and they will likely continue to proceed in this fashion as long as people purchase things in person. Even when transactions become more complicated or there are other issues that arise, most stores have automatic protocols for how to handle such issues.
The manager’s job is to train people on the best practices involved in something within the simple domain. Their boss’s boss probably designed those best practices or implemented them from someone else’s example. As a non-manager, you don’t necessarily need to improve upon something involving best practices. It is your job to execute best practices effectively and without any major speed bumps. The place where you can shine within the simple domain is incremental improvements to a process. Take the above transaction for example. One might incrementally change the process by always handing the customer a receipt rather than asking if they want one. When I go to CVS, they just hand me my mile-long receipt rather than asking me if I want one, forcing me to stand there for a moment wondering if that receipt for my candy bar should be retained. Is it an improvement in the process? It might save time or it might make customer interaction better since you aren’t forcing an arbitrary decision upon the customer.
A common mistake that people make in the simple domain is in their attempts to reinvent a process. Frustration comes for the worker when a manager says, “We have always done it this way,” but it is a relevant response when the way they’ve been doing it has so far been effective. Fear not, because “We have always done it this way,” is almost always a terrible response as you move toward the complex and chaotic domains.
If you are operating in the simple domain as part of your job, you can make important contributions, but set your expectations toward minor enhancements rather than trying to replace a functioning process with an entirely new process that you think might be slightly more functional. The beauty of minor enhancements is that you can often implement them by yourself and present your findings to management later, leading to improvements that you just created. Hopefully the simple domain does not slide off a cliff into chaos as your job will become that much harder if nobody realizes that the simple processes are actually chaotic.
The complicated domain is where you find experts in specialized fields. These experts will sense the stimuli, analyze them, and respond based on the best course of action. For example, when you go to the doctor’s office for the first time, they ask you extensive questions about what they call your chief complaint(s), and then you usually need to fill out a form about your medical history and often a family history. The doctor will then take all of this information to get a sense of what the root cause of your chief complaint could be. Often it is simple. Congratulations, you broke your leg, but when it is slightly more complicated and elusive the physician needs to sense all of the different variables rather than walk into the room and hand you a pamphlet saying, “Well here is a list of things it could possibly be based on just your first statement.” In the sensing portion, gathering information and expertise is paramount to the success of your endeavor. For a manager, this means gathering experts when attempting to solve a complicated problem.
In a hospital setting with a very complicated case, they might gather an assortment of specialists who have seen the patient’s set of symptoms. For something involving cars, a manager may gather an assortment of cars to identify how to best solve a given car’s problem. For you, it works a little differently. If you’re not in management, you often can’t just gather up the experts and set them loose on the problem. In the complicated domain, you’re often either the one tasked with solving the problem and likely a manager, or you’re an expert in a field who is supposed to help solve that problem. When you are neither of those, there are a few things you can do that will benefit you and your organization:
Start to become an expert in problems that show up routinely.
This may be simple. For instance, you might be excellent at writing very concise emails. Look above to see that this person is not me. Or you might understand something like Tailwind, Material UI, or a number of other tools that can benefit those who might need it. I became an expert in Jira so that I can quickly solve any problem related to the administration or use of Jira in general. Jira is so complicated that you often see it on people’s resumes.
Learn to identify the experts (This is an expertise in itself).
When I first arrived at Echobind, my primary goal was to figure out what everyone excels at. When you know who the experts are, finding solutions to problems becomes much easier. Instead of banging your head against the wall, it becomes better to ask the expert. I am often asked to identify the individual who knows about a certain subject. When directly asked about something, I always know who I can talk to in order to get the required information. It is always better to say “I know who can answer that,” rather than just, “I don’t know.”
Learn to identify when an expert is needed.
At Echobind, we have clients who have novel approaches to new problems, and it is not always easy to know when an expert needs to be consulted. When it comes to our medical clients and dealing with HIPAA, we always know when an attorney needs to be consulted rather than trying to wing it and put a client in hot water. Getting the right experts in early can save you and your clients a lot of money in the long run, and it can prevent you from attempting to solve a problem that has already been solved or attempting to solve a problem in a way that leads your organization into a regulatory gray area.
With these personal practices, you can become an effective participant in complicated domains that require more than best practices and have yet to travel to more chaotic domains.
Complex and complicated seem like very similar domains, but there is an important difference.
When you work within a complicated domain, experts can help you navigate the information that has been gathered until they reach a solution to the problem, or they can at least lead you to what the likely outcome is based on that information. Contrast that with the complex domain. Even for someone who routinely operates within a complex domain, it may not be obvious what is going to lead to a solution.
A common example of a complex domain is that of a battlefield. On the battlefield, any experienced commander will tell you that you can’t apply the same solution to every situation, even when the scenarios are quite similar to ones they have seen before. If you have ever heard “No plan survives contact with the enemy,” it’s partly due to the complex nature of a battle. The complex domain is dependent on exaptive or emergent practices. This means you are going to discover practices and methods based on your experience with vaguely similar scenarios.
As an individual contributor, it will be your job to supply new approaches to your managerial staff that rhymes with what they have seen before. You don’t need to rip the box apart in order for your new ideas to take hold, and ultimately you don’t want to. The biggest and most important challenge you will face is convincing your manager(s) that you are in a domain where you cannot apply best practices.
Best practices have absolutely no business being in a complex domain. Best practices have bounded applicability, which means that they have limited value depending on the scenario in which they are applied. Often, best practices only apply to extremely narrow scopes. In a military engagement, you would not hear a commander refer to flanking as a best practice that should be applied to every scenario. It can be effective in many engagements, useless in some, and quite impossible in others, so it should never be called a best practice. So how do you convince your managers that best practices don’t apply to your situation? Apply it quickly and expertly, then collect the data. Managers don’t want to hear that it doesn’t work before you do it, so there is a chance that you need to apply their best practice as well as apply your own idea to make a comparison.
This is where you will see things like A/B tests. Google famously A/B tested 50 separate shades of blue in order to decide which shade of blue will net them more ad revenue. A/B testing is a pretty common practice in making a decision, and something like testing so many shades of blue would be more emergent than best.
The chaotic domain is one of the worst domains to be in, and if you routinely find yourself in the chaotic domain, it might be better to find a new job rather than try to be effective in it. If you are wondering what a chaotic environment would be like, think 9/11, Hurricane Harvey, or any unprecedented disaster. In a product manager’s world, this means disastrous site crashes and a near-constant need to merge directly into the main branch in the hopes that your hotfix will correct everything while your phone continues to buzz with the aggression of every executive stakeholder.
Characteristics of the Chaotic category:
First, you need to identify yourself in such a chaotic environment. Are you a ‘first responder’ or are you in a position that cannot immediately affect the problem? If you’re the first responder, there is no time for data gathering, and finding the source is not going to fix the chaos right now. You need to ignore management for the most part unless they have information that will help you plug the leak or put out the fire.
Are you not one of the devs on the ground? Then you need to be Guy Fieri During the California wildfires, routinely cooking food for the brave firefighters battling wildfires.
Be useful and get out of the way. If your organization is routinely in a chaotic situation, then it might be time to evaluate your continued attendance.
No matter which domain you are in when solving problems or working toward a common goal without the authority that comes with a management title, your first priority becomes identifying the type of domain you’re in. Then you need to act in such a way that brings the most value without getting trapped in best practices with bounded applicability. Management can get stuck in the methods that helped them succeed without reevaluating if those practices still bear fruit. A good manager can have outdated practices and still know when they have a valuable member of their team, and the domain you find yourself in will dictate how much you can upend traditional paradigms.