A matter of meta
After yet more aggressive unpleasantness and put-downs over my attempts to resolve ‘the Cynefin problem’ in enterprise-architecture, I think I may have at last found the real source of the repeated miscommunications that have taken place.
The clue comes from a Tweet by Richard Veryard:
#entarch Can’t judge “fit” btwn two frameworks from within either framework, you need a metaframework (shudder).
The problem seems to be this:
- Cynefin is a framework – a model and a collection of related practices.
- It is also a metaframework, in a somewhat limited sense of ‘meta’, in that the framework and the related practices are purported to be generic and may be applied in any discipline.
- What I’ve been describing throughout these posts is a usage of the ‘Cynefin categorisation’ (Simple, Complicated, etc) – i.e. the content of the model, without specific incorporation of the related practices. (I have been explicit all along that this is what I’ve been doing, but that point seems to have been missed. 🙁 )
- This usage of the Cynefin categorisation is actually the expression of a metaframework – not a framework itself, but a ‘framework to define frameworks’. The metaframework is based on systems-theory principles, including themes such as rotation (checklists etc), reciprocation and resonance (as in ‘hard-systems’ theory etc), and recursion and resonance (as in ‘soft-systems’ theory etc), and in this specific ‘Cynefin-like’ instance uses the ‘Cynefin categorisation’ as its base-frame, for cross-comparison with other matching cross-maps for the purpose of layered sensemaking. The internal structure and foundation is thus significantly different from that used in the Cynefin framework – and at no point have I made any claim that they are the same.
- One of the key points above – as stated repeatedly in all of the posts – is that this ‘Cynefin-like’ metaframework is not ‘the Cynefin framework’: it merely uses the ‘Cynefin categorisation’ as its base-frame. Multiple ‘cross-map’ frames are then applied to the context: cross-maps from the original Cynefin model (e.g. ‘probe > sense > respond’ etc) might be used, but so might many, many others – none of which ‘are’ Cynefin. The various cross-maps are highly likely to deliver sensemaking interpretations that are different from those that would be achieved by using Cynefin alone – in fact the whole point is that it does deliver different results – and, conversely, any attempt to interpret the results solely in Cynefin terms will often make no apparent sense. It is not Cynefin – attempts to interpret it as such, or critique the results as such, are essentially operating from premises which do not apply in that context, and are inherently invalid for that purpose.
- The usage of the ‘Cynefin categorisation’ as a base-map in this way – as a metaframework – is merely one instantiation of a whole class of metaframeworks that use other key models or frameworks as base-maps. Other base-maps for such metaframeworks include extended-Zachman, Five Elements, the tetradian four-dimensions, OODA, PDCA and so on. (Some of those base-maps might use the Cynefin-categorisation as a cross-map on their own base-map – which will cause even more confusion if someone mistakenly interprets this usage of the cross-map ‘as’ Cynefin.)
- The class of metaframeworks is defined by a metametaframework, referred to as ‘context-space mapping’.
- Trying to interpret a framework (such as a single instance of a base-map/cross-map combination) from another framework (such as Cynefin) is essentially meaningless, exactly as Richard Veryard indicates in his Tweet above – the underlying premises won’t line up, so there’s no sensible or meaningful way to do a comparison between them.
- Trying to interpret a metaframework (use of the Cynefin-categorisation as a base-map in context-space mapping) in terms of a framework (Cynefin) by definition will make no sense – they’re functionally different as well as different in their premises.
- Trying to interpret a metametaframework (context-space mapping) in terms of a framework (Cynefin) will really make no sense.
- Unfortunately, all of this meaningless misinterpretation does seem to be exactly what’s happened here.
Which is odd, because such meta-relationships are not unusual: for example, every enterprise-architect is familiar with the relationship between models (e.g. UML models), metamodels (e.g. UML itself) and metametamodels (e.g. MOF, of which UML is one instantiation). Yet from the above it does seem that the main basis for all of these attacks comes down to one key person failing to understand these rather important distinctions about meta-layering.
Oh well. But I do just hope that this will at last dispose of those utterly pointless arguments, anyway?
My ‘aha erlebnis’ here is: makes absolute sense as application of any framework is … subject to context, including other frameworks. The very use of frameworks influences the sense it/they make relative to context. I view and use Cynefin mostly as a metaframework for general (social) use and apart from linking to underlying approaches. I rather/even ‘claim’ the static quadrants are rather ‘dimensions’ and thus complexity includes simple and complicated elements and is even (context / time related) determined by them. But, am I making sense ..?
Yes, you’re making perfect sense – to me, anyway. 🙂
Context is certainly the key here. The point that you’re making about ‘dimensions’ seems to be the same as what I’ve referred to elsewhere as ‘recursion’ – re-viewing what is viewed through the frame and the frame itself in terms of itself. I would certainly agree with you about viewing quadrants as dimensions, anyway – ‘dimensions’ are a very useful way to look at this (with an emphasis on ‘useful‘ rather than ‘true‘, by the way).
The key point about a framework is that it provides a defined way of looking at things, and suggested actions based on what is seen via that ‘way of looking’. Which is very useful, when we already know what to do, and can accept the view via the framework as ‘true’. Which, as per the previous post, indicates that in terms of recursion, frameworks themselves tend to end up being somewhat Simple – such as others have pointed out re Six Sigma, for example.
When we don’t know what’s going on, and are not sure of the best approach, that’s when we need metaframeworks, so that we can try on different frameworks for ‘best fit’ to the context’. We may also need a metametaframework to select the appropriate metaframework, and so on, in exactly the same kind of recursive layering that we see in the OMG-type standards (UML, MOF, ORM and onward). (Another similar approach is the Causal Layered Analysis methodology, used in sensemaking for social futures, and sometimes described as ‘poststructuralism as method’.)
For quite a long time now, the only aspect of Cynefin that I’ve used is its basic categorisation (Simple, Complicated etc) and, to some limited extent, its concept of pathways (though in context-space mapping the pathways are much more multi-layered and may often straddle problem-space and solution-space). Everything else about Cynefin is so fraught with difficulties – as we’ve seen too often on this weblog – that in my opinion it’s unfortunately best left alone.
Hi Tom,
I’ve come to the conclusion that Cynefin pulls off a very strange feat.
As a mental construct, Cynefin is a wonderfully pratical and effective tool for managers who are more comfortable with traditional cause-and-effect thinking.
The genius and value of Cynefin is to give these traditional managers “permission” to embrace the idea that some problems are Complex and cannot be reduced or managed by throwing expertise through linear project planning and standardised procedures.
Ironically, this “permission” comes from the existence of the Chaotic domain. You’ll notice that in the pathways diagram you reference in a previous post, there are two ways out of Chaos. First to the Simple domain (imposing order through sheer managerial will) or to Complexity (recognising the futility of fixed solutions and switching to an iterative sense-respond pattern).
The model also validates their “preferred” mode of management thinking by including the two traditional modes of organisation — the ‘staff-as-replaceable-resources’ call center mode (Simple) and the ‘hire-the-best-to-get-the-best-results’ model (Complicated).
The result is that Cynefin fits beautifully into a manager’s mindset and need for a self-narrative.
The problem is that there is only small evidence for Cynefin as a theoretical construct that has any basis in reality. This means that you can’t reason about it or build on it.
The reality is that all systems involving humans are complex, pure and simple. The Cynefin domains actually impose distinctions where none are required. In my view, we don’t need Cynefin to reason theoretically and instead just need one simple equation: increasing organisational structure and constraint reduces the requirement for individual expertise at the cost of long-term adaptability and innovation in problem solving.
Given your antagonism with Dave, I would simply recommend that you don’t reference Cynefin. In my view, it doesn’t add enough value to the way that you want to analyse enterprise architecture.
“The result is that Cynefin fits beautifully into a manager’s mindset and need for a self-narrative.” That’s a very good point, and one I hadn’t noticed before: many thanks indeed for that. I’m mainly a theorist of enterprise-architecture and the like whose main focus is in rather abstruse areas of metamethodology and metastructure: much of that work is about making it real, making the theory useful and practical, but sometimes I do forget about simple everyday realities such as the social-dynamics of large organisations… 🙁
“The problem is that there is only small evidence for Cynefin as a theoretical construct that has any basis in reality.” For obvious reasons, I will be very very careful to keep out of that one… I don’t use any of the formal Cynefin methods in my work, so it’s not any concern of mine anyway. The only point I’ll comment on there is that, for the ‘Cynefin categorisation’ (Simple, Complicated etc) itself, and the notion of pathways between sensemaking-modes and the like, there’s actually no need for any ‘theoretical construct’: it’s just a ‘view’, a way to look at things.
“In my view, we don’t need Cynefin to reason theoretically and instead just need one simple equation: increasing organisational structure and constraint reduces the requirement for individual expertise at the cost of long-term adaptability and innovation in problem solving.” I was about to disagree with you, then re-read the bit about “at the cost of” and realised that you’re right. 🙂 The value of the Cynefin-categorisation is that its framing of ‘problem-space’ helps to identify where automation is viable (Simple to Complicated) and where it isn’t (extreme Complicated, most Complex, Chaotic), what types of organisational structures will work in each type of context, and so on. It’s not about “reason theoretically”, it’s just a sensemaking/decision-making frame, that’s all.
I do (strongly, painfully) take your point about “don’t reference Cynefin”: it’s just that the basic Cynefin-categorisation is so useful in my work that it’s difficult to step round it (and I get accused of ‘plagiarism’ or worse if I do, so it seems to be a no-win either way 🙁 ). The real point that I’ve been trying to hammer home for months is that none of this is about Cynefin as such: it’s about the overall process of sensemaking and decision-making. (I do believe that Cynefin-proper – the full framework and practices, rather than just the basic categorisation – could have some real value within enterprise-architectures, but I’ll admit I haven’t actually found any uses for it in my own work as yet.)
In any case, Cynefin and context-space mapping are fundamentally different: Cynefin is a framework, context-space mapping is a metametaframework. As above, the actual core of context-space mapping is a set of very straightforward ideas from systems-theory, that again don’t actually need a ‘theoretical basis’ because they’re so straightforward. The detail is in my books, such as ‘Everyday Enterprise Architecture‘, but we could summarise very quickly as follows:
Rotation: pick a checklist (Cynefin, Five Elements, extended-Zachman etc) as a metaframework (base-map) and initial framework (base-map without cross-maps); use the checklist to provide views on the context; recursively, cross-map other simple frames (PDCA, OODA, effectiveness-map, ISO9000 etc) as frameworks to provide other related views into the same context.
Reciprocation: using the same checklist(s), what are the flows and balances across the context?
Resonance: using the same checklists and the views of flows and balances, where are there feedback-loops, damping, feedback-delays and the like?
Recursion: using the same checklists, what patterns can we identify within the context? at what levels of abstraction? in what ways do they repeat and/or recurse within or between levels of abstraction?
Reflexion: using the same checklists, in what ways can the whole be seen in any part? (i.e. the inverse of recursion)
Apply all of this recursively, such that each frame is used to review itself (which creates the richness of views that we need in order to make sense of true complexity).
We might note that Rotation maps loosely to Cynefin’s Simple, Reciprocation and Resonance to Complicated (‘hard-systems’), and Recursion and Reflexion to Complex (‘soft-systems’). We also need to look at uniqueness (Chaotic), for which use of the Cynefin-categorisation is a particularly useful base-map. But again, it’s not Cynefin. I hope, hope, and again hope that that’s all that need be said on that score.
As it is, and Stephen seems to agree, any(!) framework or even metametametaframework is bound to become restrictive and self-disqualifying when attempting to ‘translate’ it to practicalities. As the Belgian painter Margritte pointed out so well in his painting of a pipe with the words “this is not a pipe” below it, concepts can only reside in a human mind and will immediately lose meaning and substance when ‘put to paper and processes etc.’. I would therefore say that the absolute value of Cynefin as Stephen describes, and with those very limitations, is beyond question. As to the context/time specific ‘application’ of Cynefin, or any other general/meta-framework, the value of it diminishes rapidly and frameworks will even become counter-productive. And, to be frank Tom, your excellent summery of the ‘theoretical basis’ (which is in itself, by nature of any theoretical basis, is a limitation hence limited) did bring the Stacey Matrix (http://pauljansen.eu/images/comple3.gif) to my mind rather then Cynefin. I think this is due to the fact that your summery seems to concentrate on the lower part of the Stacey Matrix, but I’m not sure and might be assuming… which rather confirms my previous point on the limited usability of ‘models’.
Hi Tom,
I quite like your 5 Rs metametaframework (was that the right number of ‘meta’s?) but to be honest, I don’t see how you can adapt Cynefin to apply against this context.
Cynefin is not a “checklist” as you apply it, for example, in your dowsing example some posts ago. A system can only be in *one* of the Cynefin domains at any one time.
So it’s not like Zachman where you go through what/how/where/who/when/why. With Cynefin, you identify the domain that the system currently belongs to and use this as a basis for action.
Thinking about it some more, 5 Rs has a lot of potential as a multi-level complex systems description and analysis tool (and “multi-level complex system” describes just about any modern organisation). Cynefin isn’t good at this kind of nested description — personally I think referencing Cynefin weakens the model rather than strengthening it.
Paul – I certainly take your point about “any framework .. is bound to become restrictive and self-disqualifying when attempting to ‘translate’ it to practicalities” (and I love the Magritte reference!). I’m struggling a bit to follow you beyond that: perhaps I need a more concrete example? My apologies, anyway.
Thanks for pointing me to the Stacey Matrix – I think I’ve seen it before, but I’m not familiar with it. I can see your point about the baseline and technical-simplicity versus technical-complexity, with social-complexity largely squeezed out of the picture by the time-constraint; but I believe I’m describing something somewhat different. If we use the C-categorisation, time-compression in effect means that we don’t have time available to do experiments (Complex) or depth-analysis (Complicated): the only spaces left in the C-categorisation are Simple (aka the Priest, who needs certainty) and Chaotic (aka the Artist, who seeks to become relatively comfortable with uncertainty). So we get sequeezed into a spectrum between those two, which passes from binary-logic (a Simple true/false) through modal-logic (‘possibility and necessity’, a kind of intermediate between Simple and Chaotic, which we also see in a more managed way in the Complex) eventually to an extreme Chaotic ‘anything and nothing is true’). Although there’s some degree to which the Stacey Matrix sort-of makes sense in relation to that, I really don’t think it works: to me it’s more like the Stacey baseline (technical) goes from Simple to Complicated, and the vertical-axis (social) goes from a kind of compressed Simple+Chaotic to Complex. To be frank, I don’t know enough of the context of Stacey Matrix to say much more than that, but I’d be happy to discuss it further with you if it would help.
Thanks again, anyway.
Tom, what I tried to point to is that ‘our society’ raises adults predisposed for the simple/complex (part of) reality, focusing on a controllable, predictable, make-able world. So if you ‘come from the right-side of Cynefin’ a Pavlov reaction to the left-side is often observable. The adagium ‘fighting’ or ‘reducing’ complexity often is a telltale sign of that. Artists (Dali, Picasso et al) seem to be flipped in their predisposition by the way :-). Looking at the 5 Rs I felt that movement from Chaos/Complex towards Complicated/Simple strongly as I believe the proposition of the 5 Rs is to … reduce (the effects of) chaos/complexity. Nothing wrong with that for there are huge benefits of being able to ‘isolate’ simple and complicated parts-of-the-whole that can be dealt with isolated … but that in itself is a ‘slippery slope’. Just as in Architecture in the bricks-and-mortar world we do, indeed, have to ‘capture’ the 4 (!) dimensional result into 2 dimensional parts (drawings, sketches, instructions, partslists etc. etc.) … but the complete total of all these parts combined will never constitute the ‘end-produce’, they merely lead to it. In fact, that is why architecture is so complex :-), and why building-designing (complicated) is often confused with architecture. This ‘phenomenon’ is by the way also what the Stacey Matrix directs to.
While I hope to still make some sense here, I feel that either very good and complete models for ‘the left side’ of Cynefin are actually reductions of ‘the left side’ to make them fit ‘the right side’, or they will only be truly understood and of any value by those adapts already predisposed for ‘the left side’ (Dali, Picasso et al). In other words, the answer to the question ‘why’ for a framework is as context and time relevant, and therefore impossibly generally applicable. I even suggest that the rightful dispute about the Cynefin framework and its spinn-offs is caused by the difference in perception regarding the answers to the essential Q’s (what, how, where, who, when, why) rather then by the (illusionary) objective value of Cynefin, or any other model for that matter. I’ll know when I rambled here when the guy in the white outfit comes to get me. Again.. 🙂
Stephen – “A system can only be in *one* of the Cynefin domains at any one time.”
Really?? Oh. 🙁 If that is the ‘official line’ about Cynefin, then you’ve just shown me a really serious source of clashes, because I’d never understood the C-categorisation in that way. To me it’s obvious that every system is ‘in’ all of the domains, always: each C-domain is simply a way that we choose to look at it, and we need to look at the system from all those different perspectives (hence the ‘checklist’ concept) in order to be able to make practical sense of how to work with it. If I really have misinterpreted Cynefin that badly, then I can understand how someone would get so upset with me; but my answer (defence?) would be that I’d misinterpreted because the original model would not and could not have made any practical sense at all. Yikes…
Surely it’s absurd, though, to say that a complete system is only ‘in’ one domain? What happens to real-world exceptions that don’t fit within the rules and constraints of a single domain? That’s exactly how and why over-Simple tactics like Six Sigma and BPR come to fail so spectacularly in real-world practice, surely? And that’s how I’d always understood Cynefin dynamics, too – that it was the pathways by which we move the perspective between the different rule-sets of the different domains. But if ‘the official line’ is that a system can only be ‘in’ one domain, then, well… uh… ‘yikes’, is all I can say…
“So it’s not like Zachman where you go through what/how/where/who/when/why. With Cynefin, you identify the domain that the system currently belongs to and use this as a basis for action.”
Okay, if Cynefin really is like you say, then what I’ve described is indeed radically different. Since a complete system is always ‘in’ every domain (because a ‘domain’ is simply a way to look at the system), then we do indeed use the C-categorisation as a checklist, in exactly the same way we would with Zachman, or the effectiveness-checklist, or whatever. We then choose different tactics and implementations for the different parts of the system that reflect the different ‘domains’, and we use the pathways between the domains to track exceptions and the like, and the means to handle and transfer those exceptions. Overall, we cover all of the domains, because the systems exists within all of the domains; and the metaframework has to be recursive in order to give us the richness that we need to deal with, say, the Chaotic (uniqueness) within the Complicated (algorithm) and so on.
From what you’re saying, though, this appears to be almost the exact opposite of ‘Cynefin proper’: the way I’m reading you is that we’re supposed to pick a domain – usually Complex – and design everything within the terms of that domain. Is that correct? – because if so, I can understand now why people get confused when they try to read what I’m doing as if it’s ‘Cynefin proper’.
The way I do it is the way most architects actually do sensemaking in practice: once architects start to recover from TOGAF’s IT-centrism and tackle a true whole-of-system context, this is what they have to do, and that’s exactly why I developed this metaframework to help them to do that work. If ‘Cynefin proper’ does it in a different way, no doubt that’s correct in its own context, but it isn’t the way that works within the specific context of enterprise architectures. Doesn’t make either of us ‘wrong’; it’s just different usages of something that on the surface may look vaguely similar but underneath is very different. That’s all I can say, really.
Yikes. Thanks, though…
Paul – “there are huge benefits of being able to ‘isolate’ simple and complicated parts-of-the-whole that can be dealt with isolated … but that in itself is a ’slippery slope’.”
I do take your point about ‘slippery slope’, but the whole point here is that this is all about preventing mistaken attempts to treat things in isolation.
A lot of this is about practical reality. Most of the standard tactics in ‘solution-space’ are, as you say, geared solely to tackle the Simple/Complicated (i.e. ‘automatable’) aspects of a system, and often purport that doing so ‘solves’ the ‘problem’. The point here is to push people into realising that there are always Complex (e.g. emergent) and Chaotic (e.g. unique, ‘black swan’ etc) components to any real-world system, and we therefore need to allow for those when we develop designs for a system – or for anything, really. And we need to allow for them in their own terms – not by pretending that they can be ‘controlled’ as if they’re merely ‘very complicated’ (another long-running argument I and many others have had with Roger Sessions, for example).
I can’t remember if you’ve seen the work I did with Liz Poraj-Wilczynska a couple of years ago on disciplines for archaeography? That’s a relatively new academic area that’s a kind of bridge between classic ‘objective’ archaeology, more recent developments in (again academic) studying the subjective in archaeology (such as sensory-archaeology or archaeoacoustics), and more conventional art-forms such as painting, photography, music and performance-art. What we did was develop a metamethodology that covered the subjective disciplines in their own terms, and linked them together with the objective (‘scientific’) disciplines in an integrated way. That particular work ended up in a peer-reviewed archaeology journal called Time&Mind, and I’ve recently discovered that one of the peer-reviewers was a key player in one of the recent excavations at Stonehenge, so what we did is definitely credible in that academic field at least. We did another variant of it for our book ‘Disciplines of Dowsing‘ – you can download the complete book via that link, or there’s also a shorter two-page summary-sheet of that metamethodology if you want. The point there is that that’s actually another instantiation or variant of the same metametaframework that I’ve described here.
I would certainly agree with you about what (in Cynefin-diagram terms) we might describe as the ‘left-side’ domains and the need to be careful not to treat those domains as if they’re merely some kind of lesser variant of the right-side domains. A lot we could talk about here, but perhaps better in-person rather than through this rather clunky medium? 🙂
Thanks again, anyway.
Tom, after reading your last reply (#9) to Stephen as too your reply (#10) to me, I am assured and confident that ‘we are on the same page’ with regard to the slippery slope … Also I believe that there will ‘never’ be a definitive definition of ‘complex’, ‘enterprise’ or even ‘business’ that will be acceptable to everybody, which (again) proves your previous point about the relativity of meaning with regards to context and time :-). I will keep on cherishing my personal arrogance and attitude with regards to the ‘real truth’ about (the difference between) complicated and complex and I believe you and me are but little apart, if at all, in that.
As soon as I finish my present must-do chores I will look into the possibility of meeting in person. For now the clunky medium will have to do 🙁
This is strictly an opinion…
In EA theory and practice there seems to be an inability to differentiate between “complexity” and “confusion” as causes of inefficiency, duplication, cost, and a host of other ‘negative’ indicators of the overall health of organisational systems (automated or not).
The sad irony of many frameworks (Cynefin included) is that they frequently attempt what I might call ‘lexographical’ solutions. However, coining obtuse specialised terms, or much worse re-defining ordinary terminology for special purpose use generates confusion. It does so because organisational systems are in essence social systems and have behaviours mediated and controlled by natural language.
Here then is where they fall down.
If you take a well defined and effective framework such as the ITIL, you will find some care and attention applied to identifying the objects the framework takes and ensuring that the rest of the framework provides a ‘grammar’ that consistently applies those definitions. So for example key concepts such as ‘service’ ‘change’ ‘incident’ ‘problem’ are explicitly defined. Problems do creep in and especially with similar terms that may be used synonymously in common speech such as ‘incident’ and ‘problem’. But in the end it is possible to point to an event in the organisation and say with some certainty ‘that was an incident’ or another event and say ‘that is a change’.
Confusing frameworks, such as Cynefin, pile ambiguity on ambiguity and we should not be surprised that they are at once comforting to management and causes of confusion and disagreement. The “Cynefin problem” is hypostasis. It assumes a subject matter (system, problem domain, etc) that is ill defined and vague in the first place and applies a classification system for which there can be no agreed characteristics or measurements. There are no agreed definitions of a system, and just what does ‘problem domain’ signify. Worse, there are no agreed definitions for ‘complexity’ in maths or physics and certainly no unit of measure.
As a set of practices Cynefin may embody some common sense, but it cannot really be a model because the underlying ontology is vague. Application of a vague model to any real-world situation will generate confusion.
Moreover the ‘systems’ with which you are concerned are systems that are constituted as the outcome of human beliefs, understanding, discussion and behaviour. The performance of such systems is easily degraded by too much explicit structure. They are better guided by clearly defined shared values and an accurate understanding of their resources and environment. The truth is there are systems within organisations but organisations themselves are not systems in any intelligible way. As a metaphor though the idea of ‘the system’ is compelling.
@Tom G : After your comments, I went and re-read articles available about Cynefin to see if in fact *I* was the one who has misinterpreted the model. (To be fair, I think Dave has been a little vague about this at points which doesn’t help.) From my reading, it appears that thre are two main ways to use Cynefin — as a framework for decision making contexts, and a framework to describe systems.
Read his recent HBR article A Leader’s Framework for Decision Making for a really good summary of how he intends the decision making context model to work. In this article, Dave talks about leaders facing all four contexts “at once” which may be how you are thinking about the model in your EA work.
However, I had been talking about Cynefin in its other context as a *descriptor* of systems. In this model, it makes sense that a system can only be in one domain at one (eg in fluid dynamics, a body of water cannot be both turbulent *and* smooth). But it is also this interpretation which I feel is much less robust and often causes problems.
@Ric : To be fair, Cynefin never claimed to be an EA framework. I’ve always seen it’s strength to be in opening people’s minds to the idea of different modes of problem-solving. In particular, it makes a case for there being situations where it is *not* feasible to linearly and predictably solve problems like most manager like to do.
BTW, I do believe it is feasible to generate models that describe organisational ‘systems’ (but I don’t think Cynefin does a particularly good job of it). The whole field of complex adaptive systems is about predicting behavior in non-deterministic but non-random systems — which is exactly what an organisation is.