More ‘Cynefin-like’ cross-maps (‘Beyond-Cynefin’ series)
(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)
Another collection of ‘Cynefin-like’ cross-maps that I’ve found useful in various aspects of my enterprise-architecture work:
- Repeatability and ‘truth’
- Marketing versus sales
- The ‘Plan / Do / Check / Act’ cycle
More details after the ‘Read more…’ link.
Repeatability and ‘truth’
A straightforward cross-map, in some ways very close to the original Cynefin concepts. This is one example where it might make more sense to show the domains as a vertical stack.
The real-world is ‘disorder’: everything else is an abstraction. The Chaotic domain is the simplest abstraction, in that it asserts that, in principle, everything is context-dependent and nothing is repeatable. The Simple domain represents the opposite extreme, in that it asserts that there is ‘absolute truth’ and perfect repeatability – with a concomitant tendency to complain that the real-world is being somehow ‘unfair’ or ‘wrong’ if it does not conform to the expected ‘truth’. The Complex and Complicated domains fit somewhere on the spectrum between these two extremes, with the Complicated domain preferring stronger abstractions, and the Complex domain accepting that reality isn’t quite that simple.
Marketing versus sales
A useful cross-map that explores the perennial clash between Marketing and Sales.
Once again, the reality of the market is that it is ‘disorder’: any other view of it is an abstraction.
The most Simple market is a monopoly. You set the rules, then the others (especially the ‘consumers’) have no choice but to buy according to your rules. In an all-too-literal sense, you possess that portion of the market, and hence that portion of people’s lives, too. Much of it is about trying to control what people do, often in a very physical sense: people are treated as objects or subjects rather than as people. It makes marketing very simple – in fact ideally there is no need for any ‘marketing’ as such – but there are two very real dangers. One is that it’s an extreme abstraction of reality, and if reality moves away from alignment with that purported ‘truth’, the market can sometimes vanish overnight – as happens quite often on the internet, for example. The other is that monopolies often breed deep-seated resentment, and if the monopoly cannot be bypassed, the resentment may explode elsewhere – as happened with the British monopolies on salt, fabrics and many other essential items in colonial India. We see much the same in perhaps lesser form with Microsoft’s dominance of the operating-system and office-software markets – contexts where a ‘natural monopoly’ will tend to occur simply because of the need for information interchange. So whilst possession may seem like the best possible strategy, the long-term consequences can be much more severe than they look.
Most conventional marketing fits firmly in the Complicated domain: crunch the numbers, map the trends, analyse every-which-way to find out how to make the market predictable. People tend to be regarded as units of information, a datapoint within the statististics, rather than as individual people; in fact it’s very much about information, the conceptual dimension, and often also about trying to ‘control’ what people think about a product or service. (Trying to determine what people feel pushes the emphasis more towards the Complex domain, whilst the common notion here of ‘taking control’ of a market pushes the emphasis the other way, towards the Simple domain.) Note also the cross-map with timescale: marketing may occur before or after but not at the exact moment of sale.
We move into the Complex domain of marketing by regarding people more as people rather than as ‘consumers’. Complexity means much more acceptance of human factors, of ‘wicked problems‘, and also by weakening the separation between ‘us’ (‘producers’) and ‘them’ (‘consumers’) – as can be seen in the success of Amazon’s customer-driven ranking as a marketing strategy, in some forms of crowdsourcing, and also in Agile-type development where the customer is also part of the development-team. The central theme here is about relationships, which, although still ‘abstract’ in terms of timescale, may in effect extend and push the boundary of this domain quite a long way towards real-time, into what would otherwise be Chaotic space – such as via the tactics and strategies described in Dave Snowden’s recent seminar on complexity.
Yet by definition, Sales reside in the Chaotic domain, because every decision to buy or not-buy is a quantum-event, a ‘market-of-one’. The ultimate drivers for such decisions are values-based, not ‘rational’ or ‘truth‘-based, which means – as just about any good salesperson would tell us – that the focus here is on aspirations. Given that sales deals with real-time events, we’re somewhat forced into the principles-versus-rules spectrum: online sales will go toward the rule-based end of the spectrum, because that’s all that IT systems can do, but real salespeople working face-to-face with real clients or customers (not ‘consumers’ here) will recognise key principles such as the need to listen – and also to know when to stop talking, so as to allow space for the decision to take place.
This cross-map also shows us that, by definition, the conventional approaches to sales and marketing are diametrically opposed by the nature of what they do and how they work; but we can bridge that gap somewhat via either the Complex domain of emergent marketing, or by the Simple domain of IT-based sales (supported, again, by cross-links to the Complex domain to remove the risk and resentment around perceived monopolies). Which approach is ‘best’ in each case will depend on the context – which this cross-map, and others, will again help to identify.
Plan / do / check / act
Another very useful cross-map that helps to clarify what’s actually happening within the PDCA improvement-cycle.
The cycle starts with Plan. This is primarily about information, and takes place before real-time contact, both of which tend to place it in the Complicated domain.
The aim of the Plan is to create rules that are Simple enough to apply in real-time when we Do the actual work. Although ‘work’ can take many forms, it still needs to be made concrete in some way in the real world, which in effect places an emphasis on the physical dimension.
The work is not abstract: it happens in the real world, in real-time – in other words, in terms of the ‘Cynefin-like’ frame, a transit through ‘Disorder‘.
On completion, we move back out of real-time to reflect on the difference between what we’d intended (Plan and Do), what actually happened (transit through Disorder – i.e. difference between abstract intent and concrete reality), and what we can do about it (Check, leading to Act). Learnings need to be both personal and collective, which places us on the ‘values‘ side of the ‘truth’/’value’ spectrum; long-term experience indicates that such learning takes place in a social or relational context, away from the action, through tactics such as After Action Reviews – all of which indicates that this part of the cycle situates in the Complex domain.
The outcome of the Check phase is a set of guidelines for revised future action, on which we need to Act so as to embody the required changes in personal awareness and action, via a personal review of the underlying principles of the context and how they apply to that specific individual. To change how we work also requires that we face the personal challenges implied by any kind of change, so it’s also about personal aspirations and personal responsibility, in the sense of ‘response-ability’ – the ability to choose appropriate responses to the context in real-time action. Ultimately all of this is unique to the individual, a ‘market-of-one’ – and hence places this phase of the PDCA cycle in the Chaotic domain.
We then wait for an appropriate new real-world context – in other words, another transit through ‘Disorder‘ – to start the cycle again with a new Plan.
There are several ways in which the cycle can fail. One is that an obsessive production-oriented context skews the path through Disorder, to give a tighter loop of Plan / Do / (Disorder) / Plan. This cuts out Check and Act – which may seem unnecessary in the short-term, but is probably disastrous in the medium- to longer-term, since it assumes that the rules created by the plan will always apply. This is not so much Simple as dangerously simplistic.
Another type of failure occurs when extreme self-doubt skews the other return-path through Disorder, to give a probably even-tighter loop of Check / Act / (Disorder) / Check. In effect, this is a kind of personalised version of ‘analysis-paralysis’ – much may be learned, but nothing is actually done!
Yet another failure-loop is Plan / Do / (Disorder) / Check / Plan, in which the review takes place, but pressure of work forces a return to the Plan phase before any actual change can be embedded in personal action. This is perhaps the least effective form of ‘process-improvement’, but seems depressingly common in real-world business-practice.
—
Some more cross-maps still to come in this series, including one on skills and another on the role of automation, but I hope you find these useful for now, anyway.
As usual, any constructive comments, ideas and suggestions would be most welcome 🙂 – over to you on that?
Previous posts in this series:
I’m not sure why PDCA would be cross-mapped over the entire CF-like framework. It seems to me that each domain has a separate PDCA cycle, the result may or may not cause a transition into another domain when going from Check to Act.
I.e., in the Simple domain, PDCA is all just a part of standard quality management/continuous improvement – however it is possible that the result of the “Do” (as found by the “check”) may cause the situation to be thrown somewhere else. (Maybe not quite as likely in the Simple domain, but anything is possible).
In the Complicated domain, the PDCA is, again, trying to improve the situation by, possibly moving things into the Simple domain (assuming that this is a desirable goal). However, there is always the possibility that these actions, too, will cause the situation to be moved into the Complex, or even the Chaotic domain.
The purpose of the “Check” in each domain’s cycle would be to analyze the result of each “Do” to see if we achieved expected results (i.e., that the result ended us in the correct domain, and that we are able to determine if we achieved our desired results and/or what adjustments might get us closer to them.)
In the Chaotic domain, it may be that there isn’t as much emphasis on “Plan”, realizing that we’re trying to perform some action and hopefully get some result that we can measure, and which moves us away from that quadrant as quickly as possible. However, from an Enterprise Architecture perspective, relying on values/principles to drive the “Do” and “Check” steps of the PDCA cycle within that domain is one way to judge the result of our “Do” actions. And these values/principles are, in essence, a part of “Plan”ning.
So, just speaking from the rafters of all of this, I’m wondering if it is unnecessary, and maybe even detrimental, to try to map the PDCA cycle over the entire CF-like domain model.
Jeff – That would be another way of doing it, yes – and one I hadn’t thought of, so many thanks indeed for suggesting. The whole point about these cross-maps is that they provide an anchor for sensemaking – and one of the important side-themes of that is that what works for one person doesn’t necessarily work for anyone else.
The difference between the two approaches – mine in the post, and yours here – is that I was trying to explore how a generic PDCA sequence moves across the ‘solution-space’ (in effect using a secondary cross-map to the Jungian-type frame I’d used in the previous post), whereas you’re more exploring how PDCA itself would need to change in contexts with different types of repeatability (i.e. different ‘domains’). That’s a much more sophisticated and nuanced approach to ‘solution-space’ than I’d been using in these fairly basic cross-maps, and to me it’s one that well worth exploring further. Over to you on that, perhaps? – would be very interesting to see where you take it.
Thanks again, anyway. 🙂