Learning to Change

Don — Tue, 02 May 2006 23:45:59 +0000

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.

Change and Stable Systems

Don — Mon, 17 Apr 2006 18:57:50 +0000

In response to “Change Quotients” Laurent Bossavit laurent_at_bossavit.com wrote:

“Change quotients” prompted one particular thought – since I’m usually the person recommending a change, I tend to be more sensitive to lower quotients than mine. Yet, I do recall one organization which had an intrinsic change quotient which apparently exceeded mine – they reorganized every two weeks, more or less.

Your remark on how change quotient relates to system size suggests that there must be some absolutes – a reorg every two weeks may be too much for a 40-people company trying to stabilize its software processes.

Change disrupts the status quo. Change events can be external (a new competitor, government regulations, market conditions, …) or internal (promotions, people leaving, new product lines, process improvement…). Let’s call the change event, a foreign element. When a system experiences a foreign element, its output fluctuates over time until things return to normal. The following graph shows a system exhibiting this behavior.

After a foreign element the system returns to its previous output. The output varies but gets closer to and eventually achieves the desired value. (Control theory buffs will recognize this as a quarter-wave decay response to a step change in the input. I should note other desirable responses exist to step change inputs including critically damped, absolute integrated error and others.)

Now what happens when the system experiences another foreign element, say at t = 4? We’ll use the same “step change” for the input. The resulting output graph looks like:

Now the system takes longer to return to the desired output level. So far changing during change doesn’t look desirable. For convincing let’s add one more change at t = 5 (same parameters).

These graphs apply to bounded, linear systems. I have yet to meet a bounded, linear person. People respond to foreign elements more like:

I “lifted” this graph from my colleague Steve Smith’s article The Satir Change Model.

Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change?

Tuning People, Processes, and Projects to Power Results » Satir Change Model

Learning to Change

Change and Stable Systems