How do *you* make decisions?

/via https://marketoonist.com/2006/04/the-decision-matrix.html

“IT DEPENDS”
Seriously, how do you decide what to do? Do you just wing it? Or do you have a detailed “if — then — else” flowchart that you follow?
The answer is, most likely, some variation of “it depends”, right? I mean,

• • “Should I put my shoes on?” is obvious— “I’m going to the gym, so yes, I should put my shoes on”
• • “Which flavor of gelato should I order?” is complicated, with some serious expertise necessary to resolve— “I’m in NYC, not Sicily, but the reviews say this tastes authentic, and they say they use Bronte Pistachios, so yes, I should order Pistacchi”
• • “Why did Alice’s grades suddenly go to shit this semester?” is way more complex. There are so many things happening in her life in this, her third semester, and it’s likely that there might actually be more than one actual cause. What you probably do is — delicately! — probe, to try and make sense of what’s going on. “So, honey, you haven’t talked much about …” is just the start of it.
• • “OHSHITOHSHITOHSHIT THE TURKEY IS ON FIRE AND THANKSGIVING DINNER IS IN AN HOUR!!!!” is chaotic. The fire-alarm is going off, there is smoke in the kitchen, the dogs are barking their heads off, Uncle Joe just puked in the fireplace, and everybody is yelling their damn-fool heads off. That said, the first thing you do is put out the fire. And then you figure out the rest (open the windows to let the smoke out, put the dogs out in the yard, ask Carol to deal with the Uncle Joe/Fireplace situation, and then start figuring out whatTF to do about dinner)

The point here is that these problems needed completely different ways of thinking about the problem space. To put it differently, the context in which you worked when it came to making decisions really depended on the type of the problem, right?

CYNEFIN
As it turns out, back in 1999 David Snowden — at IBM Global service then — came up with a framework called Cynefin to standardize this process.

Cynefin (/ˈkʌnɪvɪn/ KUN-iv-in) is a way of thinking about situations by slotting them into four categories — Obvious, Complicated, Complex, and Chaotic. (•)

It bears some explication, so here goes —

Obvious situations are ones where the cause and effect are clear and well known. Think of the things that can be solved by a help-desk — the things that you can put into a script for a CSR, well, those are the things that are Obvious.
The approach you want to take in these situations is
1. Figure out what the situation is (sense)
2. Identify the specific problem at hand (categorize)
3. Provide a standardized/scripted solution to this problem (respond)

Complicated situations are ones where the cause and effect are still clear and well known, but the connections between the two are not necessarily so obvious. There might be multiple solutions to the problem, and the specific one may depend on the particulars of the problem. This is the domain of engineering, medicine, and so-on, where you need expertise to tease out the facts.
The approach you take here is
1. Figure out what the situation is (sense)
2. Get all the details necessary to identify the specifics of the problem (analyze)
3. Provide a solution tailored to the problem at hand.

Complex situations are ones where there really is no clear cause and effect, and worse, no real “correct answer”. Oh, in retrospect a correct answer will be very obvious, but when you’re going through it, boy howdy, are you clueless. If anything, you don’t even know what questions you should be asking! The only way forward is experimentation, to wit “Poke at it and see what happens” . 
Seriously, what you do is
1. Gather knowledge about the system through experimentation (probe)
2. Use the data you gather through probe to figure out what the underlying issue might be (sense)
3. Once you have enough information, make a diagnosis (respond)
And yes, the above is, basically, every episode of House ever 🙄

Chaotic situations are ones where you, basically, have no idea whatTF is going on. Things have gotten crazy, the light at the end of the tunnel is an oncoming train, etc. The important difference between this and Complex situations are that here things are unpredictable. Small differences in initial conditions — butterflies flapping their wings! — can lead to drastically different conditions.
The way you deal with these situations is
1. Triage. Seriously. Just stop the bleeding, and do anything to just get to an island of stability (act)
2. Once you’ve stopped the bleeding, try and figure out what is going on by moving the problem to one of the other realms (Complex, Complicated, or if you’re very lucky, Obvious). This is when you think of things like “Should we roll back to a previous release?”, or “What if we add more servers”, etc.
3. Assuming that you’ve managed to come to a resolution, act on it (respond)

The interesting thing about this is that good engineering is all about moving clockwise towards Obvious. No matter where you start, you want to end up in a place where everything is neat, tidy, and predictable!

WHERE ARE YOU?
The tricky part in all of this is that you really really need to make sure that you are in the right domain for what you are doing. And this, my friends, is where I see most of the badness these days, with most of it stemming from overconfidence.

Emergent Behavior is everywhere in the world of software. That reaping algorithm that deals with stale messages in your message queue? The one that works just fine till, when you added that 17th worker, performance cratered by 1000x? Stuff like that is everywhere in what we do, and doubly so when you look at any kind of distributed system (and these days, everything is a distributed system…). And the thing about emergent behavior is that’s what takes situations from the world of Obvious to, well, somewhere else (Complicated if you’re lucky. Chaotic if you’re not).

And then there is the whole Complicated vs Complex bit. Complicated situations are already bad enough, since your resident #CowboyDeveloper already believes that he knows more than he actually does (Hello Dunning-Kruger!). It gets worse in Complex situations, because here, there is no straightforward answer! You have to probe, to experiment and analyze results, to be willing to give up on your pet hypothesis and move on. And if you refuse to acknowledge this, well, you end up with solutions that are band-aids at best, and rube-goldberg devices at worse.

The thing about the above is that patches that are implemented when you mistake Complex situations for Complicated ones actually do more harm. They risk tipping the entire situation into a Chaotic realm—largely because the more moving parts you have, the more likely that you don’t quite understand what is going on.

KNOW WHERE YOU ARE
The bottom line here is that you really need to understand where you are, to be able to deal with the situation properly. Assess the situation, and respond based on the realm you are in — anything else risks disaster. Oh, it may not happen immediately, but it will happen!

(•) There is also Disordered, which is the little area in the middle. It’s where you are when you don’t know where you are…