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.

The rules (updated)

Learn the rules (and how and why they came about).

Understand the consequences of not following the rules. And of following them.

Always follow the rules (except when you shouldn’t).

When a rule needs to be changed, change it.

The rules

1. You have to break the rules in order to learn the rules.

2. You have to learn the rules before you can break the rules.

3. You should always follow the rules, except when you shouldn’t.

On the importance of rules

After reading some of the various recent posts concerning Mind Maps® and downloading and using the trial version of MindManager, I went back to the source of my first introduction to Mind Maps®, Michael Gelb‘s book How to Think Like Leonardo DaVinci: Seven Steps to Genius Every Day. I was fortunate enough to meet Michael when he was touring for the book when it came out several years ago and hear him speak about the book and his experiences. If you’ve not read this book, I strongly recommend it.

After a brief description of Mind Maps, Michael lays down the rules of Mind Mapping before presenting the exercises. The rules themselves were very familiar to me since I have been playing around with Mind Maps over the last couple of days. What really grabbed me was Michael’s “justification” for using rules, a quote from DaVinci’s Treatise on Painting:

These rules are intended to help you to a free and good judgement: for good judgement proceeds from good understanding, and good understanding comes from reason trained by good rules, and good rules are the children of sound experience, which is the common mother of all the sciences and arts. (emphasis added by me)

Throughout my adult life I’ve had a “glass half full” perspective on rules that somewhat mirrors DaVinci’s sentiments. This comes from the scientist and engineer in me. To paraphrase another great mind, Richard Feynman, it is important to know what has been done before so that you can build from it.

As anyone with children – especially teenagers – knows, though, rules have a very bad reputation. From the kids point of view, rules are evil things meant to repress (oppress?) kids and limit their adventures in life. I see this as a “glass is half empty” perspective on rules.

Unfortunately, it seems to me that many people in organizations I’ve been involved with have this same perspective. Rules in the form of organizational processes, best practices, etc., are all too often ignored – often quite blatantly and proudly. The not invented here syndrome is alive and well. That said, I do not advocate blind following of rules or application of past success (best practices) to any “knowledge” problem.

One aspect of Knowledge Management, process improvement, etc., is the capturing and use of best practices. Much of the writing and practice of best practices, at least that I’m familiar with, and my past experiences with organizations doing work with best practices focuses on the capturing of past practices that worked and the application of those practices, as is, to future situations that are similar. While this works fine for what I call “information” processes – and is, I believe, a critical step in helping any organization improve – I don’t believe that it is appropriate for “knowledge” processes. Or, in terms of DaVinci’s scheme above, the blind use of rules, in the form of best practices, stops short of the goal – good judgement.

This is not to say, however, that past experiences should not be exploited in creating/acquiring new knowledge. Except for the rarest of occasions of thinking “outside the box” (e.g., Newton’s discovery/invention of the calculus and Einstein’s General Theory of Relativity), most new knowledge created today is derivative of something past. It is important to know what has come before and learn from the success and mistakes of others. The rules that come from those past lessons then become the framework for the future, not the fully developed solution to be applied like a generic template to a MS Word or PowerPoint document.