Kurt Simmons asked this question in ProblemsVersusOpportunites. He shared some (what I think) are valid thoughts. I agree with them on at a cursory level. But in keeping with this blog’s theme, An Alternate Reality, what would it mean if problems and opportunities are actually the same. What would that look like? Sound odd? Hang with me for just a minute.

Once Upon A Time

Problems represent a difference between what we have, and what we’d like to have. Using Kurt’s example, “wrasslin’ alligators” is a problem for a handful of reasons:

1. The alligators may win.
2. If I win, PETA (and possibly law enforcement) will be after me, making the alligators look tame.
3. We play to a draw, leaving the swamp full of water AND alligators.
4. I really wanted to take the opportunity to drain the swamp, thereby creating an alligator free environment.

Oh that’s ugly. Pursuing an opportunity created problems. Who’d have thought? As Andy Grove said, “No problem is so complicated that you cannot make it more complicated.”

So what’s an opportunity? An opportunity represents a difference between the extrapolation of my current state/rate/progress and some idealistically better, hoped for, potentially possible other state. What limits my opportunities?

1. My current state. This includes all of the decisions and actions that got me into the swamp with the alligators. Where I am potentially limits where I can go. Someone wrasslin’ alligators isn’t likely to ponder running the Boston Marathon.
2. There is no such thing as a free lunch. If I decide to pursue the Boston Marathon opportunity, I’m probably not going to be to work on getting the Nobel Prize in Economics (or Alligator Wrasslin’). Now the problem becomes selecting which opportunity to pursue.
3. The illusion of opportunity. While the grass looks greener from the swamp, human history contains an incredible number of fixes that failed. So many in fact, that General Systems Thinking has an archetype cleverly named “Fixes that Fail”. It’s been said that “Today’s problems are yesterday’s solutions.”

So a problem is an opportunity who’s time is now, not in the future.

So What’s Your (view) Point?

Kurt alludes to the second proof that problems and opportunities are the same. He said, “Whenever I got injured playing sports I used to go in a deep funk. I think I grew up when I started looking at sports injuries as great opportunities to catch up on my reading.” This points to the same event being both a problem and an opportunity. In fact, Kurt says that “being up to your keister in alligators … is a great opportunity to practice alligator wrasslin’.”

I believe Jerry (Gerald M.) Weinberg was channeling Virginia Satir when he said “What happens isn’t important. It’s how we respond that’s important.” So it’s our viewpoint and response that determines if something is a problem or opportunity.

The Practical Application

Here’s a quick test. The AYE Conference super early discount period ends April 30, 2007. The price if paid in full is 40% off the at-the-door price. Based on what you’ve just read, would you consider this to be a problem or an opportunity? Need more information about the conference? You can check out the current schedule. Need to ask some questions? Drop me a note.

The hardware & integration project to produce that client was much-delayed, under pressure, and more than a little out of control. I didn’t need a PM. They already had more “help” doing that the normal way than anyone could stand. What I needed was a kind of “un-PM” to coordinate and focus what the execution team was doing, mostly by filtering out the noise from above and across, and maybe injecting somber reality checks into what we said was happening. I needed someone with perspective on the technologies & manufacturing, a grasp of project execution, and a delicate touch with people. I needed someone honest, fearless and gentle about both without losing the need for real data, for he and I to respond to. Taking the culture and history into account, I needed some magic in “just in time” coaching and OD-on-the-sly, to help these people grow into the jobs they were supposed to be doing, without making too big a deal about it. I needed to help these people loosen up while staying focused on the job at hand.

Don has the gift of retaining the child-like quality of enjoying what he does despite decades’ experience with technology development, and a butt-load of training in OD and human systems. He’s serious where need be, but never solemn. With his other skills and gifts, he was perfect.

Don slid-in, and within a week we were tracking to reality of what was done and he’d cleared the underbrush so we could see what remained all without making anyone’s head explode. The product went beta the day I had predicted a couple months earlier, received all certifications and approvals, and worked as advertised. One of the crustier software engineers said: “It’s the best hardware we’ve ever shipped.”

So, what did Don contribute, beyond his background in hardware development, software development, and projects?

• Gentle leadership.
• Sense of fun.
• Just enough Command & Control which was mostly less in detail than there had been, and more in direction
• As a bonus, Don was able sometimes to explain to the more interested members of the staff what I was doing with the organization and how. That conversation is a complicated one to have when you are the boss, as I was.
• And Don engaged in some just in time coaching and almost mini-workshops on tools and techniques of working well together, general systems in particular.

Don and I have since threatened to offer a workshop on general systems applied to development work. I’ve been the slacker on this. But, if we pull it off one day, it should be a riot. I’d like to do that because the one regret I have about working with Don at Padcom is that I didn’t get to spend as much time with him as I’d have liked to.

Jim Bullock – February, 2007, Seattle Washington

My thoughts about the book … If you don’t have the book, get it. If you have the book and haven’t read it, do so now. This books takes information you may already know at some level, and provides a standard framework for the 48 patterns. The authors present the patterns in a “scenario sequence”, but encourage you to add the patterns to your change agent repertoire and use what fits at the opportune time.

You can find additional information here. I took the pattern summaries they provided, and added the problem and essence of the solution. I formatted the file to print on Avery 5388 3×5 card stock. This file is named Pattern Summaries.

“Why doesn’t the developer just give me what I ask for?”

These questions popped out during the Tutorial at this year’s AYE Conference. Realizing the energy, Steve and I held an impromptu discussion on the topic.

What came out of the discussion? Both groups were “mind reading”. Guessing what the other person wanted, and how they wanted it.

When I work with a new client, I follow these three steps to remove mind reading to improve my communication with the client.

1. I ask them what they want. Do they want a summary? “The ship is sinking.” Do they want a summary and action items? “The ship is sinking. If we can isolate the compromised compartments, we may be able to stay afloat.” Do they want details so they can form their own conclusions? “We just hit an iceberg. The forward port compartments 1 – 4 have been compromised and are taking on water.” Even when I summarize, I have detailed information available if asked for it.

2. I ask them how they’d like to receive the information. Sometimes people want to hear the information. Others prefer something written; email, report, spreadsheet, whatever. When you give them information in the requested format, you’re respecting their personality preferences.

3. After the first report, I ask if the information I gave them, and how I presented the information worked for them. This step gives me information on:

- Did I understand their request for information?
- Was I able to meet the request?

Following these steps simplifies my task of sharing information. It also simplifies management’s job of repackaging the information for others to view and use.

It’s understandable. We all know what change is. We’ve been involved with change all our lives. Thus we each have an idea what change means. However, as I mentioned earlier (Different But Useful), the map is not the territory. It’s quite likely that your definition varies from mine. Like the air we breath, we don’t notice it until something goes wrong.

So, what is change? Change is the transition in a system between two steady states.

Transitions requires time. Smaller less complex systems generally require less time to make transitions. As an independent consultant, I can implement changes much faster that Microsoft can. I don’t have empirical data but I’d guess by the time I’m finished with a change, they’d still be discussing it.

Transitions also require energy. Some energy is required to move the system from its stable state. If an external event creates a life and death response in the system, this energy probably isn’t hard to find. If the change “comes down from on high” and involves doing something differently (such as process improvement), the energy may not exist to get the transition started. Once the transition gets underway, more energy than normal gets expended as the system attempts to re-organize and find its new stable state.

Seem reasonable? Got a question or something to say? Let me know.

Stable by Existence

It was a fair assumption. After all, the topic was “Change and Stable Systems.” Unstable systems don’t exist very long. Like fire flies on June nights, they flash briefly, then go black.

First Things First

If the system is unstable, the first change to make is get stable. Being unstable violates the Law of Continued Existence. You have three intervention points to create stability: gain, energy, and degrees of freedom.

Gain

Technically system output divided by input. The higher the gain, the more the input gets amplified. A common example is putting a microphone in front of a speaker connected to the microphone, and turning up the volume. In organizations this tends to be the “rumor mill”. Information, real or imagined enters the rumor mill and gets amplified and re-transmitted. This makes it difficult to tell fact from fiction. To adjust the gain have meetings where you can learn what fictions are circulating. Then share the facts as simply as possible.

Energy

Energy comes in two forms:

• Potential energy – the ability to get work done.
• Kinetic energy – doing the work.

If the system is unstable, try changing the energy balance. Is everyone running around in panic mode? Slow things down and convert some kinetic energy to potential energy. The opposite situation, too little kinetic energy creates sluggish responses (if any), and prevents change from occurring.

Degrees of Freedom

Degrees of Freedom means flexibility of action. Normally we want this. However if we’re dealing with an unstable system, too much freedom creates a “loose cannon on a rolling deck”, and the ship we sink might be our own. Reigning the troops in won’t be popular, but it will reduce the number of ways to go wrong. It will also change the system gain and energy.

The Only Hard and Fast Rule

Unfortunately is, “There are no other hard and fast rules.” I can’t tell you which parameter to work with. But by manipulating gain, energy, and degrees of freedom, you can restore stability to your team, project, or organization.

I arrived just before the rescue truck. The SUV lay on its side in the ditch. The VFD had already set up traffic control and fire suppression. Using standard rescue techniques and tools, “Mom” and the kids shortly walked out of the SUV. Other than needing to by a new vehicle, this story ends happily. But what happened? The Highway Patrol report will include some phrase like “too fast for existing conditions”. “Mom” has probably driven this road most of her life. It’s rained before while “Mom” was driving. But today the amount of rain, the wash over the road and her speed created a new context that “Mom” couldn’t cope with successfully.

Like this accident most “interesting events” happen because someone, somewhere, at sometime, loses track of the context. Context involves us and everything we’re connected to. “Involves us” includes our mental models, our world view, and our actions. We started changing at conception. We continue to change until after we die. Along the way, we grow, we learn, we change. Accidents happen when we change, but the “everything else” hasn’t. Learning may create an accident that leads to personal growth. Personal growth might make us uneasy with our current friends.

“Everything we’re connected to” is the environment we exist in. Our family, our friends, our career, our hobbies, everything with which we come in contact is in a state of flux. If our world view limits how we see things, we’ll create accidents by missing opportunities or reacting to things that aren’t there. If we hold to mental models that no longer apply to our current situation, we’ll be out of context when we act. Behaving like a 10 year old doesn’t work well now that I’m pushing 50.

We need to learn from accidents. Learn about ourselves, our context, how they interact, and how to keep them synchronized.

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

I want to recognize I’ve been using two words interchangeably: systems and organizations. In this context, I view an organization as a specific type of system.

Systems contain three basic components: reinforcing loops, balancing loops, and time delays. Reinforcing loops cause growth or decline. Balancing loops interact with reinforcing loops and create stability. Time delays separate cause and effect by days, months, possibly years. These delays determine how quickly a system responds to a change.

Delays occur in several places for organizations.

Transport delay involves the time required to move information around the organization. Information that development needs to know may enter the organization in customer support. “Oh no! The Frammin module appears to be broken! It’s reformatting the customers’ hard drives and displaying Elbonian profanities on their monitors!” The standard hierarchical organization communications path would be up the chain to the common node, then back down the development change to the managers who decide what should be done, and then to the programmers who actually do the work.

Decision delay results from the time required to decide what to do. I used to believe that inside every complex system, there was a simple system trying to get out. I still largely feel that way, but some software systems are complex, and that’s that. We’ve been writing software for 50 years. Most of the easy programs should be written. That leaves the difficult and complex programs. Quick decisions can spell disaster if the long and short term ramifications aren’t considered. When the development managers learn the Frammin module causes problems, it may take a while to determine the circumstances surrounding the problem event, exactly what part of the Frammin module causes the event, and what to do about it.

Implementation delay is the time required to do the work. The classic line here: “You can’t produce a baby in 1 month with 9 women.” Some work is separable and can be done in parallel by multiple workers. Some isn’t and must be done by a single person. Quick thinkers will try to create separable work. While work can proceed in parallel effort, communications (and gaps) and interfaces become issues. These issues are avoided when a single person does the work. So which answer is better?

Time delay relates to a system parameter called time constant. When the system output reaches 63.2% its next value, one time constant has passed. The following graph shows a system with a time constant of (approximately) 4.5.

By reducing any or all of the delays, we can achieve a result in a shorter time period as demonstrated by:

We’ve moved the time constant to (approximately) 3, or reduced the time it takes to respond by 1/3.

How do we remove delay from the system?

Transport Delay: All organizations have informal networks that pass information to where it should go. These networks are usually called “friends”. Some organizations explicitly encourage this by “cross assignment.” A developer works in customer service. A tester may spend time in development. Besides broadening the skills and creating an understanding of what the other person does, this creates the informal network that keeps information flowing.

Decision Delay: “Empowerment” bothers me. I actually think it’s a great idea, but in many situations the idea gets morphed into an evil double bind event. Nonetheless, we’re talking about empowerment. Move the decision making authority to the person closest to the information (reducing transport delay) and work effort (possibly also reducing implementation delay). The management problem resides in authority to make a decision can be delegated, responsibility for that decision can’t. Maybe this causes the standard empowerment double bind.

Implementation Delay: Better people make better products. I can’t put my hands on the data, but I seem to remember that Jerry Weinberg, Tom DeMarco, and Capers Jones have all released studies showing that individual performance varies by an order of magnitude. So get better people. Read Johanna Rothman’s book: Hiring the Best Knowledge Workers, Techies & Nerds. Improve the skills and abilities of the people where you work. Send them to the AYE Conference. Improved workers will impact Decision Delay by allowing true empowerment.

Can you think of other delay causes? How can we mitigate them?

Agree? Disagree? Add a comment.

Don’s Dismal Dilemma: How will I achieve my goals, when I’m not in charge or control?

Physical systems follow patterns established eons ago. Friends do what suit them. My clients determine when and where I’ll work with them.

As time progressed, I found the one thing in the universe I have complete control over: me. This lead me to

Don’s Delightful Discovery: I can’t control what happens to me, but I can control me, and how I respond to what happens to me.

As Virginia Satir said, “We can direct our efforts to change what we can and to work out creative ways to live with what we can’t change.” [New Peoplemaking, pg 7]

When we quit changing with our environment, we face extinction. We need to update our mental models so they conform current with reality. As we grow and mature, our realities change. Our mental models need to reflect the changes. Mental models formed in childhood and not updated make for interesting adult behavior. Dad warned me about getting “Hardening of the Attitudes”. (Notice the survival rule that affects my change quotient?)

Changing allows me to achieve my goals. If the goal doesn’t change, and external events (by definition beyond my control) change the situation, I need to change my actions (I control these) to bring the results in line with achieving my goal. Or perhaps my actions aren’t producing the results needed to achieve the goal. Again change becomes necessary to realign with my goal. If I don’t change what I’m doing, my actions will take me away from my goal.

“Insanity: doing the same thing over and over again and expecting different results.” Albert Einstein

Occasionally I need to change my goals. As I learn more, what used to be important may not be important now. Changing goals allows me to work on what’s important to me.