Many people believe that complexity is just higher order complicatedness i.e. that there is a continuum and that the difference is one of degree, not type. When one considers however how very different these states are from each other, I tend to agree with Dave Snowden when he says that there are in fact phase shifts between them i.e. they are fundamentally different types of systems.
Why is this important: as long as decision-makers believe they are dealing with complicated systems, they will assume they are able to control outcomes; find solutions to problems and waste a lot of money on expert consultants to give them the “answers”. For organisations to become more resilient and sustainable, business science simply has to move beyond its Newtonian foundations towards an understanding of complexity.Sonja Blignaut – 7 Differences between complex and complicated
I’m sitting on a plane as it boards, wanted to jot down some quick thoughts. I’ll come back in later to clean it up, add some links (that you are going to want to check out) and make it a bit more coherent.
In a blog post earlier today, Jim McGee discussed the boundary between strategy and tactics, how it used to be “well defined” – some people did strategy, some did tactics, and the two didn’t really overlap. But how it never really was so cut and dried and how we are realizing that. But we aren’t the first.
I’m currently reading Walter Isaacson’s new bio of Leonardo da Vinci, and one of the things that marked him as different in his time (and any time before him) was his realization that there are no straight lines or sharp edges in nature, and his incorporation of this knowledge into his art.
Then of course fractals and complexity.
Speaking of which, Dave Snowden recently wrote about the liminal spaces between the different sections of Cynefin. For example, the boundary between complexity and the complicated; going from one to the other is not a straight line boundary, there is an overlap.
Note: This post references concepts explained in the Cynefin framework.
The typical organizational decision making process treats most operational issues as if they are Ordered, a complicated (or obvious) problem that needs to be solved. Based on your understanding of the situation you develop several courses of action, based on rules or “good practices” that have worked to some degree in the past, and implement a course of action with the belief that you can accurately predict the outcome of implementing the course of action based on past experiences. This assumes, in general, either a relatively static (non-adaptive) situation or a situation that develops in a predictable manner.
Many situations we face today, however, fall increasingly in the complex domain. In this case, you respond to the situation without any separate and discreet analysis or planning. If your actions don’t achieve the desired results, you take what you’ve learned (sense) and respond again. You don’t know what you are going to need to do until the situation presents itself, and you don’t know if it will work until after you’ve tried.
To dip into a pop culture reference, an episode of the TV show “The Last Ship” presented a scenario in which both obvious, complicated, and complex challenges presented themselves, all as part of the same situation. This is a very condensed description tailored to fit this conversation.
The ship is hunting – and being hunted by – an enemy submarine.
The Captain is on the bridge and his staff is providing him the information he needs to decide the appropriate course of action. A well defined task, with years of training and experience, he knows exactly what he needs to do, and his staff know exactly how to respond to the Captain’s orders to achieve the desired result. Obvious.
The ship’s sonar was damaged in a previous action. The Chief Engineer have a sensor that they can adapt to act as a sonar-like device to acquire the target, but have many technical, operational, and other practical considerations they must consider to make this happen. They know the constraints they have and what they need to do to make it work. The Chief coordinates each person’s actions to bring their experience to bear to plan and achieve the predicted results based on past experience. Complicated.
A land team comes across an unexpected gun emplacement threatening the ship. They don’t know exactly how many enemy personnel are manning / guarding the guns, nor do they know the terrain beyond the cover and concealment from which they will begin their assault. When asked the plan, the team leader responds simply with, “Win.” Each member of the team then executes the plan, responding as they learn more about the number of enemy personnel, the lay of the land, etc. Complex.
Organizations tend to look at all problems as if they are obvious or complicated, that we can simply apply a known rule or process and get the predicted / desired outcome. Which is great for when the problem you face is actually obvious or complicated. Too often, though, organizations prematurely try to reduce a complex problem to the point that they are obvious so that we can standardize and automate as much as possible.
When you try to solve a complex problem as if it were obvious, you are just begging for trouble.
image credit: Dave Snowden, retrieved from Wikipedia on 10 July 2017
Systems thinking and complexity have thus spent a lot of time in my mind, side by side as I try to make sense of them and understand how to apply them to life and work. To be sure, I have often simply treated them as “basically the same thing”, without much effort to distinguish between them.
One of my earliest blog posts was a simple reference to complex adaptive systems. The concept was (is) fascinating to me, on many levels. Not the least of which is my unquenchable curiosity about the connectedness of everything, and an early realization that the world can be seen as a collection of systems. A systems thinker, in other words.
I think I first came across the formal concept of systems thinking in The Fifth Discipline. I was a young Army officer in the Signal Corps, responsible for leading and training young soldiers and for planning and executing communications support missions. Many of my colleagues approached the role from a very rigid, very structured, very “mechanical” perspective. Not unexpected, of course, since military units in general are very highly structured and driven from the top down by command and control – “Here’s what you should do, and I’m going to watch you to make sure you do it so we achieve this very specific outcome.”
As if anything ever works out the way you plan. Understanding my job, the role of my unit, as a component of a larger system that could be manipulated helped me to provide the best support I could to the units that depended on what we provided. (The beginnings, perhaps, of my understanding and application of user-centered design and service design, perhaps?)
I really don’t remember what triggered my interest in complexity. This, I think, is something that has always lingered just below the surface in my mind. If I had to pinpoint a single starting point for the beginning of my slow hunch about complexity it would have to be Douglas Hofstadter’s Godel, Escher, Bach – A Golden Eternal Braid. I came across this book in my latter years of high school and made my way through it as best I could. Though I didn’t really understand much of it at the time, it primed my thinking to be more receptive to a different way of viewing the world.
Then came James Gleick’s Chaos and Michael Crichton’s Jurassic Park. My interest in the science and philosophy of Richard Feynman led me to Murray Gell-Mann and the Santa Fe Institute. Eventually I found my way to the work of Dave Snowden and his insights into the application of systems thinking and complexity science to the world of work, however broadly or narrowly you might define this. (Though I have some of this documented in my notebooks from the time (90’s), I wish I had been blogging back then so I had a better record of my thinking.)
Systems thinking and complexity have thus spent a lot of time in my mind, side by side as I try to make sense of them and understand how to apply them to life and work. To be sure, I have often simply treated them as “basically the same thing”, without much effort to distinguish between them. Though they share some key characteristics they are, of course, different. But what are those differences, and why does it matter? Heading in to the new year seems to be a good time to delve into this.
Fortunately for me in this regard, I recently discovered an article from 2013 by Sonja Blignaut that has pointed me down a good path for this exploration. Titled appropriately enough 5 Differences between complexity & systems thinking, the article is a summary of her notes and thoughts from some time spent with Dave Snowden as he presented workshops and worked with clients.
Over the last 10 days I’ve had the privilege of accompanying Prof Dave Snowden to various workshops and client meetings in Johannesburg & Cape Town….
Often people see Complexity as a subset or slight variation on Systems thinking, but Dave has drawn some clear distinctions that I find very useful. These aren’t the only differences, but they’re the ones that remained top of mind:5 Differences between complexity and systems thinking
Scaling in a complex system is fractal, or self similar in nature. In effect we decompose to an optimal level of granularity then allow coupling and recouping of the granules to create new patterns all of which have a self-similar relationship to each other. One of the things we are doing with our adaptation of fitness landscapes within SenseMaker® is to allow the same source data to represent itself for different identity structures within an organisation in contextually appropriate ways. Nothing in a complex system is context free, everything is context specific.
I’ve been interested in, and trying to understand, the Cynefin framework for many years. Without much success, I might add. However, I recently saw an Intro to Cynefin video from Dave Snowden at Cognitive Edge that has helped me put the final pieces of my understanding in place.
Actually, looking back at my first attempt to use the framework to look at an issue, back in a November 2008 look at the response to the global economic crisis, it looks like I may have understood it better than I thought I did. But then I started taking it places I don’t think it was ever meant to go. Continue reading “Our causes can’t see their effects”
When talking about management, what most people are thinking about is efficiency, maximizing output per unit of input. Many (most?) people talk about the need for leadership in addition to, or even instead of, management.
But what exactly do we get from leadership? What is its purpose?
The first word that comes to mind is “effectiveness”. But most measures of effectiveness are based on a desired end-state, which to me makes this just a different way of measuring efficiency.
Is leadership just another way to get people to do what you want them to do so you can accomplish your own goals? Or is it something different, something more?
<break title=”flight to phoenix”>
When you “manage” something / someone, the best you can hope for is what you ask for. When you “lead” someone, there is no way to know ahead of time what you will end up with.
Maybe the question is better addressed in the context of the Cynefin framework:
Management : Simple :: Leadership : Chaotic
(and possibly disorder), with a sliding mix of the two being appropriate in complicated or complex situations.
Of course, I’m not the first person to consider this question. There are many (many many) more thoughts on this question out there, as you can see in the Google search results for leadership vs. management.
When I first discovered the Cynefin framework, I remember thinking, “Exactly.” It is one of those things that once I saw it I realized how obvious it was, at least in hindsight after someone had pointed it out. Of course, I’ve been trying to actually figure it out ever since.
Dave Snowden blogged recently that he is putting together a history of Cynefin, and provides a brief timeline of its origins and where it is now. He also includes a diagram showing the diagram as it was in 2000 compared to what it is now:
My most recent post that included Cynefin looked at it in the context of concept work and the role of deliberate practice in achieving mastery. The basic premise of that post was that success in the chaotic domain requires mastery, which is the result of a lot (10,000 + hours) of deliberate practice. Even though originally developed with a focus on knowledge management and communities of practice, the origins of the model, as shown above, seem to lend some validity to my understanding.
An added bonus to Dave’s blog post is the comment from Steve Barth (the emphasis is mine):
Something I’ve been thinking about lately relates to the original knowledge-training axis in the early drawings. It comes up working with clients to differentiate and merge knowledge management and organizational learning programs. Increasingly, I believe that knowledge and learning are often polar opposites, and the order/unorder sides of the model make this clear. Simple and complicated emphasize what we already know—or at least believe to be true—and further investigations and analysis must either accept or falsify these premises. We assume that our assumptions are correct. On the other hand, learning is largely about what we don’t know. That is, we must assume that our assumptions could be wrong.
I’m looking forward to the full history.