Consider these three situations:

• You’re at home on a Saturday when your phone blares. A page has escalated to you. One of your teams has been dealing with a data integrity issue that has caused a production outage for the last 30 mins, and the current incident commander doesn’t know how to proceed. What do you do?

• You are tasked with launching your company’s flagship product to an overseas market. None of your team members are from this locale nor speak the language. The product only operates domestically right now. What do you do?

• One of your company’s client-operations teams is asking for advice on choosing software tools to help them scale. You volunteer, since you’re a founding employee and once managed client relationships yourself. What do you do?

Take a minute or two to think about your answers to these questions.

Got them? Good.

Now, ask yourself:

1. Why did you make the decisions that you did?

2. How satisfied are you with your own explanation?

If you answer falls short of “extremely satisfied”, I hope you’ll find something useful in this series of posts.

In this post, we’ll describe a framework for identifying what kinds of decisions we should be making in any given situation. In subsequent posts, I’ll enumerate some exercises that I find useful to help teams make decisions together.

Situational Awareness

As I grew into my leadership career, I found myself responsible for making decisions that were all over the map in terms of scope and complexity.

As a software developer, I’d learned a lot about solving problems; however, more and more, I was finding myself in situations where solving problems was the easy part.

People also often wanted to know the reasoning behind my decisions — especially when they’d seen me decide differently in a similar situation before. I did my best to explain myself proactively, but I rarely felt great about it.

Once, at an offsite, a peer commended me for “situational awareness.” This made me feel both good and bad. I was happy that they respected my decision-making, but sad that this sounded like a polished version of “you seem to have a good intuition but I don’t get how you do it.”

I realized that the methods I’d learned for decision making were either extremely specific or extremely general.

On the specific side were things like Agile methodologies, product development methods, etc.—frameworks built for specific outcomes.

On the general side were things like Type 1 vs. Type 2 decisions and… not much else, other than generic leadership principles or trendy one-liners.

It never occurred to me to look for something general enough to work in any context, but specific enough to suggest concrete actions. I was left with chalking it up to situational awareness.

The Framework I Didn’t Know I Wanted

While studying an ostensibly unrelated topic (program management) I stumbled across a framework called Cynefin (pronounced kuh-NEV-in.) When I saw it described as a ‘sense-making device’, I rolled my eyes a bit and skimmed ahead.

However, after seeing a couple of related charts in the section, I realized I’d found something I never knew I wanted – a rubric for making myself aware of what decision-making context I was in.

(Image sourced from here.)

That helpful peer who commended me for ‘situational awareness’ was onto something. I had been sensing what kinds of decisions the situation required based on intuition. These charts helped me classify each situation and explain why certain kinds of decisions were needed.

Reading further, I discovered that Cynefin has been criticized for basically being too weird and fluffy to use. In this post, I’ll try to distill the concrete parts I’ve found useful, and then suggest some ways of putting these ideas to practical use.

Cynefin

Cynefin classifies situations into five “buckets”. Each bucket requires you to make different kinds of decisions to be effective.

Clear

If the situation is clear, it means you deeply understand it and that there are many opportunities to apply best practices.

Personally, I’m so used to things being hard that I tend to assume that ‘clear’ situations never happen. However, it’s important to recognize when they do. If you don’t adopt best practices in areas that are important to your business, you’re just giving your competition free opportunities to beat you.

Imagine you’re setting up a VPN for your 200-person company. If you don’t apply best-practice here and the VPN has issues, you are draining everyone’s productivity for a no good reason.

In a clear situation, you want to

• establish the facts,
• identify the instance of the problem you need to solve, and
• respond by following a best practice.

Complicated

In a complicated situation, you know what you don’t know. You’re not sure of the relationship between cause and effect yet, but you know what kinds of analysis will help you define it.

This is the domain of engineers. In a complicated situation, there is typically a well-defined problem with a range of right answers, and there are meaningful trade-offs between them.

For example: “We need to enable feature-flags in our legacy distributed web-app so that we can A/B test new ideas.” In this situation, there are many ways to proceed, but you need some combination of expert analysis on both the context and the feature-flagging solution to figure out what might actually work best.

In complicated situations, you want to:

• Seek expert analysis,
• Define requirements of a good solution,
• Evaluate solutions based on those requirements

Complex

In a complex situation, you don’t know what you don’t know. You may not know what the problems are yet, or they may defy strict definition.

For example: “We want to triple the adoption of our product in the next 12 months.” This problem is easily defined, but it’s really hard to know what you don’t know about the reasons more customers aren’t adopting your product.

In complex situations, you must find ways to run safe experiments to help sense what is going on, and then decide how to respond.

This might result in a family of complicated or clear problems, to which you can more readily apply analysis or best practice.

Complex situations can be really hard on people who are used to wearing a ‘complicated’ hat. They often know a lot about their area, and so we really need their input, but but they struggle to work in environments where the problems don’t easily yield to direct analysis.

If you’ve ever seen someone throw up their hands in a problem-definition meeting and demand “I don’t understand what problem we’re trying to solve!” you’ll know what I’m talking about here. (For the record, the answer “yes, that’s the reason we’re here” is not super helpful when this happens.)

When faced with this scenario, I find it more helpful to:

1. Propose a handful of naive experiments myself, and
2. Supply the reasoning I used in coming up with that list.

I’ll then get the complicated-friendly folks to evaluate those experiments. In this context, they’re usually much more comfortable with responding to ideas with new ones, rather than generating them from scratch. This helps bootstrap a list of more useful experiments.

In summary: In a complex scenario, you want to

• Run safe experiments to sense what’s going on
• Analyze the outcomes
• Choose how to respond

Chaotic

For me, chaotic situations tend to feel like complex ones, except there’s significant element of imminent danger. Things are awful, it’s too dangerous to wait for results from a well-reasoned experiment, and people are looking for a quick way out of the frying pan.

In this situation, you need to move towards control and stability ASAP. The hope is that you can act in a way that removes some of the urgency, and converts the chaotic situation into a complex one.

High-impact production incidents are a classic example of chaotic situations. The folks accountable for the outcome need to take control and act in a way that stabilizes the environment so that everyone else involved can start to remediate the issue.

This doesn’t always mean acting on the problem itself; for example, the incident commander of a production incident might first make sure that:

• The right people are available to pitch in
• Customers have been properly notified
• Internal stakeholders are aware and, at worst, only yelling at the incident commander instead of the whole team

This creates a more stable environment where the folks responsible for fixing the problem have the space and resources they need to understand what is going on. This looks a lot more like a complex problem now.

In a chaotic situation, you want to:

• Act to stabilize it
• Sense if your stabilization efforts are working
• Choose how to respond

Disorder

Have you ever felt like there were several extremely urgent or important problems on your plate, but you have no idea how to proceed? Perhaps everything seems critically important but also unactionable at the same time. This happens to me several times a year, and it’s extremely bewildering.

I think this happens to every senior-ish leader eventually. You know there’s urgency, you know there’s danger, but when you look at the immediate actions you can take, they all seem like mush.

This is how I recognize disorder.

You can think of a disordered situation as a happy collage of all the other kinds of situations that we just described. That is, you have a mess of clear, complicated, complex, and possibly chaotic situations, and it’s up to you to figure out what to do with them all.

When this happens, you want to:

• Enumerate all the situations you think you’re dealing with
• Classify each as clear, complicated, complex, or chaotic
• Use these classifications to decide how to start making decisions in each area
• Get to work :)

This process is one of the most helpful un-sticking tools I have in my toolbox.

Homework

Here are some exercises that can help you put Cynefin into practice.

Reflect

Use your current work to reflect on how Cynefin might help you.

1. Write out a few different situations that you’re in right now.

2. How would you classify them using Cynefin?

3. Write out a few decisions you’ve made in each situation recently.

4. Do those decisions match the kind or order of decision-making that Cynefin would suggest? Whether the answer is yes or no, are there any insights this gives you?

Be aware

Whenever I pick up a new tool or idea, I like to start just by developing an awareness of it, instead of trying to use it right away. Once the awareness is built, the rest tends to come naturally.

As you move through your workday, try to be aware of what kind of situation you’re in according to Cynefin.

If it’s too onerous to think about or refer back to the whole framework, try using this algorithm:

Are you confident that you know what the problem is?

if yes:
    Does this feel like a "commodity" problem?
    if yes:
        It's probably "clear".
    else:
        It's probably "complicated".
else:
    Does the situation feel confusing or dangerous?
    if yes:
        It's probably "chaotic".
    else:
        It's probably "complex".

If you run through the algorithm and you feel like the answer to these questions is in some uncomfortable superposition in your head and you really want to go work on a pasture somewhere raising sheep, you’re probably in “disorder”.

At the end of the day, reflect on the kinds of situations you were dealing with. Does this bring you any insights?

Search for tendencies

I imagine that the majority of people feel most comfortable in one or two of the contexts described by Cynefin. For example, I’d expect most engineers to be comfy with complicated, and most scientists to be comfy with complex.

With this in mind, ask yourself the following questions:

1. When you were reading this guide, did you recognize classes of situations that you gravitate to?

2. Do you react badly to other modes?

3. Can you become more aware of this?

Now, think of some of your closest co-workers. Ask yourself the same questions about them. Does that give you any insight into how you’ve been working together? With this insight, can you think of ways to collaborate more effectively?

Postscript

Thanks to Dan Langer for his feedback on an earlier version of this post.