Cynefin Framework: Ordered Systems

The right side of the Cynefin diagram represents ordered systems. Most of the time, even when a system is clearly unordered, we try to interpret it and change it as though it were ordered. I will go into more detail about how poorly such an approach to change can work in the next post.

Simple Systems

The lower part of the diagram covers what Snowden calls simple systems. As a very simple example, consider a form that your organizations submits every month or every quarter because the form is required for you to maintain some employee benefit. Basically, filling in the form assures some agency of government that you are doing the same thing you were the last time you submitted the form, and the form, signed and sent, makes you liable if you aren’t doing things right.

You update each time if there is anything that is actually new. A more involved version of this same concept of a simple system would be tweaking a personnel policy because of a change in your organization or the rules regarding such policies. Most of the time, with a little effort, you can figure out what needs to be tweaked, make the changes, and be done with it.

Snowden describes these activities as “Best Practices”. There is a right way to perform these actions and once you figure it out, you can pretty readily keep doing it right. You identify the task (Sense), you connect what you Sense to a task you have more or less done before (Categorize), and you Respond with the appropriate output.

Much of day-to-day work for most people falls into this kind of system.

Complicated Systems

Systems are called complicated because they have lots of parts. Think of an airplane, like a 747, or a computer. When a complicated system is being designed, the relationships between the parts need to be rigidly constrained. We don’t want the wing of a 747 to suddenly decide that it needs to be somewhere other than remaining attached to the plane. Also, while the parts are optimized for being a part of the 747, they are not necessarily optimized for what they could be if they weren’t part of the 747. It is a bad idea to have one part that will last forever and another connected to it that fails with great regularity. In complicated systems, parts and their maintenance are often tailored to each other so that failure of the system as a whole won’t occur.

Much of the design of our organizations and change groups become complicated in this sense over time, as we get bigger and have more complicated constraints (laws, audit requirements, 3rd party contracts, etc.). These design changes are usually done because they can’t be avoided, and we tend to add the changes and make some adjustments in the rest of our organization or group to accommodate them. It is like trying to remodel the 747 while it is flying. Optimization doesn’t enter into our organizational results because we have to keep the doors open while we design and make the changes. After such changes, organizations usually go through a process of running into “pain points” that didn’t exist before the change. We muddle with these to make them work as well as we can, but some aspects of such change will show up in employee stories about the problems in the organization for years. Some will even outlive the employment of every person who participated in the original change.

If a change is particularly difficult (say, rewriting your retirement plan to make it compliant with a new Federal law), you might hire an expert to help plan and implement the change (say to draft a compliant plan which you can then tweak to fit your organization). Even though you end up with a plan, it had to be created part by part in the same way that you would design or build that 747.

This need for real design is the reason why “Analyze” replaces “Categorize”. The notion of problem solving rather than matching an exact solution is the reason why Snowden describes this quadrant as “Good Practice”. Nonetheless, understanding (making sense of) a complicated system can be achieved one piece at a time. Think of the metaphor of a “blueprint” (I’m old enough to remember when blueprints were blue). While you may not be able to get the whole of the 747 inside your head, you can go through the entirety of the plan by using the design documents and the narratives attached to them. Much of what we think of as funding proposals qualifies them as complicated systems. We are constructing them a piece at a time, and organizing them in a way that will show the proposal reviewers what we expect to happen and how we expect to make things happen. A blueprint. In fact, most strategic plans are also blueprints. This may seem obvious to you as you read that last sentence. But as I hope to show you in the next post, blueprints don’t work well with complex systems, and they don’t work period with chaotic ones.