Decision-making – linking intent and action [1]

How is it that what we actually do in the heat of the action can differ so much from the intentions and decisions we set beforehand? How can we bring them into better alignment, so that we do ‘keep to the plan’, at the individual level, and across the enterprise? And once again, what implications does this have for our enterprise-architectures?

This extends the previous posts on SCAN sensemaking and real-time decision-making, ‘Belief and faith at the point of action‘ and ‘Decision-making – belief, fact, theory and practice‘, this time to explore the linkage – or lack of it – between ‘considered’ decision-making and real-time decision-making.

[As before, most of this is ‘work-in-progress’, so be gentle with it, okay? 🙂 It should be usable as-is, but do expect odd gaps, rough-edges and wobbly-bits in various places, and please give constructive feedback where you can. Thanks!]

We started from the SCAN sensemaking-frame:

And reviewed it from a perspective of decision-making rather than sensemaking:

It’s actually the same frame, so the two axes are the same in both views:

• a ‘horizontal’ axis of modality of sensemaking and decision-making, from simple true/false on the left, to infinite-possibility on the right
• a ‘vertical’ axis of time-to-decision or time-to-action, stretching from a real-time ‘now!‘ to a potentially-infinite future (and some symmetry with time-from-decision etc, into the past)

The vertical-axis is essentially continuous, but the horizontal-axis has a distinct phase-shift where the modality of decision changes from a simple-true/false [0..1] to an open n-ary [0..n] choice. To the ‘left’ of this point, the apocryphal Einstein dictum applies: doing the same thing should lead to – or is believed to lead to – the same results; whereas to the ‘right’ of that point, doing the same thing may lead to different results, or doing different things may lead to the same results.

On the left-side, there is what purports to be ‘objective certainty’; on the right-side, there is, by definition, some degree of inherent-uncertainty, always somewhat context-specific, and often somewhat personal and subjective. A conventional ‘control’-based concept of the world assumes that everything can somehow be forced onto the left-side of the frame; Reality Department and real-world practice indicates that such concepts of ‘control’ are still wishful-thinking at best, and that alternate decision-strategies must be available, dependent on context.

Hence one of the key tasks of an enterprise-architecture is to ensure that all required decision-methods are supported, and also ensure that appropriate methods are applied to each context.

The previous post, ‘Decision-making – fact, belief, theory and practice’, mainly looked the ‘horizontal’ dimension of this frame; here we’ll explore the impacts of the ‘vertical’ dimension – specifically, the separation between intent and action.

Two parallel paths

We have a plan. An intent. We’re sure we’ll know what to do when the time comes. And yet, to paraphrase von Clausewitz, no plan survives first contact with Reality Department. What we intend doesn’t happen the way we’d planned. (Or perhaps, even stranger, we were equally sure that we wouldn’t know what to do, and yet we discover that we did know what to do – but have no idea how.)

In short, there’s a difference between intentions and expectations beforehand, and what actually happens in real-time action. And we’d like to find some way to close that gap, and create better results overall – whatever those intended results may be.

That’s where continuous-improvement or continuous-reassessment tools come into the picture – techniques such as PDCA and OODA, for example. Likewise the US Army’s After Action Review, four questions that cross-link with the PDCA cycle:

• “What was supposed to happen?” – to answer that, we need some grasp of Plan or intent
• “What actually happened?” – to answer that, we need to be able to observe what we Do and did
• “What was the source of the difference?” – to answer that, we need to be able analyse, assess, Check and compare
• “What do we need to do different next time?” – to answer that, we need to find the courage to face up to change, and to Act to align our capabilities to align better with that actual or needed change

All of these review/reassess processes cycle through the ‘vertical’ dimension, always returning to real-time action, yet catching a variously-brief breath away from the action to create space for reflection and change. There’s often a lot of recursion in this, of cycles-within-cycles – as is particularly clear in OODA – yet in essence it always depends on availability of some time away from the action. If the only time allowed is the ‘now!‘, that also blocks access to any means to adapt to changes in context – and that’s an all-but-guaranteed recipe for decision-disaster…

So to make it work – to create effectiveness within the enterprise – we’ll usually need a lot of vertical movement in SCAN terms. Yet as we saw in the post ‘Belief and faith at the point of action‘, there’s usually also a lot of to-and-fro across the horizontal direction, between closed belief and open faith. And between those two different movements – cyclical and recursive in one direction, a more context-driven back-and-forth in the other – this can get real confusing real fast if we’re not real careful: mixing up the different modes usually leads to unintended outcomes.

Yet the Inverse-Einstein test – that horizontal distinction between true/false versus modal n-ary decision-making – runs right the way through the frame, giving us something that we can use as an anchor to keep the decision-making and capability-development more stable. That anchor gives us a means to keep the moves separate:

• at real-time and at any given distance-from-action, move back-and-forth horizontally across the decision-modality, to identify or apply appropriate decision-rules
• review-processes apply vertically, at a given level of decision-modality – which often also aligns in practice with a given skill-level

So the Inverse-Einstein test gives us two distinct parallel paths in the ‘vertical’ direction, for review and capability-development: one whose core focus is on ‘truth‘, based in true/false logic; the other on usefulness, or ‘value’ in a subjective sense, based on a fully-modal decision-logic. In effect, that’s CP Snow’s ‘Two Cultures‘:

• the sciences emphasise certainty, linking Simple to Complicated, Assertion to Belief
• the humanities emphasise personal-experience and trust, linking Not-known to Ambiguous, Use to Faith

In reality, of course, they do connect horizontally with each other – technology being the obvious example. But the connection only works well when it’s at the same time-level, the same distance-from-action.

What we don’t want – what we need to avoid – are unintended ‘diagonal’ moves across the frame. Ambiguous ideas will confuse and fail as Simple rules, for example, whilst Complicated assertions applied as certain ‘truth’ in the Not-known at real-time are rarely a good idea:

• markwfoden: RT @webisteme : Simple rules lead to complex behavior. Complicated rules lead to stupid behavior

In short, what we do want is this:

And what we don’t want is this:

The next question, of course, is how we support all of that in our enterprise-architectures.

Implications for enterprise-architecture

Probably the key point for architecture is this: at the moment of action, no-one has time to think. And yet we still have to do the right things, and do them right, without being distracted by the need to think.

Things have to work according to a combination of very simple, immediately-accessible, no-thinking-required rules, and free-form trust and faith, a letting-go into the ‘flow‘ of the moment. In practice, that’s what we most need our architecture to support: or, to put it another way round, everything else exists to support what happens in that real-time action.

Everything we build in the architecture also needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context. It needs to ensure that we have the right sets of rules for action when rules do apply, and the right experience such that the fallback into faith is as effective as possible whenever the rules don’t apply.

The key role for an organisation is to help make ‘the right things happen right’, in accordance with the needs of the extended-enterprise that’s shared with that organisation’s customers, clients, suppliers, partners and other stakeholders. The organisation aligns itself with the enterprise-story, and brings its resources and capabilities to bear on some selected subset of that enterprise’s problems, desires and needs. Hence, in turn, the role of the enterprise-architecture and domain-architectures for that organisation is to provide appropriate support to identify, track, design and change those ‘response-abilities’ of the organisation.

All of that should be straightforward enough, I hope. Yet what it implies is that, within the architecture, we’ll need to include:

• services to support each sensemaking/decision-making ‘domain’ within the frame
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

– part of which, in turn, requires:

• a radical rethink of ‘command and control’ – especially its (mis)use as a management metaphor

Deal with the last point first, perhaps: rethinking command and control. As described in the post on insuperordination, we’re still often stuck with a legacy management-model that is grossly inappropriate for most current business-needs, and perhaps always was. In conflating genuinely-useful for ‘tree’-type service-oriented aggregation-structures with largely mythical notions of hierarchy and importance, we’ve ended up with management-structures that assign ‘rights of command-and-control’ over ‘subordinates’, regardless of whether the ‘superiors’ actually have the competence and knowledge to make the required decisions – which, in many of the highly-volatile business-contexts of today, they generally don’t. The result, in all too many cases, is a management-mess: the near-total antithesis of efficiency, effectiveness or relevance.

In short, far from being the ‘solution’ that it purports to be, Taylorist-style hierarchies of one-way ‘command and control’ from ‘owners’ to ‘managers’ to ‘workers’ are one of the most serious sources of problems in enterprise-architectures. The way forward, architecturally speaking, is to rethink the nature and role of ‘command and control’, and to separate it from those redundant management-myths.

Perhaps surprisingly – or perhaps not – some of the most active proponents of such a rethink are the US military: in particular, the work of David Alberts and others at the (US) Dept of Defense Command & Control Research Program. To be blunt, they’re literally decades ahead of where most business-organisations are today: see, for example, ‘Command Arrangements for Peace Operations‘ (1993) [PDF] or ‘Understanding Command and Control‘ (2006) [PDF]. (The mini-book ‘Power to the Edge‘ is rather better-known outside Defense circles, and is a must-read for anyone involved in organisation-architectures or enterprise-architectures.)

[Quick note: for enterprise-architects and others, I would strongly recommend any of the work of Alberts’ and his team, such as those books above and their most recent book, ‘The Agility Advantage‘ [PDF]. For managers and other business-folk, perhaps think of this as Sun Tzu’s The Art of War, brought up to date? – and just as important, too.]

In essence, the classic hierarchical model assumes that command and control are essentially the same: a command from the ‘superior’ is expressed as orders that control the actions and results of the ‘subordinates’. Alberts’ work indicates that command and control are radically different – in particular, that the concept of ‘control’ only makes sense for things that can be controlled via simple true/false logic, such as machines. For anything else – including real people – the closest that we can have to ‘control’ is ‘commander’s intent’: a ‘command’ that explicitly acknowledges the existence of inherent-uncertainty and, preferably, the degree or extent of that uncertainty. In short:

• ‘control’ applies primarily to decision-making on the left-side of the SCAN frame (Assertion and Belief)
• ‘command’ applies primarily to decision-making on the right-side of the SCAN frame (Use and Faith)

It’s perhaps useful to compare this with the Cynefin framework, especially at real-time. On the left-side or ‘control’-oriented side of SCAN (the equivalent of Cynefin’s ‘Simple’-domain), the Cynefin dictum of ‘sense > categorise > respond’ does make practical sense: whatever is sensed is matched against predefined categories, which then elicits responses in terms of that structure of ‘control’. Yet on the right-side of SCAN at real-time (equivalent to Cynefin’s ‘Chaotic’-domain), the Cynefin dictum of ‘act > sense > respond’ makes little to no sense at all: in effect, it assumes the absence of any guiding ‘commander’s intent’ or equivalent – which could indeed lead to the wrong kind of chaos.

[Cynefin works well enough at a good distance-from-action, but in this sense can be actively misleading relative to any real-time context. Yet real-time is literally where the action is. It’s a problem…]

This again is where the distinction between ‘organisation’ and ‘enterprise’ is useful. An organisation is bounded by rules, roles and responsibilities, which does allow for the possibility of something that resembles ‘command = control’, though only within the scope of that organisation. Yet once we move beyond that scope, or have to work with partners and other stakeholders who are beyond the remit of the organisation’s rules, and may well conflict with them (as Alberts describes in ‘Command Arrangements for Peace Operations’), we are then in a context which is literally ‘beyond control’ – and we need a form of ‘command’ that does not assume indisputable equivalence with ‘control’. For those purposes – in fact for anything on the right-side of the SCAN frame – we need to move to a form of command based more on the shared-enterprise, bounded by shared (or at least agreed) vision, values and commitments.

Hence enterprise-architecture, rather than solely organisation-architecture – and rethinking ‘command and control’ to match that broader scope.

(I’ll split this here and tackle the remainder in another post. Any comments so far, though?)