Solution-space: Beyond Cynefin?

The previous posts on ‘chaos and Cynefin’ were intended to contribute to an ongoing debate about how to use concepts from the published Cynefin framework and the like, and particularly to underpin a systematic exploration of what many Cynefin aficionados would describe as the ‘Chaotic domain’. It’s evident that there’s a real perceived need there, because overall I’ve so far had several hundred reads, several dozen re-Tweets (particularly via knowledge-management thought-leader David Gurteen and management-consultant Paul Jansen, for which many thanks), and a lot of constructive comments and feedback – all of which have been very helpful.

Unfortunately, as can be seen from his comments to those posts, one person who was definitely not happy about such ideas was the originator of Cynefin, Dave Snowden. So there’s evidently a major problem for us there.

What is clear is that, whether Dave likes it or not, a substantial community already uses Cynefin concepts and Cynefin terminology to describe a kind of meta-methodological ‘solution-space’ within which various methods, methodologies and tactics can be situated, and their respective appropriateness for specific contexts can be assessed. What’s also clear is that, as far as Dave is concerned, we are no longer permitted to use the term ‘Cynefin’ for this ‘framework-that-occupies-much-the-same-conceptual-space-as-Cynefin’: we do need to find an alternative term for this.

In short, to describe that ‘solution-space’, it seems we now need to move beyond Cynefin.

To do that, we need to identify:

• the role and purpose of this ‘not-Cynefin framework’
• how it draws from the published Cynefin framework and/or common usages of that framework
• how it extends and/or differs from the published Cynefin framework
• summarise how this framework would be used in practice

Once we’ve done that, we can perhaps start looking for an appropriate alternative term to describe it. 🙂

This is again going to be long, so I’ll stop here for a moment with a ‘Read more…’ link.

(Apologies: some of this will necessarily be somewhat technical at the start, but the examples later on should bring it down to the practical and concrete.)

It’ll be obvious that there’s a real risk of confusion here around how people have used the Cynefin framework, Dave’s now more-explicit intent for how the ‘Cynefin’ term ought to be used, and the somewhat different direction that this specific usage of Cynefin-like concepts needs to go. In the hope that it’ll reduce misunderstandings, I’ll use the following labels:

• CF (‘Cynefin framework’): the basic Cynefin diagram of four domains (currently labelled ‘Simple’, ‘Complicated’, ‘Complex’ and ‘Chaotic’) around a central region of ‘Disorder’
• CT (‘Cynefin/Cognitive-Edge techniques’): a specific set of techniques drawing on formal theory of complex-adaptive-systems and related science, using CF in various ways, but particularly as an illustration to describe both the problem-space and where those techniques should be situated in terms of overall ‘sense-making’
• UF or ‘the framework’ (‘unnamed framework’): a framework that, like CF, uses an intentionally-loose categorisation of four domains and central region to describe an overall ‘solution-space’, but also permits multiple alternative yet related ‘views’ into that overall solution-space

We also need to distinguish between problem-space and solution-space:

• problem-space is the context of the problem and its underlying factors – for example, in CF terms, whether the factors in the problem can be considered to be Simple (i.e. display linear causality), Complicated (e.g. linear causality with feedback loops and delays), Complex (e.g. retrospective causality) or Chaotic (i.e. display no apparent causality)
• solution-space is the context of the proposed solution and its relationship to the underlying factors of the problem-space – for example, in CF terms, whether the solution-method assumes that everything remains the same (Simple), contextual but predictable (Complicated), highly contextual (Complex) or in some part inherently unique (Chaotic)

CF and UF both describe the problem-space and solution-space; CT is in essence a defined set of techniques that can act on any part of the problem-space but centre on the Complex domain in solution-space.

The reason why this distinction is important is that CT goes “from solution to problem” – in other words, much like most other forms of pre-constructed ‘solutions’, it needs only to seek out those problems for which its techniques are appropriate. But enterprise-architecture, knowledge-management and many other disciplines necessarily operate the other way round, “from problem to solution” – the parameters of the problem need to be identified, and then an appropriate solution identified to match those requirements. The comparison between problem-space and solution-space also indicates the probable consequences of any mismatch. Solution-space is largely irrelevant to CT because for the most part it is already situated in solution-space (specifically, certain regions within the Complex-domain): all it needs to do is find appropriate problems in problem-space to match what it can do.

It should be emphasised that, unlike the CF/CT pairing, no specific problem-space techniques are associated with the framework. (In other words, there is as yet no ‘UT’ equivalent to CT, nor is there likely to be in future. Although both are related to CF, it should become evident below that CT and the framework have fundamentally different functions and purposes: it therefore makes no sense to suggest, for example, that the framework could somehow be ‘better’ than CT, or vice versa.)

Framework role and purpose

The framework (‘UF’) provides a meta-methodology model describing a generic ‘solution-space’, in principle covering every possible method, methodology and pattern of tactics.

The purpose of the model is to provide a means to identify, situate and assess appropriateness of methods within different contexts, and, by corollary, identify probable characteristics of appropriate methods (in solution-space) for different methodological contexts (in problem-space).

The model itself should provide a means to categorise and describe any possible methodological context, including itself.

Similarities to Cynefin

The framework needs to identify distinctive regions or ‘domains’ within the overall solution-space. Terms such as Simple, Complicated, Complex and Chaotic usefully and meaningfully describe such regions.

All potential solutions start from an initial condition of inherent uncertainty (“I don’t know what to do”), described in CF as ‘unknown’ or ‘disorder’.

The regions do not have strict boundaries; there are many contexts in which the regions may overlap or blur. The framework is not a simple two-axis model.

The process of identifying an appropriate solution to a given context in ‘problem-space’ consists of following pathways in solution-space. These pathways may lead to appropriate or inappropriate methods, in relation to the actual needs in problem-space.

The framework provides a means to situate methods and tactics within solution-space. As in CF (but not CT), in itself the framework does not mandate any specific method or technique for use in any given context in problem-space.

The solution-space described by the framework has strong cultural connotations; it is best understood as not so much an abstract concept as an experience, even a way of life, and also has complex connotations of belonging, ‘homecoming’, commitment to and responsibility for place and context ‘as itself’. Aspects are similar in some ways to the Australian Aboriginal concept/experience/etc inadequately translated as ‘the Dreaming’, and also to the Bantu notion of ‘ubuntu‘. In English this may be represented, if somewhat inadequately, by terms such as ‘place’ or ‘space’; Dave Snowden’s use of the Welsh word ‘cynefin’ is particularly apposite here. The framework will need a name that similarly reflects this richness, depth and complexity of meaning.

Extensions to or differences from Cynefin

The framework differs from and extends CF by permitting multiple alternate views into the overall solution-space, whilst still always using the primary set of regions as a guide for comparison and as a base for common interpretation. (Note that some of these views may be simple two-axis matrices, or two-axis spectra. However, this does not mean that the framework ‘is’ a two-axis model – each is simply a selected view into the solution-space, not the solution-space itself.

The framework differs from CT (and to some extent from CF) in that it is not explicitly based in one specific category of science or methodology. Instead, as a ‘umbrella’ description of solution-space, it permits multiple bases of theory, considering theory to be another type of view into the overall solution-space. The model does not inherently privilege any theory over any other: in principle, the overall frame should be theory-neutral. (Note that the purpose of the framework is meta-methodology, not methodology. Any methods used to assess the nominal ‘appropriateness’ of any other method should themselves be situated and assessed recursively within the solution-space. This recursion would apply, for example, to all the methods and techniques within CT.)

The framework differs from CT and extends CF in that it does not privilege any one domain within solution-space. (From all its descriptions, CT appears to privilege the Complex domain in solution-space.)

The framework differs from CT in that the emphasis throughout is on recursive, layered meta-methodology, not method; its methods apply to recursive assessment of appropriateness of methods within solution-space, not to resolution of specific problems in problem-space. In framework terms, CT represents only one amongst a near-infinite range of possible categories of method within the solution-space.

The framework differs from CT in that its methods apply to solution-technique selection, not end-problem; it relates to an earlier stage of problem-resolution than does CT, which assumes that the technique(s) to be used have already been selected. The emphasis is on identifying an appropriate solution-technique before problem-solution can take place. The methods used in conjunction with the framework will often include those familiar in other forms of quality-management and process-improvement, such as the PDCA cycle and After Action Reviews, but in some cases might well draw on CT methods.

The framework contextually differs from CT and extends CF in its description of solution-selection pathways. For example, within the framework, in principle all solution-selection pathways leave the initial ‘disorder’ domain via the Chaotic domain, and may traverse into other domains from there; some solution-techniques remain primarily or wholly situated within the Chaotic-domain of solution-space, though most do not. For CT, all solution-selection pathways should traverse through the Complicated-domain of solution-space (for evaluation in formal scientific terms), and should ultimately lead to regions that are situated primarily or wholly in the Complex-domain of solution-space.

Suggested practice

The previous posts ‘Complexity, chaos and enterprise-architecture‘ and ‘More on chaos and Cynefin‘ summarise the principles for use of the framework, though should now be read in terms of the above description rather the standard Cynefin (CF and/or CT) concepts.

Within solution-space, specific techniques tend to go through the standard Gartner hype-cycle:

• ‘Technology trigger’ (though note that the trigger for a new solution-technique is not necessarily technological): the technique becomes available (i.e. known) within solution-space, usually closely matched at first to a single narrow region in problem-space
• ‘Peak of inflated expectations’: usage of the technique is extended outward into broader and broader regions of solution-space, in some cases to the point where it is believed to be ‘The Answer To Everything’
• ‘Trough of disillusionment’: repeated failures with use of the technique outside of its appropriate region(s) in solution-space lead to increasing rejection of the technique (and often abandonment in search of the ‘next Best Thing’), to the point where it is sometimes believed to have no useful application at all
• ‘Slope of enlightenment’: there is a belated awareness that the technique is neither an ‘answer to everything’ nor ‘useless’, but needs to be situated in appropriate regions of solution-space (i.e. matched to appropriate contexts in problem-space)
• ‘Plateau of productivity’: once the appropriate regions in solution-space have been identified, it becomes ‘self-evident’ as to which types of end-problems the technique applies best, and the factors that drive process-improvement for contexts in which this specific technique is used

For example, Taylorism and Six Sigma apply very well to contexts which have very high repeatability (i.e. are firmly situated in the Simple-domain in solution-space); but they are not well-suited for use outside of that region (hence the misuses of Six Sigma that Dave Snowden decries as ‘sick stigma’). The slide from Dave’s seminar that contrasts Scientific-Management, hard-Systems Thinking and (CT) Sense-Making shows the historical progression of the early stages of the hype-cycle in each case, but crucially it does not situate each category of techniques in solution-space. It correctly describes how techniques have arisen in part as a response to the downward trend of ‘failures’ after the hype-cycle ‘peak of inflated expectations’, but the overall result is a misleading impression that each category is somehow ‘better’ than the previous category in the sequence, when in reality ‘better’ is actually a highly contextual term.

As suggested in the slide, these three examples also provide stereotypes for techniques that are primarily or wholly situated in specific regions of solution-space:

• Scientific Management: Simple-domain
• hard-Systems Thinking: Complicated-domain
• (CT) Sense-Making: Complex-domain

But crucially there are no techniques listed for use in the Chaotic-domain of solution-space, in which the context is primarily or wholly non-repeatable. (An example given in one of the previous posts was sales, in which each individual sale is ultimately a unique ‘market of one’.) Although systematic processes exist for identifying and validating techniques in the Simple, the Complicated and, increasingly, the Complex domains, very little seems to have been done in the Chaotic domain in solution-space – it seems instead to have been dumped into the ‘too-hard’ basket as ‘outside the scope of science’, and hence all but abandoned.

Yet most if not all real-world problems incorporate elements of inherent uncertainty. Hence disciplines such as enterprise-architecture, quality-management and knowledge-management, which of necessity cover the whole of problem-space and solution-space, do definitely require meta-methodology techniques that are able to work within the Chaotic region. Since the other regions of solution-space are already fairly well covered (such as with narrative-knowledge techniques, statistical quality-analysis and so on), transits into, out of and within the Chaotic regions of solution-space (i.e. low-repeatability to non-repeatability) will probably provide the most urgent uses for the framework. Dave Snowden alludes to this in the quote used in one of the previous posts:

I have a strong bias towards the natural sciences and the Cynefin framework is built from a science based position. However … I have seen too many examples of dowsing not to believe it works in some way, I can also see that in all the cases it is a deeply embodied skill that cannot be taught. …  I also have to respect the fact that all controlled tests have failed to establish authenticity. This provides an interesting dilemma. On the one hand I have seen it work with water engineers, and with the man/jcb symbiosis that dug out the drive to the side of my house, on the other hand controlled tests have failed to validate. That means we have a really interesting anomaly that requires investigation.

Dowsing therefore provides a good test-case for the Chaotic-domain of the framework’s solution-space: the techniques must produce concrete real-world results, yet by definition operate in inherently non-repeatable conditions.

Perhaps relevant here is that there is now a fully-worked example for this, documented as the book Disciplines of Dowsing, which I co-authored with archaeographer Liz Poraj-Wilczynska. (Archaeography is a relatively new sub-domain of formal archaeology, providing a disciplined, structured bridge between conventional ‘objective’ archaeology, art and culture.) Within it we used a variant of the framework with domains described as follows:

• Simple domain (‘inner / truth’): ‘Mystic’ mode (aka ‘Priest’)
• Complicated domain (‘outer / truth’): ‘Scientist’ mode
• Complex domain (‘outer / value’): ‘Magician’ mode (aka ‘Technologist’)
• Chaotic domain (‘inner / value’): ‘Artist’ mode

A set of characteristics are defined for each mode:

• its role within the overall discipline or practice (of dowsing, in this case)
• the type of ‘world’ (region of solution-space) which the mode will cover
• the core emphasis and types of response within the mode
• when to use this mode within the overall discipline
• how to identify when this mode is already in use – “You’ll know you’re in this mode when…”
• rules, guidelines or principles that inherently apply within this mode
• warning-signs of potential problems within this mode (i.e. misalignment between problem-space and solution-space)
• ways to bridge across to other modes (i.e. triggers for transitions and/or pathways within the solution-space)

These are summarised in a two-page reference-sheet and described in more detail in pages 31-70 of the e-book version of ‘Disciplines of Dowsing‘, which can be downloaded for free from here.

During live field-work, the practitioner will, in effect, frequently return to solution-space to tackle routine methodological concerns, including:

• “Which mode am I in now?” (i.e. which region of solution-space) – compare the roles for each mode, or the “You’ll know you’re in…” lists, or work it out backwards from the rules or guidelines in use at present
• “If I’m in this mode, which rules apply?” (i.e. intersection between problem-space and solution-space) – look up the rules from the list for the respective mode – and check against the respective ‘warning-signs’ list to test if they’re being blurred with the rules for another mode
• “Which mode do I need to be in?” (i.e. selection of region within solution-space) – look up the “You need to use when…” lists, and pick out the appropriate mode for the task in hand (i.e. in problem-space) – and remember also to use the new mode’s rules, not those of the previous mode
• “If I’m in this mode, how do I switch cleanly to another mode?” (i.e. transition within solution-space) – look at the respective ‘bridge’ list – though note that switching to the ‘diametrically-opposite’ mode (i.e. Chaotic <-> Complicated, or Complex <-> Simple) may well seem hard at first

The book also includes (in pp.71-95 of the e-book) what are described as ‘Seven Sins of Dubious Discipline’, which exemplify particular ‘clusters’ of common errors within solution-space:

• The Hype Hubris – in effect the same problems as described at the ‘Peak of Inflated Expectations in the Gartner hype-cycle
• The Golden-Age Game – similar to the Hype Hubris, but frequently coupled with an extraordinarily arrogant ‘holier-than-thou’ type of self-image
• The Newage Nuisance – a kind of half-baked misuse of techniques, in effect a complete mismatch between solution-space and problem-space
• The Meaning Mistake – a specific class of of errors that can occur in relation to the Complicated-domain of solution-space (for a real-world example, see my earlier post ‘Dowsing the flames‘)
• The Possession Problem – a specific class of errors that occur at another level of meta-methodology, when understanding of both problem-space and solution-space is forced into the Simple-domain via mistaken notions about ‘possessing the truth’ about a given problem and/or solution
• The Reality Risk – a more subtle class of risks (and sometimes genuine dangers) that may occur in the Chaotic-domain of solution-space
• The Labyrinth Lessons – issues that arise as a consequence of specific stages in the sequence of skills-development, both in implementation of the actual skill (i.e. in problem-space) and in developing and understanding the principles and practice of the skill (i.e. in solution-space)

These tactics are all directly applicable and re-usable in just about any other discipline or business-domain, especially those that of necessity must transit into or through the Chaotic-domain of solution-space. For example, we’ve already adapted these for use in archaeography and archaeology; I’m currently in the process of adapting them for use in values-architecture and enterprise-architecture.

Constructive comments, suggestions and other ideas most welcome – there’s a lot we can do with this.

Over to you, anyway – and thanks.