Two SCAN notes – 1: Edges

The SCAN framework describes sensemaking and decision-making in terms of four distinct ‘domains’, by convention labelled as Simple, Complicated, Ambiguous and Not-known. But what happens at the edges?

(The domains themselves are fairly distinct, anyway, in the sense that viable sensemaking and decision-making tactics change radically from one domain to another. Note, though, that the boundaries between those domains can move around dynamically, often by quite a lot, and it can sometimes be useful to use other labels too – as we’ll see in the next the other of these ‘Two SCAN notes’ posts. Also – and importantly – the whole thing is fractal and recursive: a context that seems to be ‘in’ some domain or other will always contain elements of the others as well. Yeah, it’s kinda tricky… But let’s get back to this part of the story for now.)

In an ecosystem, most of the most interesting things happen at the edges. And it looks like much the same would be true of SCAN: what’s come up in the past few weeks is that the edges between domains – the transitions between different overall approaches to sensemaking and decision-making – seem almost to be the key to the whole thing.

(A quick note for Cynefin aficionados: you should probably see some similarities here with the ‘Cynefin dynamics’, the putative pathways between Cynefin domains. Some aspects of those similarities would arise automatically, because the two frameworks do apply to similar and related needs and concerns; but there are also some fundamental differences, particularly around how the flows actually work in SCAN, and what passes along them. As a result of that, you may find that there are some potentially-useful cross-maps between the two frameworks on this matter of edges – though for various reasons I’d best not comment on it any more than that.)

I introduced this notion of edges in SCAN, in a lighthearted way, in the slidedeck for my presentation at the Integrated-EA 2014 conference. What I’ll do here in this post is provide a bit more detail.

Overview

SCAN has two dimensions:

  • vertical-axis of arbitrary scale from ‘NOW!’ to infinity, in effect representing the amount of time still available before a decision for action (at ‘NOW!’) must be made
  • horizontal-axis of arbitrary scale from absolute-certainty (left) to absolute-uncertainty (right), or absolute-sameness to absolute-uniqueness, or any similar dichotomy of that type

In practice, there is a distinct boundary that occurs at some contextually-variable point along each of these axes:

  • vertical-axis: ‘transition from plan to action’ – decision-making is simplified right down (typically to predefined rules or principles) to enable action at the highest possible speed, by minimising the need to stop and think during action
  • horizontal-axis: ‘boundary of effective-certainty’ – on the left-side, decisions are essentially known or knowable (‘tame-problems’), whereas to the right, decisions become increasingly ambiguous and uncertain (‘wicked-problems’)

In effect, this partitions the context-space map into four ‘domains’, with dynamically-variable ‘size’, dependent on the effective positioning of those boundaries within that context:

Although there are only two boundaries in this schema, this in effect gives us four distinct edge-transitions:

  • edge of action: transition between plan and action, where the decisions about what to do are essentially already-known
  • edge of uncertainty: transition between certain and uncertain (‘known’ versus ‘unknown’), but at some distance in time from the point-of-action
  • edge of innovation: transition between plan and action, where the decisions about what to do are not already known or certain, and/or where new information or experiences are needed or implied
  • edge of panic: transition between certain and uncertain, or known and unknown, either at or close to the point-of-action

Or, in visual form:

The next sections describe in turn what happens at each of these edges.

Edge of action (Simple :: Complicated)

The transition across this edge is the difference between plan and action:

  • plan is what we intend to do in the expected conditions
  • action is what we actually do in the actual conditions at the time

(In some ways, it would be more accurate to replace the label ‘Complicated’ with ‘Theory‘, and ‘Simple’ with ‘Practice‘, but the terms ‘Simple’ and ‘Complicated’ have become so well established now that it’s probably best to leave them as they are.)

In the feedback-loop across that edge:

  • ‘Complicated’ provides simple rules for Simple to enact in real-time practice – often packaged as an actionable plan

But (to paraphrase von Clausewitz) “no plan survives first contact with Reality Department”; hence:

  • ‘Simple’ returns information etc about realities, to help Complicated revise the plan – preferably in near-real-time

We can see this happening recursively in contexts such as help-line service, where the realities coming ‘upward’ from one level have to be escalated to successively-higher levels of Complicated in order to be resolved, and then finally filter back down again as successively actionable ‘rules’. At each move ‘upward’, the focus moves further and further away from the immediate real-time contact, and requires increasing levels of ‘time to think’ – though note that each level, recursively, also has its own versions of Simple and Complicated, of action and ‘stop and think for a moment’ plan.

Edge of uncertainty (Complicated :: Ambiguous)

The transition across this edge is the difference between analysis and experiment:

  • analysis refines existing answers (via algorithms etc) to derive usable rules for Simple, but is unable to handle anything ‘outside of the box’
  • experiment applies questions (via guidelines and patterns) to variously-unknown contexts, in search of usable answers

Note that both of these sets of activities take place at some distance in time ahead of the moment-of-action:

In the feedback-loop across that edge:

  • Complicated passes to Ambiguous any questions that it cannot resolve within its existing algorithms
  • Ambiguous passes to Complicated any answers that are (or seem) sufficiently-certain for Complicated to be able to use

Again, this is recursive, with level upon level of complexity being addressed, usually further and further away from the moment-of-action. (‘Complexity‘ here is a catch-all term for everything that happens in these two ‘upper’ domains – which, via recursion, also in effect occurs in the ‘lower’ domains, though in less overt or visible form.)

Edge of innovation (Ambiguous :: Not-known)

The transition across this edge is the difference between semi-structured experiment and free-form exploration:

  • experiment applies hypotheses to test possibilities with a given context
  • exploration will delve into a context to elicit ideas and experiences

Note that both of these sets of activities take place under varying and, often, increasing uncertainty:

In the feedback-loop across that edge:

  • Ambiguous passes to Not-known various principles that provide some form of reference, guidance, anchor or ‘seed’ for sensemaking in the real-time ‘unknown’ – “in the field of exploration, chance favours the prepared mind”
  • Not-known returns to Ambiguous various ideas, information and other news that may be used in experiments

It’s important to note that, by definition, the only place where anything new can be found is in the Not-known. If we are to find the ideas and experiences we need for invention and innovation, we need to be willing to “become comfortable with being uncomfortable” in the Not-known, and to work with that ‘the unknown’ in real-time, rather than only ‘from a safe distance’.

Edge of panic (Simple :: Not-known)

The transition across this edge is the difference between structured-process and free-form improvisation:

  • structured-process follows predefined work-instructions to deliver a predetermined outcome in a (nominally) known context
  • improvisation follows chance and serendipity – often with the assistance of guiding principles and ‘seeds’ – to return a useful and/or meaningful experience within a potentially otherwise-unknowable context

Note also that both of these sets of activities take place at or close to the moment-of-action:

In the feedback-loop across that edge:

  • Simple passes to Not-known its fears, arising from loss of certainty, or from real-world responses that don’t match Simple expectations
  • Not-known returns to Simple any options that are (or seem) sufficiently-certain for Simple to be able to use

Note the symmetry here with the questions and answers that pass back and forth between Complicated and Ambiguous: the difference is that for the Simple::Not-known loop, all of this happens at or near real-time, and – for humans – often carries an emotional-loading that is not (or, ideally, should not) be so prevalent further away in time from the moment-of-action.

An action-checklist is a classic example of a tool that bridges across this edge:

(c) OCFlightCenter – click to see original PDF

The routine checks (in black, in the checklist above) provide Simple rules to guide real-time actions – whose purpose is to minimise the risk of traversing over to the ‘uncertainty’ side of the context. The emergency-checks (in red, in the checklist above) are called-for when fears arise as the context moves too far into uncertainty, and provide options that can be tested and acted-on in a Simple way – ideally returning the context to return back over to the certain/Simple side.

Linking it all together

In any real-world context, all of these domains and edges will be in play in some way or other, all interleaving with each other at various distances from the respective moment-of-action, and at varying degrees of certainty or uncertainty.

In that sense, all of the feedback-loops will be happening at the same time, in various ways and in varying levels of priority and relevance for the immediate context in play.

The catch here is that different tactics and techniques are needed in each of the different domains, such as in this visual summary:

The fundamental requirement here is “don’t mix them up!” – trying to use techniques from one domain in a different domain is usually not a good idea… (The one place where it can be useful in the Not-known domain, where the mismatch acts as a kind of reframe – in other words, as another form of recursion!) Hence, in turn, it’s really important to be aware of which domain is effectively in play at any given moment, and/or which edge is being traversed, and in which direction.

Overall, yeah, all a bit technical, I know… But it really is worth the effort to step back a bit sometimes, and watch how all of this works in real-world practice – because it’s how we do get better at doing things more effectively, and in ways that we actually want.

Posted in Complexity / Structure, Enterprise architecture Tagged with: , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*