Learning to Change

In Changing Quicker we looked at reducing or removing system delays to reduce the time delay between realizing a change needs to be made, and when the change’s effects occur. Another way to change quicker involves learning to change. Learning is a process that depends on experience and leads to long term changes in behavior potential. We can use Causal Loop Diagrams (CLDs) to model learning and change experiences. This provides a framework for discussing learning.

The Learning Loop

Learning involves a basic sequence of steps:

1. Deciding to do something.
2. Doing it.
3. Noticing the results (possibly after a delay).
4. Comparing the results to what we wanted to have happen.

We can learn from everything we do. This means the linear representation happens continuously, over, and over, and over again. General systems thinkers use CLDs to draw pictures of repeating events. The CLD for our basic four step learning sequence looks like:

 

You can start “reading” this CLD at any ellipse. Starting at the bottom we do things, take actions, and otherwise interact with our environment. These actions cause things to happen and information comes to us as feedback. The parallel lines on the arrow connecting “Actions in the World” and “Feedback experience” represent a time delay. The shorter the time delay between when we take action and we get the results of that action the more quickly we can learn (this would be Transport Delay in “Changing Quicker”). We compare the feedback and results of our actions with a goal, the “why we did it” resulting in a “Difference”. This “Difference” in turn influences our “Decisions”.

For example let’s look at my goal to provide quality software services to my clients (Goal). My equipment performs reliably, so I decide not to back up the client’s files on another system (Decision). Then one day, my hard drive scrogs itself and I lose the source code I’ve been working on for weeks (Feedback). Now I can’t provide much service (much less quality service) (Difference). This Difference causes me to periodically back up the client’s source files to another computer. The results of my first pass through the loop actually worked well for several years.

So now I’m happily copying sources to another computer (Action). I’ve modified the current source and sent it to the client for testing. Not a problem since the original is on another computer. The client asks for another change which I make on top of the existing change, which is different than the unchanged source on the other computer. The second change doesn’t work I need to back out change #2 and get back to change #1, which no longer exists (Feedback). This again trips the “Difference” between the goal to provide quality service and what’s happened. This influences my decision to install a version control system where changes can be conveniently stored and retrieved as necessary. I’ve already changed how I store client files one time, so changing how I store client files the second time becomes easier. This is single loop learning.

Change can actually happen on different levels. In the basic learning loop, I change my actions to reduce the difference between my goal and the feedback I get. What happens if I “abstract up” one level, and change how I change? This leads to “meta-change” or changing how I change. The CLD for meta-change looks like:

 

This drawing resembles the learning model but has an extra balancing loop (B2). This balancing loop connects the feedback directly to the decisions and enables the question “How did this change work?”. This retrospective position allows me to change how I change. Would a different action create a better (smaller in this example) difference? Did the feedback lead to the results I expected? If not, why not? Does my mental model (see Choosing Change for more on mental models) for this situation need adjustment? Am I using the correct model? Meta-change adds another feedback loop increasing sensitivity to the environment and making the system more stable.

We’ve not answered the question, when should we introduce a “new” change?

In Anticipating Change¹, Jerry Weinberg mentions McLyman’s Zone Theory based on the Satir Change Model. McLyman’s Zone Theory distinguishes four “zones” during change. We receive change opportunities differently depending in which zone we find ourselves.

 

The Gray Zone

When a foreign element arrives in the Gray Zone, people have already lost some of their meta-change skills, for old learnings about change have lost their usefulness. Without these meta-change skills, change is once again slow and difficult, and the chance of successful change declines.

The Red Zone

The Red Zone is the time before the previous foreign element is transformed, accommodated, or rejected. When a new foreign element arrives while the system is in the Red Zone, chaos from both foreign elements increases. Moreover, the chance of ever finding a transformation for either foreign element decreases, and the likelihood of rejection or accommodation increases.

The Yellow Zone

The Yellow Zone is the time interval when a previous transformation is still being integrated. When a new foreign element arrives while the system is in the Yellow Zone, chances of successful change are reduced, but not as seriously as with Red Zone foreign elements. The system may lose its grip on the original transforming idea and be thrown back into Chaos. … With successive Yellow Zone foreign elements, the system builds an energy debt: Successful change becomes less and less likely, and productivity drags.

The Green Zone

The Green Zone is the time between late Integration and early New Status Quo. When a foreign element arrives in the Green Zone, the system’s chances of successful change are maximized.

¹ Quality Software Management Vol 4, Anticipating Change, copyright 1997 by Gerald M. Weinberg, Dorset House, ISBN 0-932633-32-3, pages 42 – 44