You should always follow the rules (except when you shouldn’t)

 

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 

Advertisements

Systems thinking and complexity

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.

In the coming days I’ll be looking at those 5 differences in detail.

Coherence through shared abstraction – Cognitive Edge

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.

Source: Coherence through shared abstraction – Cognitive Edge

 

Our causes can’t see their effects

Cynefin frameworkI’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”

Management : Efficiency :: Leadership : ??

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”>

</break>

Some thoughts:

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.

Cynefin and mastery

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.