Wednesday, June 10, 2009

The Blame Game

©2007, 2009 Don Gray and Jerry Weinberg

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

  • Respond negatively, looking for reasons, usually blaming someone else) for the results.
  • Decide no difference exists by ignoring the results and do nothing.
  • Respond constructively, learning from what happened and improving at getting the results we desire.

Choices for a poorly ending project.

Choices for a poorly ending project.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a ?success?) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

  • Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
  • If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
  • Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
  • Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.
Results of blaming

Results of blaming

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

  • Observe what’s actually happening. Are people doing what they say they’re doing?
  • Listen to the language people use. Do you hear blaming?
  • Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like ?It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

Friday, May 8, 2009

No Exit

Always have an exit strategy.

©2005 – 2009 Don Gray, Gerald M. Weinberg

“The thought that disaster is impossible often leads to an unthinkable disaster.” – The Titanic Effect, The Secrets of Consulting, pg 95

Engelbert, the Software Engineering VP, sat quietly in his office pondering the current state of UberDenke’s next UDCRM release. Slowly he had realized the release wasn’t going to ship on time. There were many more errors than he planned for, and over half of the code had not even reached the testing group.

The more he thought about it, the more he felt trapped. The more trapped he felt, the more he wanted out. The more he wanted out, the more he felt trapped. And around, and around his feelings traveled in a vicious circle of trapped and wanting out. But there wasn’t anyway out.

Or was there? Engelbert’s thinking and actions have trapped him in a reinforcing feedback loop. His feelings are creating an emotional downward spiral that will continue until some system limit is encountered. The system limit may be the when he finally admits to others the release won’t ship on time. Perhaps his health (mental or physical) may break first. Or maybe he’ll change jobs.

We can all sympathize with Engelbert?s plight, because at some time or another, we’ve all been caught like this–a trap artistically summarized by Jean Paul Sartre’s depressing play about three people trapped in Hell, No Exit.

Engelbert set up his own No Exit hell right from the beginning, because he, like Sartre’s victims, had no exit strategy. An exit strategy is a planned set of activities to initiate when one party suspects that a relationship isn’t working, activities that should prevent the situation from becoming a hellish trap.

Dynamic Basics – Getting Started

The no-exit dynamic generally begins when two (or more) parties agree to work jointly on some project. Sometimes the agreement is not explicit, as often happens when the work of one party depends on another party’s output. This joint work could stem from a voluntary relationship (such as co-authoring articles) or perhaps from a management mandated decision. In Engelbert’s case, his manager told him to use a new process to build the next generation of their software product.

The parties start merrily to work under the agreement, and all goes well for a while. Next, life happens.

Perhaps the person with whom you agreed to write an article falls ill, changes jobs, or takes time away from the joint project to deal with pressing family problems.

Perhaps the other team at work discovers the problem is more difficult to solve than anticipated. Possibly another higher priority project siphons manpower from their team.

Or perhaps the dynamic starts up when the levels of commitment and interest are unbalanced, or when there is a different understanding of the agreement.

Locking In

The first slip or two may not create a problem. We use explanations like these:

  • It’s only happened one time. (Not noticing prior behavior on the part of either party).
  • Things are bound to get better. (Seeing through rose colored glasses)
  • I’ve made a commitment, so I’d better not say anything. (The team player problem)
  • They’ve got a plausible story. (Just one more chance).
  • I’ve already invested so much, a little more investment and I’ll have what I want. (Good money after bad)

Whatever the reason–and there are hundreds of variations–the slips soon become the norm, not the exception. Since the slips happen individually, separated by days or weeks, the cumulative effect isn’t noticed until it’s too late to do anything reasonable about the slips. The more we become accustomed to the slips, the more tolerant we become as new slips occur. It’s not that Engelbert is stupid. It’s just that he lacked foresight, or was too optimistic. If he had known when starting development that the project would slip several times, he could have planned differently.

Failing to take early action sets the precedent for continuing failure to act. Failing to act causes negative feelings to accumulate. The negative feelings are there from the first slip, but they are ignored or suppressed until the accumulated value becomes greater than we can tolerate. When we finally surface the negative feelings, we feel trapped by our previous actions. We’ve become locked in the reinforcing feedback loop of simultaneously wanting out and feeling trapped.

In this dynamic the system continues accumulating more negative feelings until the system experiences a catastrophic collapse. Engelbert may be fired, or quit, or get sick, or ship a system that drives his company out of business.

Setting up the Exit

So, what’s the solution? The first step to exiting the reinforcing feedback loop is to become congruent by balancing the factors of yourself, the other party or parties, and the context in which the dynamic is taking place. Most commonly, in this type of a feedback loop, the other becomes lost. As you try to cope with the situation, you start blaming the other person for the problem, and that only tightens the loop. Responding incongruently like this creates stress and does nothing to improve the situation or help find an exit from the loop.

Becoming congruent allows you to be centered in your actions. Being centered opens a range of responses you can use to change your view, each of which might break the trap. By changing your view of the situation, we can see possible interventions that will change the loop dynamics. Among such interventions are these:

  • Changing how you see your contribution to the problem.
  • Determining why you feel like you’re trapped.
  • Obtaining a better understanding of what you heard during the “agreement” process.
  • Bringing in a third party who adds a compensating loop. Sometimes you do this by just letting the loop escalate until someone else is affected, often by not trying so hard on your side. This is an example of:
  • Doing the opposite of what you’ve been doing. This personally applies Marvin’s Fourth Great Secret, ?If what they?ve been doing hasn?t solved the problem, tell them to do something else.? The Secret of Consulting, pg 41

Exiting the Loop

No self-reinforcing loop can last forever. Sooner or later, one way or the other, the loop will exit. If no action is taken, the reinforcing loop will continue its downward spiral until some other part of the system collapses:

  • Personal health (mental / physical) will deteriorate until the exit happens. (This is breakdown of the self.)
  • The interpersonal relationship will decay and animosity replaces the original camaraderie. (This is breakdown of the relationship with other.)
  • A third party starts to be affected and intervenes. Of course, this is the result some people are hoping for (if we make enough noise, Mommy will stop the fight). But, you can also encourage it. (This is where the context intervenes.)

Another exit option is to become centered, congruent and work on changing the loop dynamics. The key here is to recognize the No Exit dynamic early, and take corrective action quickly. Your plans and strategies must be flexible. While the goal can be constant (exiting the loop), life continually changes, so fixed plans inevitably become obsolete or, even worse, counter-productive.

When the loop finally exits, there are several possible outcomes:

  • An intervention works and the joint effort continues
  • The “healthy” participant becomes “sick” and the effort ends due to lack of effort
  • One person takes over the entire effort

This applies to multiple party systems (two or more). In addition to software development this could include:

  • marriage and other long term interpersonal relationships
  • business ventures
  • article or book writing
  • sports or other activities you are doing “for fun.”

An Ounce of Prevention

Next time, Engelbert should consider prevention interventions. Prevention interventions can be used to prevent the No Exit dynamic from happening in the first place. Or if it starts anyway, they provide an agreement among the parties as to how to handle it–if you like, a meta-agreement, or agreement on the limits of our agreement and what we’ll do when we reach them.

In a crisis, it’s much easier to stop and think if you have provided time in your plan for stopping to think. If you haven’t, one party will say, “Here you tell me that we’re behind schedule, but you’re adding this thinking-bit to the schedule. That doesn’t make sense.” With that easy dismissal, everyone quickly hurries back to their unproductive panic.

Examples of advance preparation of exit strategies include:

  • Periodic check-ins
  • Gate points where either party can exit the activity, if they’re not perfunctory so you can really exit at these points
  • Better understanding and more explicit statement of each party’s expectations, along with a process by which expectations can be modified along with the plans that were based on them.

A well-designed system will set some limits at the beginning, limits that are not vulnerable to a buildup of tolerance.

Third Party Interventions

Most parents have learned some dos and don’ts about what to do when they witness such a no-exit loop. If you find yourself on the outside looking in, you might apply one of these principles:

  • Know when to enter (never do unless you’re asked for help, though you can encourage the parties to ask you).
  • Prevent damage (whatever that is) to others.
  • Decide it’s not your problem and walk away, letting the nature of the no-exit loop take its course.
  • Avoid creating addiction (co-dependent) dynamics.
  • Avoid using fixes that accentuate the dynamics, unless you want to make it worse so it will crash more quickly or lead to enough pain that the parties will work out their own solution.
  • Be careful not to prevent natural learning.
  • Look for interventions that remove barriers and/or increase resource states.

Exit Levels

In deciding about intervening, choose which of three Exit Levels you’re seeking:

  • First exit is when participants realize how much pain the feedback loop is causing and figure out a way to break out for themselves.
  • The second exit is out of the situation (as when the parties concur that the agreement has failed). This may lead to a new agreement, or an exit agreement where they continue the relationship with each other.
  • The third exit is where one party opts out of the system by ending the relationship.

Of course, the best exit is the one you have planned for before you ever get started. Unfortunately, there’s a prevalent romantic notion that real relationships shouldn’t need a pre-nuptial agreement. As Engelbert’s boss argues when he tries to set up some exit strategies before his next project, “Thinking of possible failure is negative thinking. It’s just that kind of thinking that guarantees we’re going to fail. Just like you did that last time.”

Of course, the last time, they had no such exit strategy, so their failure was much more costly and painful than it need have been. That’s The Titanic Effect: The thought that disaster is impossible often leads to an unthinkable disaster–”Why would we need lifeboats on an unsinkable ship?”

Sunday, March 5, 2006

Bi-Quinary Search

© Gerald M. Weinberg, 2004

“1,073,741,823 lines of correct code, but one unknown bug is going to send us into that Sun.”

“Do not panic.” Peri said, using Calming Voice. “We have adequate time to find it.”

“Peri is correct,” echoed Setho. “Remain logical. We must divide the code in half and allow the simulator to find which half contains the defect. Once we repeat this process 30 times, we are guaranteed to find the culprit.”

“I know I couldn’t have designed this ship,” I said, “and you’re absolutely right about the process. But you have no concept of time. Each test will cost us 10 minutes, and in 4 hours we’ll pass the point of no return. Yes, an hour after that, we’ll be able to unlock the controls, but it will be too late. Perhaps you Zaard will be satisfied to choose your personal sunspot for cremation, but it doesn’t do much for me.”

“We will remember our ancestors,” said Peri, twisting into the Zaard meditation posture.

“Yes,” Setho agreed, in posture as in words. “Termination of existence is the only logical conclusion, so remembrance of ancestors is the only logical action.”

“Don’t go to sleep on me. There is a way, if we’re lucky.”

“Luck is a human concept,” Peri said, his voice slowing and sinking. “Do you really think you can find one out of a billion lines of code by luck?”

“Peri,” said Setho’s Chastizing Voice. “Please be respectful. We must not interfere with his religious beliefs, no matter how preposterous they are to us. Proceed with your foolishness, John, if you wish. We shall watch, and pray for your soul.”

“I could use more help than that. I figure that if I can guess a division of the code that puts the bug in the smaller half, I can accelerate the process.”

“Your assumptions are incorrect. Though you name it ‘code,’ we know it is Leethaa, not some simple computer instruction.”

“Doesn’t matter what you call it. If we find the Leethaa, or code, that’s wrong, we can change it through the console.”

“True. We can change it, but if we merely know it is wrong Leethaa, that still does not mean we know what is right Leethaa.”

“Of course you’ll know. You built it.” Peri and Setho exchanged another look, and the odor in the compartment changed. “I’m just a passenger, remember, like any human, taking advantage of your intergalactic freight service. You’re the designers.”

Setho turned several of his eye to me, but spoke to Peri. “Since we are all to end our existence, in a few hours, can there be harm in telling him?”

No, the memories of our ancestors will not be harmed.”

“Tell him what? And don’t talk about me like I’m not here.”

“We Zaard are not the designers of these ships. We, too, are passengers, enjoying these gifts from our ancestors, countless time in the past. We do not know how the Leethaa operate, but only how to repair them when they fail.”

I was quickly rearranging all I thought I knew about the Zaard. Too bad I wasn’t going to be able to tell anyone. “Then how can you repair it?”

Setho was about to reply, but Peri raised an appendage and used the Interrupting Voice. “We use the binary search, using the simulation logic, as I explained. When we locate the offending Leethaa, we alter its state – le to eth; eth to aa; aa to esu; esu to culara; culara to le. Those are the five possible states, as I believe you well know from observing us through these months we have flown together.”

I didn’t know they had been watching me watching them, but what did it matter now. “Fine,” I said. “So once I locate the right Leetha through my guessing, you can make it right.”

“True, but guessing depends on luck, and we do not believe in luck. You will not find it.”

“Moreover,” said Setho, “even if we were to assume your false premise about the existence of luck, then we would logically have to accept the existence of bad luck as well.”

“And with bad luck, your guessing process would actually take longer.”

“Hey, we’re going to fry anyway, so what more do we lose if it takes longer? Besides, I need your help.”

“We cannot help with luck. We can only remember our ancestors.”

I swept my gaze over the full circle of consoles. “Then call it ‘intuition,’ if you don’t like luck. You two know a lot more about this vehicle than I do, and your guesses may actually be better than mine.”

“But we already told you, we don’t believe in guessing.”

“Well, one thing for sure you do believe in is arguing, and arguing for sure isn’t going to save our skins. While we’ve been having this lovely philosophical discussion, I’ve been running my first guess. It should be done in 30 seconds.”

“We noticed,” said Setho, who seemed the more alert of the two. “… And there it is. You see, it seems that the flaw is in the larger of your two parts – not the smaller one chosen by your guess – and now the process will take even longer.”

“Okay, so it was bad luck. But if my luck turns better, we can make up the lost time.”

The two Zaard merely exchanged more glances that I couldn’t interpret, so I made my second guess. “I think the transporter code is the most likely place, so I’ll make that one of the halves.” I entered the cutting point and restarted to testing process. “If it’s in there, we’ll be down to less than a million lines of code.”

But it wasn’t there, and by the time we found out, I had already lost 20 precious minutes without reducing the problem significantly. Setho and Peri didn’t seem to mind, lost as they were “remembering their ancestors.”

I started feeling warm, even though I knew that the sun’s heat would not be affecting our interior temperature for another couple of hours. Setho must have noticed.

“Do not be distressed, John. Having remembered our ancestors, we are now at peace. Do you not have ancestors to remember?”

“Most of my ancestors aren’t worth remembering.”

“How sad. No wonder you solve problems by guessing. But surely your ancestors must leave you some worthy memories.”

I paused to enter my third guess. It was even more risky, but I had to make up time. I felt it was more of a gesture than anything useful. Three hours and thirty minutes – 21 guesses – was all that was left.

“None of them ever knew the Zaard even existed, so none of them ever toured effortlessly around the galaxy. What memories could they leave that would do us any good?”

“True. Your history is so strange to us that I never thought that you might not have useful memories. How unfortunate that we know each other better only now.”

“But your ancestors’ memories don’t seem any more useful than no memories at all, if they can’t help fix a failure.”

“Oh, but they can. We have memories of all ship failures in the past, and how to repair them.”

“Then why aren’t you fixing this one?”

Setho gave me a look that even on his/her strange face seemed to say, “Don’t be a stupid Human.” What s/he actually said was, “Because our ancestors never encountered a bi-quinary star system such as this one, so there is no memory of this particular failure.”

“But there were failures before?”

“Of course, but not this failure.”

“And how often do you have these failures?”

“Among the entire fleet, perhaps once every thousand of your years. Would you like to know exactly?”

“You mean you have a record of them?”

Peri now joined the conversation. “Of course. We told you that we remember our ancestors.”

“All of them?”

“Yes, of course. What would be the logic of forgetting errors. We have a saying, ‘A Zaard who forgets his/her ancestors forgets how to stay alive.”

My mind was racing, but my mouth was having a hard time keeping up because I was trying to keep my chest from swelling with hope. “Okay, how many have there been, since the beginning? Or is that too hard?”

“Why should it be difficult? Approximating the time, in the past 180,000 years, there have been 674 distinct ship errors.”

I did the arithmetic in my head. “That’s a mean time between failures of about 250 years.”

“267,” Peri corrected.

“Not bad, but not perfect, either. Maybe your ancestors weren’t as perfect as you thought.”

“We do not think our ancestors are perfect. If they were perfect, we would not have to remember them. But, to their credit, these failures are in a fleet of more than a million ships, so the mean time between failures on any one ship is greater than 267 million years. They are not perfect, but they are very, very consistent.”

I was impressed, but I wasn’t going to show it. “Sure, that’s great. But we’re on one ship, and it’s failing right now.”

“Fortunately,” said Setho, “the signals have already been broadcast, so we will be remembered. You will have the honor of becoming the first Human Zaard ancestor.”

“Oh, thanks, I hadn’t thought about that. But I’d rather live and be forgotten, so what else can you tell me about these errors?”

“What else would you like to know?”

“I’d like to know the distribution of errors across the various Leethaa components – like, which component has had the most errors per element?”

Peri paused for a moment, then announced, “That would be the Nisoog-arthl component, with 402 of the 674 errors, if I have remembered our ancestors honorably.”

“You have,” said Setho, “Most honorably.”

Now my heart was beating audibly, and fast. “And how large is the Nisoog-arthl?” I’m not superstitious, but I crossed all my fingers as I waited for their reply.

They replied in unision, in the Data Voice, “The Nisoog-arthl comprises Eight-hundred seventy-seven thousand nine-hundred and twelve Leethaa.”
As they spoke, my pad displayed the number: 877,912. I could do the necessary calculation in my head. “That’s it, then. One more guess and we’re done!”

I stopped the current simulation, now useless, and entered the boundaries of the Nisoog-arthl as my fourth guess. Now all I had to generate the patience to wait ten minutes to know whether I would live or die. Since Peri and Setho showed utter disbelief, I explained.

“You told me that your ancestors were very, very consistent, but not perfect. When they built these ships they didn’t make many mistakes, but they did make some. And if they were as consistent as you say, then their mistakes would be consistent, too. They would consistently make most of their mistakes in the same parts of the Leethaa. And the one part they most consistently made mistakes in was the Nisoog-arthl – so I’m guessing that’s where this mistake will be found. We’ll know in seven more minutes.”

“Yes, that’s quite logical, in a strange sort of logic, but what good will it do?”

“Yes,” said Peri, also using the Query Voice. “That was a logical guess, but that only narrows the problem down to the Nisoog-arthl. We have no more refined data, so what logic can you use for your next guess?”

“But if the error is indeed in the Nisoog-arthl, I won’t need any more guesses. I can switch to a pure binary search and be sure of narrowing the search to a single Leethaa in the remaining divisions.”

“Aaah,” they said in the Simultaneous Voice, “so in the end you can be logical.”

“And in two more minutes,” Setha continued alone, “we will all know logically whether or not we will visit that sun.”

The Identified Patient Pattern

©2006 Don Gray and Jerry Weinberg

Engelbert frowned, trying to understand why Pamela had been acting strangely. Her programming skills were among the best in the company. She had a way of getting things completed. That’s why he made her project lead for Uberdenke’s next UDCRM product release.

With only two weeks left until the ship date, Pamela’s personality had shifted. Normally calm and composed, she had been seen crying after meetings. Occasionally he could hear her screaming at the programmers working for her. Something had to be done. He was going to have to figure out what was wrong with Pamela. And fix it.

Engelbert’s decision casts Pamela as an “Identified Patient.” The Identified Patient becomes the focal point for the Engelbert’s intervention work to “solve the problem”. When Pamela is “cured”, Engelbert thinks, he can return to his normal schedule. Until then, he has more important work to do.

What happens when Engelbert becomes involved with the Identified Patient Pattern? And is Pamela’s behavior change really the problem? Could there be a fundamental problem that Engelbert is overlooking? What effect does Pamela’s behavior have on the project?

Identified Patient Dynamics

Trying to answer these questions requires considering several
points. As Pamela’s behavior becomes more pronounced:

  • People become distracted.
  • Extra work gets created (trying to “cure” Pamela) and time gets spent doing non-productive tasks (appeasing Pamela, hiding, gossiping).
  • The less useful work gets done.

This seems straight forward enough. But how do these relate to each other? Using a diagram of effects we can visually represent the process as

Identified Patient Activity

Figure 1 – Identified Patient Activity

This diagram shows the downstream effects these actions cause. Eventually these actions adversely impact Remaining Work, which increases Deadline Pressure, which increases Identified Patient Activity Level. And the dynamic starts over again with amplification due to the prior looping. The loops are all negative feedback loops. This means once Pamela (or anyone) becomes the Identified Patient, the system starts down hill, and continues until it hits a natural limit and stabilizes or collapses.

Without knowing it, Engelbert and the UDCRM team become embroiled in activities that add more pressure to system, thereby creating more Identified Patient Activity Level on Pamela’s part. By trying to “cure” Pamela, Engelbert engages in treating the symptom, not fixing the problem. In this case, Deadline Pressure continues to build, creating more stress and exacerbating the Identified Patient Activity Level.

All Stressed Up and No Where to Go

What does Pamela’s worldview look like? She’s the project lead for the next release of UDCRM. The project started with a bad release date (see “The Liar’s Contest”). Engelbert knows this (”No Exit). The project team can look at the remaining work and see they won’t make the ship date.

Uberdenke has to two intertwined systems: the formal hierarchical system with nice boxes and lines, and the informal “shadow” system formed by acquaintances, friends, antagonists, history, and working relationships. The intertwined systems can be congruent or incongruent. When the systems are incongruent, the informal system struggles to compensate–not always effectively–as long as possible. When the informal system can no longer compensate, it doesn’t degrade slowly, it collapses.

In this case the formal system won’t acknowledge the inevitable until it’s too late. The project team (informal system) knows they can’t meet the date, but for a variety of reasons don’t feel able to update the formal system with their reality. The incongruence between the formal and informal system takes a mental and physical toll on the employees by creating stress. To protect the others from blame, one of the people may actively (but perhaps not consciously) adopt the role of Identified Patient by “acting out” in bizarre ways. This behavior serves to distract management’s attention from the other people, but at the same time distracts them from the true, underlying problems. In the short run, then, Pamela is rewarded for her bizarre behavior, and reinforced to continue “protecting others.”

As project lead Pamela embodies the stress and manifests it via her behavior. As her stress level goes up, her behavior becomes more erratic. As her behavior becomes more erratic, the less remaining work gets finished (see above figure), which increases the project tension and so on.

When Engelbert starts trying to “cure” Pamela, two problems occur. First, the Identified Patient dynamic starts, engaging the negative feedback loops. Second, Engelbert’s attention becomes focused on Pamela, and misses the opportunity to look for a fundamental problem. Trying to “cure” Pamela may momentarily reduce pain, but–because the real problems are not being addressed–this ultimately leads to system collapse and much more pain.

Combining Pamela’s stress and Engelbert’s actions results in the following diagram.


Figure 2 -Triangulation

Once again we see two negative self-reinforcing loops:

  • Pamela’s Tension/Stress/Patient Loop
  • Engelbert’s Tension/Stress/Patient/Responsiveness Loop

Both loops keep on keeping on, resulting in more of what we already have. This results from the Identified Patient’s second order nature. Second order nature doesn’t mean the tension and stress aren’t real. It means some other problem causes this problem. Trying to cure an Identified Patient is like scratching athlete’s foot. You’re doing something that feels good, but when you quit scratching you still have athlete’s foot, and wounds from the scratching, which has also spread the fungus more widely.

To improve the situation, Engelbert needs to move from the negative reinforcing loop to the Tension/Stress/Awareness/Responsiveness balancing loop.

What You See isn’t What You Get

To “cure” Pamela, Engelbert needs to determine what’s making Pamela act out. Difficulties with this include:

  • Something in the formal system doesn’t want to know what the informal system knows.
  • Pamela’s behavior masks the real problem.
  • Engelbert may not have the interpersonal skills needed for this.

Management acknowledging the delivery slip would relieve the deadline pressure and stress wouldn’t build. Unfortunately managers promote what they want to hear with such comments as:

  • I don’t want to hear problems, I want hear solutions.
  • Our competitor can do this, why can’t we?
  • You’ll just have to work smarter.
  • If you can’t do this, I’ll find someone who can.

Comments like these ensure that managers only hear good news, until there’s no possible way to hide the bad news. Then they ask, “Why didn’t they tell me sooner?”

Pamela’s behavior indicates a problem exists, but doesn’t give a clue what it might be. Pamela could be acting out because of:

  • Work stress (our example).
  • Triangulation (compensating and covering for a fellow employee).
  • Problems at home.
  • Substance abuse.
  • Sexual harassment at work.
  • Some other unresolved problem.

Most software development managers made it there by having great technical skills, not great people skills. If Engelbert discovers the problem isn’t work related, he’ll need help. Dealing with personal problems in a work environment can be a legal minefield, and is best left to people trained to do it.

In the extreme case, Engelbert may choose to blame Pamela for the project’s problems. While incongruent and counterproductive in the long term, this tack appears to have short-term benefits. Pamela becomes the scapegoat, and hopefully the problems will leave when she does. In the mean time, a new delivery date will be set (while in panic mode). This temporarily relieves the Deadline Pressure. This dynamic may execute several times, until eventually some new delivery date finally provides the time necessary to complete the project. Or, the project collapses under all this extra effort and emotion.

Dealing with an Identified Patient

Identified Patients exist everywhere. The tip-off comes when you hear or think, “Things would be better if this person would just leave.” In reality, that person leaving won’t change the underlying system, and someone else will take on the role. The key to success starts with understanding the Identified Patient functions like a canary in a mine. They provide an early indication something is wrong and needs to be dealt with, but replacing the dead canary will not clean the toxins out of the air. Unfortunately, unlike the canary whose death tells the miners that the air is probably poisonous, the Identified Patient doesn’t indicate what problem exists. One thing for Engelbert to consider: the closer he gets to finding the real problem, the more Pamela may act out. One of Engelbert’s options involves getting the UDCRM team to focus on the remaining work, thereby reducing the attention given to the Identified Patient Activity Level. This becomes an exercise in active support and barrier removal, not platitudes and posters about success through working harder. If the Identified Patient Activity Level gets even larger, this indicates that something else is going on.

If Engelbert can remove Pamela from the system, it might allow the problem to show. Of course removing Pamela might cause other problems which would again mask the original problem provoking Pamela’s behavior. Another person becoming the Identified Patient would indicate underlying system problems. If the Identified Patient Activity Level prevents any useful work from being accomplished, this may be the first action to take. Hopefully, Engelbert will be able to find and fix the problem that created the IP. Engelbert needs to be aware some fixes actually exacerbate the symptomatic problem. Common fixes that fit this dynamic include:

  • Adding tools leads to the “worse before better” dynamic as productivity drops while people get used to the new tools.
  • Splitting tasks leads to the communications/interface dynamic where information needs to flow through more paths and permutes while doing so.
  • Splitting people between tasks leads to context swapping overhead, that period of time it takes to remember where you were and get back into the flow.
  • Adding new people to the project basically incorporates all the above dynamics.

Stress Reduction

Engelbert has several options available to relieve the Deadline Pressure causing Pamela’s behavior. He can use any one of three project leverage points to change the amount of Deadline Pressure:

  • Features – If the number of features decreases, the Remaining Work decreases, which decreases Deadline Pressure.
  • Quality Goal – If the acceptable quality is reduced, the Remaining Work reduces, which reduces Deadline Pressure.
  • Desired Ship Date – As the Desired Ship Date gets bigger (more days to ship), Deadline Pressure goes down.

This looks like:

Intervention Points

Figure 3 – Intervention Points

At this level we now have balancing feedback loops that help stabilize the system. Selecting the best leverage point or combination involves determining how the Uberdenke clients can best be served.

What to do if you’re the IP

Identified Patient behavior has several possible causes. These include:

  • Boredom – which results in irrelevant behavior
  • Triangulation – based on placating behavior. Could be caused by
    • Incongruent formal/informal systems
    • Compensating for other people in the system.
  • Really bad managers using blame to cope with bad results from poor decisions.

Identified Patient behavior is a symptom, not a cause. If management does recognize the behavior, they’ll most likely try to fix you, not the cause. Unless you want to be “fixed”, it’s important to recognize the source of your incongruent behavior. This enables you to work on becoming more congruent and changing the source of the Identified Patient behavior.

“If what you’re doing isn’t working, try something else.” Marvin’s First Law1

If you’re bored, change yourself. Try and find a more challenging position in the company. Take up a hobby that will provide the challenge you’re looking for. If necessary, consider changing companies. Get interested in solving some real problem that’s hindering others.

Triangulating due to incongruent systems doesn’t accomplish anything. The systems eventually align when the informal system collapses and the formal system has no choice. This usually happens too late to do meaningful risk management and damage control. Much pain accompanies the collapse. Trying to alert the formal system to impending doom may get you labeled as “Nay-sayer”, “Not a team player” and such. If this happens, consider changing companies.

While a nice concept for those taught to “play nice with the other kids”, triangulating by covering for other people boomerangs at two levels. You’re not going to be able to do the work for two people, the amount of remaining work will go up, leading to deadline stress, and the incongruent systems dynamic comes into play. Along the way, you’ll become exhausted and your health, both mentally and physically will deteriorate. This reduces your ability to produce and the cycle starts over again. It’s OK to occasionally help other people. But if helping other people gets in the way of getting your job done, learn to say no, or find another company to work for. Whatever you do, do it directly. There’s enough confusion without adding triangles to the mix.

Lastly, if you can’t change the system, and changing companies isn’t an option (and sometimes it isn’t), recognizing the dynamics that create the Identified Patient behavior can help you cope as congruently as possible.

And in conclusion

Identified Patients indicate something is wrong. Trying to “cure” Identified Patients seems important, but lowers the amount of useful work accomplished. Locating and correcting the fundamental problem is the best way to “cure” the Identified Patient. Engelbert needs to remember that correcting the fundamental problem may temporarily cause other problems.

1 Weinberg, G.M., The Secrets of Consulting. 1986, New York: Dorset House Publishing

Multiuse Model

©2007 Donald E. Gray

Models are like kitchen utensils. You need a variety of them, and you should know when and how to use them. They should be useful for more than a single task. I recently started exploring the first explicit model I learned years ago.

The Cybernetic Model

One of my more interesting college classes was feedback control. The class was based on differential equations, Laplace transforms, and a single model that looked like this:

The Cybnertic Feedback Loop

This model is the basis for most of the process control in the world. The controller compares the setpoint to the actual value.The controller uses the error information to take corrective action. If the temperature is too hot, the corrective action might be to reduce the heat in the temperature jacket. After a while, things cool down. All processes have a time lag between the corrective action and when the change arrives at the output. I “borrowed” the “delay symbol” from Causal Loop Diagramming to show this. If it gets too cool, the controller will change the action and add more heat.

I didn’t realize at the time how powerful and versatile this diagram is.

Personal Problem Solving

With just a few word changes, the model can be used to describe how people can solve their problems.

Personal Feedback Loop

A problem exists when a difference exists between what we want, and what we have. We can solve the problem by changing our actions, and seeing if the world at large responds with results that are closer to what we desire.

I’m trying to lose a few pounds. I can change what I eat (calories, fat, carbs, pick your favorite fad diet). I can change how often I exercise. If I continue with these changes, eventually I should lose the weight.

Project Management

Change a couple of more words, and now we have a project management tool.

Management Feedback Loop

In this drawing, I’ve used a dash line connection between the manager (in this case synonymous with leader) and the team. I made this distinction since managers don’t have a direct linkage to the team. Managers can ask, cajole, threaten, and perhaps fire team members who don’t perform the tasks they’ve been asked to do. But the team member always has a choice.

Loops All the Way Down

It is possible to nest the cybernetic model. Consider the Scrum sprint cycle. The sprint cycle overview looks like:

Cascade Feedback Loop

The outside loop is the sprint cycle (usually 30 days or less). Every sprint the product owner sees new product functionality. They compare the current product state with the target and prioritize the remaining user stories. The product owner and team select a subset of the remaining stories which becomes the current sprint backlog.Completing the sprint backlog is the goal (setpoint) for the inside loop. Every day during the sprint, the Scrum team tracks how it’s progressing toward the sprint goal during the daily standup meeting.

A Rose is a Rose

In QualitySoftware Management Volume 1, Systems Thinking Jerry (Gerald M.) Weinberg presents the model in a slightly different picture (page 62).

Pattern 3 Controller

Jerry says, “The feedback model of a software development system requires feedback of information about the system’s performance, plus requirements for the controller to compare with that information. This is the model that distinguishes Pattern 3 from Patterns 0, 1, and 2. It is also used by Patterns 4 and 5.”

This presentation highlights two systems aspects:

  1. Randomness. All systems interact with their environment. Changes in the environment create changes in the system whether the changes are planned or not.
  2. The software development system creates “other outputs” that the controller can use to improve the overall system performance.

A Good Place to Start

Like kitchen utensils, you need many different models. I keep a list of models I use here. The list includes:

  • the Cybernetic Model
  • Diagrams of Effect
  • Behavior Over Time Graphs
  • systems archetypes
  • the Satir Interaction Model
  • the Satir Transformation Models
  • MBTI (and temperaments)
  • abstracting (Korzybski)
  • abstraction (Hayakawa)
  • the NLP Meta-Model
  • meta-programs
  • intake modalities
  • the Rule of Three

I didn’t consciously start the list with the Cybernetic Model, but that’s where it belongs. Any time I start with a difference between what I want and have, I’ve already started using the Cybernetic Model. I may choose to use other models to help resolve the difference between my desires and perceptions.For instance, if I’m involved in a conversation that doesn’t make sense, I may use the Satir Interaction model to find out why the conversation doesn’t make sense. If a co-worker’s actions don’t make sense, maybe I’ll use MBTI types to shed light on the problem.

But it all starts with the multi-use, handy-dandy, Cybernetic Model.

The Liar’s Contest

In this game,
the only way to win is to stop playing.

(c)2004, 2005 Don Gray and
Gerald M. Weinberg

It may look like a crisis, but it’s only the end of an illusion.

- Rhonda’s First Revelation

The Setup

Sharkey, the sales VP of UberDenke Software Products, firmly believes he needs to have the next release of the UDCRM product in three months. Engelbert, the software engineering VP, estimates a minimum of twice that long – six months – to implement all the new features. During the discussion, Sharkey drops some thinly veiled threats:

  • Do you think we need to consider outsourcing this development?
  • I wonder why our competitor manages to get software out, but we can’t?
  • Perhaps we need to see the company president about the schedule.

Getting the message, Engelbert eventually agrees to “try to get the software done” in three months. Engelbert calls a meeting of the development group leaders and shares the story. “Marketing insists
that we ship the next version of UDCRM in three months. Sharkey already has a quote from an outside vendor, so I had to agree to the schedule. Let me know how we’re going to get this done.”

The developers head to their cubes and start to ponder how they will get the work done in three months. No matter how much they try to shorten their schedule, their estimates range from three and a half to eight months to deliver the next version of UDCRM. Engelbert figures that Pamela’s estimate of three and a half months is close enough to three months, so he shaves off two weeks and declares that as the team’s schedule. He rewards Pamela by making her project lead.

Objectives for Play

In the abbreviated story above, there may or may not be a valid reason Sharkey wants the three-month date. There may be legal considerations (HIPA, EPA, IRS) involved. Perhaps COMDEX is in three months and UberDenke needs to be ready to demonstrate the product. Or maybe a key client has agreed to pay to have UDCRM shipped in three months. Sometimes the “Big Boss” has determined that a date (usually 1 January) is a good day to start using a new system. And just maybe, Sharkey fabricated the date out of pure imagination.

Likewise, Engelbert may or may not have had valid reasons for his initial estimate of six months. Based on the new features and changes to infrastructure, six months could be a valid number – even optimistic. Perhaps previous experiences with marketing have always ended with Engelbert’s estimates cut in half, so this time he doubled his best guess for how long the next release would require.

When Sharkey makes up the needed date, and Engelbert starts by doubling his estimate, they become enmeshed in a Liar’s Contest. A Liar’s Contest is a dynamic interaction arising from a conflict between two people who hold different values for an outcome. The winner is the contestant who emerges from the game with his lie unchanged. The loser is the participant who believes the other contestant’s lie and changes his lie to match. Neither of them is ever forced to tell the truth.


A Liar’s Contest can happen between the same or different corporate levels as well as between organizations. Sharkey and Engelbert play the game as peers from different parts of the organization. Engelbert and the developers play Liar’s Contest as boss and subordinates. During the competition, one participant generally starts with some type of an advantage over the other.

The participants’ negotiations tend to be zero-sum situations. Winning for one becomes losing for the other. Generally, the interactions between the participants focus on a single value (three months, six months), not a range of values. They never discuss probabilities, even though the future is always uncertain. You can often stop the Liar’s Contest dynamic by creating win-win situations, agreeing on a range of values, or allowing probabilities into the discussion.

And even though Sharkey and Engelbert finally “agree” on a value for the outcome, the real outcome value will almost certainly be something else:

- A miracle happens. No risks occur and the salaried programmers work long unpaid overtime hours, and the product ships on time. This outcome reinforces Sharkey’s original request of three months. “Those programmers! Always padding their time estimates! I KNEW IT!”

- A miracle fails to happen and the product ships “on time” with serious or fatal defects. Sharkey points out that Engelbert agreed to the schedule, so the current mess is his fault. For extra affect, Sharkey can mention that “The only reason we’re not losing more customers is because of the frantic work of the sales staff.”

- A miracle fails to happen and the project ship date slips to six months – or, often, much longer because trying to do a six-month project in three months usually takes much longer than a well-planned six-month project. The product finally ships with minor defects. Sharkey points to lost customers
and lost revenue and blames Engelbert for the dip in quarterly revenues.

It’s interesting to note that in all cases, Engelbert and the software developers are “wrong.” That makes them the losers, but it doesn’t guarantee that Sharkey won’t lose, too. If he’s still responsible for sales, he may suffer the consequences of the failure to produce a miracle.

Choose Your Position

In a Liar’s Contest, one participant usually comes into the competition with one of five distinct advantages:

Positional Given most corporate structures and climates, it’s difficult to argue with a liar from above you who delivers the “Make it so!” ultimatum. That’s why Liar’s Contests often trickle down through several levels of an organization, producing incredibly far-fetched values of estimates.

Negotiation Experience Some people have more experience negotiating, which gives them an advantage when they press for their chosen outcome. They tie into the culture better (”Be a team player”) and have alternate options (real or fictitious) prepared as threats prior to starting the Liar’s Contest. (”We’ll have to go outside if you can’t do it.”)

Interpersonal Skills The ability to understand people provides additional leverage points. We all want to be successful and to feel competent, yet while the feelings are mutual, the participant who first brings them up tends to put the other person on the defensive.

Psychological Strength Anyone who comes to the Liar’s Contest off-center, entwined in other stressful events, or with generally low self-esteem will be at a great disadvantage to a more congruent opponent.

Nothing to Lose The less you have to lose by lying, the more easily you’ll win most Liar’s Contests. Your potential loss involves both the size of the loss if the lie is discovered and the chance that your lie will be discovered.

When a time delay exists between the negotiation and the outcome, it’s possible that neither party (like Sharkey and Engelbert) will be in the same position, or even with the same company when the outcome is
delivered. If the time delay is long enough, or the record keeping is bad enough, nobody will remember the original lie. Perhaps the reason projects keep such poor records of past estimates is that the people love to have Liar’s Contests and not pay the price of losing.


After Engelbert and Sharkey have played a round or two of Liar’s Contest together, several different effects may be seen in the long term. Sharkey may no longer accept any of Engelbert’s first estimates – he always pressures for a decrease. Engelbert may compensate by padding his original estimate. Since the “pad” can be negotiated away, the reduction dynamic is reinforced. Engelbert may offer more honest first estimates. This does not change the underlying system, so the personal interactions won’t change. The system goes through another evolution and repeats the previously described activities.
This dynamic looks like Figure 1

Figure 1 - Liar's Contest Basic Dynamic

Figure 1

If the Liar’s Contest continues to result in reduced delivery times but worse quality, secondary negative consequences appear. The developers will have a reduced view of Engelbert’s overall management abilities. The long hours developers work attempting to deliver the software will result in mental fatigue and burn out, a further drop in output quality (now on a downward spiral to disaster), and interpersonal stress (family life suffers, feeding back to even poorer quality work). If the economy and locale permit, developers will start leaving for greener pastures in more honest environments. Finally, customers may purchase the competitor’s software due to release quality and cycles.

All in all, Liar’s Contests establish the relationships and conditions for bad things to happen, both now and forever more.

Game Over

To end the Liar’s Contest, both parties must realize what is missing in their interaction: the other person and the context of the discussion. In our story, each player in the Liar’s Contest saw only his own role. Sharkey saw Engelbert only as an impediment to his success. Engelbert saw Sharkey only as an obstacle. Neither saw the other as a human in the same boat as himself, nor did either player see himself as just one part of the bigger system. The reality is that Sharkey and Engelbert are both parts of an interconnected system. For Sharkey’s sales to increase, the developers need to deliver a quality product. For client expectations to be easily managed, the sales force has to provide realistic delivery dates.

While early delivery may result in increased sales, these sales come at a cost. Increasing sales may mean more customers, but poor quality software leads to increased support costs. Thus, the company may be less profitable than before. Customers may lose time fighting a faulty product. As support degrades, they tend to switch to a competing product. What both the company and customers need is not software in three months, but software with
sufficient quality as quickly as possible.

When the goal is stated this way, both players can support it. This agreement allows for a number of possible interventions that could end the Liar’s Contest:

1. Include pertinent contexts in the negotiations. If Sharkey explains why the dates are important, it could give Engelbert an opportunity to suggest trade-offs, so they could deliver the most valuable product possible within the time constraints. If Engelbert points out the quality trade-offs that the short schedule forces, Sharkey may see that it could cause customers to choose competing software. Sharkey can then work with Engelbert to find a date that will work for both of them.

Ideally, Engelbert would show the trade-offs by bringing real customers into the discussion, but salespeople who like to win Liar’s Contests generally work to prevent actual contact between customers and developers. If this happens, Engelbert should ask the customers if they want to talk directly with him. If the customers do want to talk to him, Engelbert should ask them to insist on it. He shouldn’t volunteer more than that. Concerned customers will make it happen. If the customers are not concerned about lies, Engelbert shouldn’t be concerned either.

2. Avoid all or nothing discussions. Offer options during the negotiations. Consider a range of features over a corresponding delivery time frame. Say, “If you really need that delivery schedule, here’s a list of functions. Start cutting them one by one and I’ll tell you when you’ve cut enough so we can make the schedule.” Or, if it’s feasible, you might say, “If you give me this and this by such and such a date, then we could make that schedule.” Be sure to ask only for things they can actually get for you – not, for example, promises of “perfectly clean component deliveries.” And be sure to have this in writing, in case they don’t deliver and still expect you to make the date.

3. Say “I don’t know.” Instead of saying “that can’t be done,” Engelbert can engage Sharkey in trying to solve the problem by saying, “I understand what you want, but I don’t know how to give it to you. Do you see something I don’t? Can you show me how to do this?”

4. Let someone else do it. Sharkey might threaten Engelbert, “If you can’t deliver, I’ll find someone who can.” Engelbert may defensively insist there’s no need to go outside, but properly engaging outside help can create the opportunity for the inside developers to learn new software packages, techniques, and skills. Or, if the outside developer fails, the sales organization has a chance to learn more reasonable expectations about software development.

5. Add another information path. Include the company president, developers, customers, or other parties who have skin in the game. Again, invite them to ask themselves in, using their power to get what they want and need. If they don’t want in, then it’s no longer a problem.


Nobody has to engage in Liar’s Contests – unless they enjoy it more than they despise the consequences. Understand the dynamics so you can show other people the consequences of starting a Liar’s Contest. A copy of this article might serve that purpose quite well. It has for us.

< Publication Notice> – A version of this article was previously published in Better Software, May/June 2004

Planning for Delays

©2000 Gerald M. Weinberg,

As some of you know, a group of consultants are producing a conference for our colleagues and clients. It’s called AYE, for “Amplifying Your Effectiveness.” One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn’t.

My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base — a situation that’s more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what’s happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.

I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we’re doing about them, I’ll present a few general principles that might also be helpful to others:

1. One project member’s email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.

2. Rick’s color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.

3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays — but didn’t because people had their own budgets and could pay the bills and trust they would be reimbursed.

4. Kevin breaks his hand, which is especially tough because he can’t use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn’t the only one whose article was delayed.

5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it’s not yet on the critical path.

6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).

7. Several people take vacations they’ve been planning for a year or so (how inconsiderate of them!). This wouldn’t have been much of a problem if we’d thought to put these vacations in our plan.

8. Naomi has a serious family situation, so she decides she must cut back on her participation until it’s resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi’s participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).

9. People who were not at our initial planning meeting have to be brought up to date — not just on our plans, but on the logic behind our plans. We haven’t planned for this, so it’s a real delay — but has an excellent side effect of making us rethink some of our logic before it’s too late to change.

10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven’t thought of. James is also an excellent writer/editor, and can take up some of Naomi’s tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn’t have had time to pay off.

11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.

12. Marie’s son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference’s problems!

13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I’ll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference’s problems.

14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project — and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.

15. Unfortunately, some of the articles submitted aren’t up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don’t practice it.

16. There are lots of typos in the material we prepare for our web site (, but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.

17. From time to time, some team member panics about some item or another — which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.

18. Then there are holidays, delaying things in a variety of ways. Why couldn’t Jesus have been born in August, we ask? Poor planning, we concluded — was it by God or by us? Probably us.

19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we’ve learned Freedman’s First Law of Consulting: Don’t fly on the East Coast in Winter.

20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve’s ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams’ lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider — a lesson for next time.

21. Then, once we have all the essays and bios and pictures, we realize that some people haven’t kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, “It just didn’t seem important to keep those legal things — at the time.” Lesson obvious, and lesson learned — I hope.


Well, there are lots more than twenty-one, but I think I’ll stop here. Some of us will publish the entire project’s delay list in the future; it will probably be a book. And we’re planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.

God may have other priorities higher than your project. Leave some slack for Acts of God.

Perfectionism kills schedules; reasonableness saves them.

Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate “bad luck,” but it also lowers psychological pressure on participants, which leads to “good luck.”

Quality is negotiable, but not infinitely negotiable.

Plans are predictions; plan to test them early and often, and then adjust them.

Machines fail. Software fails. People are even less perfect, but they’re more adaptable, so they’re handy to have around to back up the machine systems.

If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you’ll remove it.

Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project’s assets. If you fail to follow this system because “it doesn’t seem important,” you’re sure to lose your assets.

You won’t be aware in advance of all possible single points of failure, but if you do some risk analysis, you’ll be aware of many of them, which will leave you more time to deal with the ones you weren’t aware of.

You won’t appreciate other peoples’ delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.

And, finally, I often hear my clients telling me that their project will make its schedule “if everything works out right.” Well, I’ve been in the project business for over forty years now, and I’ve seen several thousand projects. I’ve never seen one where “everything works out right.” This has led me to formulate Jerry’s Iron Rule of Project Life:

It Always Takes Longer

Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren’t part of your plan. You’ll be more successful, and you might even be happier. As of now, we’re on schedule for November, and we’re rather happy about it.

Seeing the Other Person’s Big Picture

©2000 Gerald M. Weinberg,

You’re entering a new situation, and you’re ready to gather the Big Picture of the other people involved. Whatever you do, don’t try the following process without first getting a Big Picture of yourself, as discussed in an earlier article. If you’re not personally centered, this whole process will sound hollow and even smarmy.

Which others’ Big Pictures? Well, who will the significant others be? Anybody I omit from this survey will potentially appear on stage at a critical juncture and spoil my best-laid plans. The people I usually have to consider are Dani, my wife and business partner; Sweetie and Ruby, my German Shepherd dogs and biggest supporters; Lois and Susie, my coworkers; other colleagues in my network, such as my PSL faculty colleagues; my customer, the one who’s going to pay my bills. In this column, however, I’ll focus on my clients, the ones I’m going to work with on this assignment.

I’ll look for the answers to the three Big Picture questions:

- How do they happen to be here? (Past)

- How do they feel about being here? (Present)

- What would they like to have happen? (Future)

How do they happen to be here? (Past)

When someone talks about past consultants, they’ve given me a free head start without my having to ask one of my “past” questions, such as,

Did Darlene choose to be here, or was she forced by me, or some other factor, like her boss?

What has been her past history on this job? What knowledge does she have that I can tap into? What prejudgments has she made about the nature of this task?

Has she had early personal or cultural experiences that might affect the way she works on this job? With me? These are not excuses for poor performance, but things I have to understand to work well with Darlene.

What’s been her past experience with me? With other contractors? What preconceptions does she bring to the table as a result of these experiences?

How do they feel about being here? (Present)

In this instance, I knew right away that this organization “had consultants before, but none of them made any difference.” Obviously, Darlene felt that this was an important thing to say, but I didn’t know why she brought this up so early in our relationship:

Does she have some reservations, or forebodings, about this assignment? About me? Does our doing this assignment conflict with something else she wants to do?

Is she eager to be here? Is she looking forward to working with me on the task that I’ve agreed to do?

Is she clear about what’s going to be required of her if I take this assignment?

How’s her self-esteem? Does she feel able to control her situation and accomplish her personal goals, or does she feel powerless?

However she’s feeling, is hers the right mood for me to succeed in this job? If not, what steps can I take to help her get into the right mood?

I often seek this information by asking, “And what does that tell you about my tour of duty?” Here are some of the answers I’ve received from Darlene and other people, at other times:


You don’t have a chance, so I’m not going to waste any time helping you.


You’re going to need my help if it’s going to turn out differently this time.


It’s nothing personal, but this will be another of those management vision things, full of sound and fury and going nowhere.


I’m really excited, because you’re different from any of the consultants we’ve had before. This time, our consultant is really going to make things better around here.

Each of these answers is full of information, but I’m going to work differently with each of these people.

What would they like to have happen? (Future)

First, though, I have to know the answer to the third question, “What would you like to have happen?”

Why did X agree to work with me on this assignment? The experience? The challenge? Fear of the boss?

What will success look like, to X? Is it aligned with my success criteria? Did previous consultants solve problems that X failed to solve, thus making X look like a failure?

How long does X want me to be on this assignment? Will I be able to stay long enough to see it through? If the customer extends the project, will X be laughing or crying?

My responses

Assuming each of them genuinely hoped something would change, but knowing that each felt differently about my being here, I would construct different responses, perhaps as follows:


You don’t have a chance, so I’m not going to waste any time helping you.


I can understand your feeling. I’ll do my best not to waste any of your time, but if I should happen to come up with something that might save you some time, would you be interested in hearing about it?



You’re going to need my help if it’s going to turn out differently this time.


Great! What sort of help do you think you can give me?



It’s nothing personal, but this will be another of those management vision things, full of sound and fury and going nowhere.


Yes, I’ve sure seen my share of futile, grandiose projects. I personally think that big changes result from an accumulation of small changes. Would you be willing to work with me on some small thing that would help you in some way? Then we could see if we’re wasting our time, or if things might be different this time.



I’m really excited, because you’re different from any of the consultants we’ve had before. This time, our consultant is really going to make things better around here.


I’m flattered. Thank you. In what way do you think I’m different from the others, and why do you think that will help?

As a result of learning their Big Picture, I’m no longer knocked off balance. Instead, I’m well centered and already beginning to create a method of working appropriately with each of my clients.

Question and answer

Q: How do you come up with such responses in real time? They make sense when I read them, but in the moment, I often go blank.

A: There’s a pattern, but it won’t work if you think it’s a formula. You must remain creative in order to fill in the pattern, so the first thing you must always do is center yourself. Then, find a way to connect with the emotional content of what they’re saying, relating your own emotional state to theirs. Only then can you proceed to the content — what they want to have happen, and you might do next to move toward what they want.

Seeing Your Own Big Picture

©2000 Gerald M. Weinberg,

The editor of Contract Professional chose the name for my column there, “The Big Picture.” He told me he chose the name “because you (Jerry) look at the business of contracting and consulting and the people skills involved, which translate across all skill sets and even industries” — in short, The Big Picture.

That’s flattering — but why would you want to look at the Big Picture? If you’re like me, you’re often called into an assignment because you’re supposed to be an “expert.” You know what an expert is: “someone who avoids all the small mistakes while committing a grand blunder.” So, before I get down to the nitty-gritty of a new assignment, I like to place everything in a grand array. I always make mistakes in my assignments, but this way I can hope they’ll all be small mistakes.

My favorite method of approaching the Big Picture is first to break down the question into three parts: Self, Other, and Context. In this column, I’ll start with Self — that is, the Big Picture of yourself.

Focusing on myself, I then ask three three questions I learned from the famous family therapist, Virginia Satir:

- How do I happen to be here? (Past)

- How do I feel about being here? (Present)

- What would I like to have happen? (Future)

How do I happen to be here?

Here are some Big Picture questions that make an enormous difference in how I approach an assignment.

If it’s the first assignment with this client, how did I make the connection? Was it through a third party, or through a direct contact by the client?

If it’s a repeat, what impressions did I leave the previous times I was here? Did I leave friends, or enemies? Are my old contacts still viable? What assumptions am I carrying over from the previous assignments?

Did I get the contract I wanted, or did I have to make some concessions that might come back to haunt me?

How do I feel about being here?

Am I here reluctantly? Do I have some reservations, or forebodings, about this assignment?

Am I eager to be here? Am I looking forward to the task that I’ve agreed to do?

Am I puzzled about what’s expected of me, or is the assignment clear? How sure am I of the assignment?

How sure am I of myself — of my ability to provide value for value received?

However I’m feeling, is this the right mood for succeeding in this job? If not, what steps will I have to take to get in the right mood?

What would I like to have happen?

Why did I take this assignment? For the money? The experience? The challenge? The possibility of a future reference? If I don’t have my mission in mind whenever I choose a course of action, the client may be happy with my work, but I’ll come away with a hollow feeling.

What will success look like, to me? If I come away with a pile of money but a poor reference, will I be satisfied? How about an ecstatic client who’s enormously impressed by my repeating a solution I’ve done so often it bores me into a trance?

How long do I want to be here? If the client extends the project, will I be laughing or crying?

Using the Big Picture of Yourself

By using these three questions to assess my own state before I start an assignment, I’ve enormously increased my level of satisfaction. I use them to survey my state before I agree to any contract, new or renewed. On one occasion, for instance, I found I was about to renew a long-standing contract with a nice 15% increase in my daily fee. When I checked my feeling, however, I realized that I had negotiated for the wrong thing. Much of the time on the old contract, I felt that I was doing a fine job in solving the wrong problem, and I don’t find this very satisfying. I didn’t mind the extra 15%, but what I really wanted was more involvement in defining my own assignments.

Armed with improved self-knowledge, I halted the negotiation process and asked for more leeway, which the client was only too happy to grant. I was prepared to sacrifice at least some of the 15% increase, but the client insisted that I take it. He commented, “Now that you’ll be helping do the right things, rather than just doing things right, you’ll be worth at least that much more to us.”

Self-assessment doesn’t always pay off this directly. On another renewal, early in my career, my attempt to get more leeway in defining my work led to an irreconcilable difference between me and my client. This client knew — or thought he did — exactly what his problems were, yet I felt his poor problem definition limited my ability to be successful in my terms.

At that time in my life, what I wanted most was experience with certain types of problems and a few outstanding references. On my first assignment with this client, I had helped solve a problem that didn’t vaguely resemble what I really wanted to work on. And, though the solution was innovative and successful, it didn’t really help the client with his true problem — since he was working on the wrong problem to begin with. He attributed his lack of satisfaction to some unspecified shortcoming in my work, and was reluctant to give me a sterling reference.

And, of course, he was right. The shortcoming in my work was my failure to assess the Big Picture — both his and mine — before I took the assignment. As we negotiated for a follow-on, the three questions show me that the extra money he offered wasn’t adequate to overcome my bad feelings about working with him again. Negotiations broke down, but at least I didn’t waste another six months of my life struggling for something I didn’t really want.

It took me a few weeks to get a new assignment, and that cost me a few bucks. The cost is long forgotten, but I still savor the memory of my satisfaction with the new assignment — what I learned, what I earned, and how it put my professional life back on my own track.

Questions and answers

Q: It’s all very nice to say that I ought to be centered in myself before I make big decisions, but whenever I get into some sort of negotiation, I lose track of myself, what I want, and what’s good for me. What do you suggest?

A: This is too big a question to answer entirely, but the first part is easy. When you first notice that you’re starting to lose yourself, STOP whatever you’re doing. Then concentrate on how you’re breathing, and switch to smooth, regular breathing.

Q: I’ve tried the breathing thing, and sometimes it works. But sometimes it doesn’t, like when another person is blasting at me in a loud voice. What should I do?

A: If you can’t get your breathing under control, find a way to leave the situation. If you wish to continue, come back later. If you find yourself unable to leave, then that’s a sure sign you must leave, now, and not come back. This is not the situation for you.

How did This Happen

©2005 Don Gray

It was Saturday afternoon when the house phone rang. “Don, this is John. I know we haven’t talked in 10 years, but I have a client who has a problem.” In 20 years I’ve never had a client call and say “Don, things are going great! Why don’t we pay you to do nothing? Just send us an invoice.” So I’m not surprised when the first words I hear are “Something’s wrong, can you come and take a look?” What did surprise me was Saturday and at home.

George, the client, works for a major defense contractor. Recently George inherited a system he didn’t know much about. The system had suddenly started producing about 25% defects. At $300 to $25,000 per part, upper management was screaming to find the problem and solve it.

Prelude to a Problem

We can use a general systems thinking drawing called a “Causal Loop Diagram” (aka “Diagram of Effects”) to see the situation’s dynamics.

Figure 1 – George’s Problem Solving Ability

You can start reading this diagram at any node. Cloud-shaped objects represent subjective quantities, values that defy quantifying, or are too expensive to quantify. “George’s Ability” doesn’t quantify easily, but you can experience it anyway. Ellipse-shaped objects represent objective quantities. Counting the number of problems and problems solved is easy to do. The arrows connect the variables and show the direction of influence. As George’s ability to solve problems goes up, the number of problems solved goes up. Black dots indicate an inverse action, so as the number of problems solved goes up, the number of remaining problems go down. As the number of remaining problems goes down, the time available per problem goes up. As the time available per problem goes up, George’s ability to solve the problems goes up. And around and around it goes.

Figure 1 contains “fuzziness.” George’s ability to solve any given problem will vary. Has he seen a similar problem before? What is his energy level? Will solving a given problem fit in the time available or will George have to “come back to it?” Even so, if we know George, we have an idea what kind of problem solving ability he has, and it’s a useful approximation.

Another important fact about Figure 1 is that the loop reinforces itself. This means if things are going well, they tend to get even better. Conversely, when things are going poorly, they’ll tend to get worse. We indicate this reinforcing loop with an “R1″ in the loop’s middle. When we add another reinforcing loop, we’ll label it “R2,” and so on. If things keep going well, eventually George will solve all the problems. I don’t think that will happen in George’s world, but theoretically it could. More likely, the QA department will want new information collected during production, clients will want different reports, the product engineers will decide to run the process differently. Or, George’s problem-solving ability will be recognized by management, and he’ll be “awarded” the department’s “problem project.”

Houston, We Have A Problem

When George inherits the problem project, suddenly, the number of problems he needs to solve skyrockets. Since this loop reinforces itself, as the number of problems shoots up, fewer problems get solved (or at least the problem-solving rate goes down). Customers become unhappy. QA rejects more parts. When management finally gets involved, the “BIG MANAGER” flies down to take hands on control until “the problem gets solved.” Dynamically, this looks like Figure 2.

Figure 2 – From Bad to Worse

Note that adding management pressure creates a boomerang affect. The management’s goal is to help solve the problem quicker, but now George has less time to solve problems since he’s required to attend the daily meeting from 8 – 9 AM explaining what’s wrong, and what’s being done to fix it. The BIG MANAGER also moved into George’s office space. Now George gets to overhear the phone conversations about the project. This creates an additional distraction that reduces George’s effectiveness. Management pressure actually creates two new reinforcing loops that amplify the effects in the original reinforcing loop.

Reinforcing loops are ‘engines’ in systems thinking. They cause either growth or decay until something happens that stops the cycle. In the positive cycle, George would eventually solve all the problems. In the negative cycle the problems get worse until something collapses. George could quit or get sick. Clients could take their business elsewhere. To prevent collapse, management needs to intervene to balance the system’s dynamics. This led to the Saturday phone call.

When I became involved, the system structure changed again. The result looks like:

Figure 3- Starting to Balance

As George’s ability goes down, the need for George to obtain help goes up. As George gets more help (becomes more efficient), the number of problems solved goes up. As the number of problems solved goes up, the number of remaining problems goes down. As the number of remaining problems goes down, the time available per problem goes up. As the time available per problem goes up, George’s ability to solve the problems goes up. Eventually, the need for my involvement should be come less, as the system recovers its balance. My involvement creates a “balancing loop” (B1). Balancing loops add stability to systems and organizations.

Creating Causal Loop Diagrams

Causal Loop Diagrams help reveal system dynamics. Creating the diagrams involves more work than reading them, but can be done by anyone willing to take time to think things through and look for relationships. For example, what problems might arise by involving help? Is it possible that things will get worse before they get better? And why would that be?

The Buddy System

The first step in creating CLDs: find a buddy, friend or coworker with whom to share the process. When I started working with CLDs, I didn’t pay attention to this. I’ve since noticed that I add something to every diagram that comes my way, and every diagram I send out comes back with meaningful corrections or contributions. This happens because everyone’s world-view is slightly different. Most world views overlap enough that we can understand each other, but are different enough that other people will think of things you don’t. If you’d like, you can send me your drawings for review and comment.

If another view-point is necessary, two may be better. But be aware that at some point adding people will create more “drag” on progress than contributing “thrust” towards completeness. In a work environment, completeness counts more than speed, so make sure you consider all viewpoints when developing CLDs. For independent work, I prefer “mostly complete” and quickness.

When sharing with your buddy, consider how you’re going to present the CLD. I worked with a friend on the phone one time and tried to draw the CLD as he described his drawing. Unless you enjoy lessons in miscommunication, skip this and at least send some sort of a drawing (JPEG, GIF, PNG) they can view, print and mark up. I’ve found sending the actual drawing works best. For Windows users, I typically use Visio. I have a template for CLDs (using Jerry Weinberg’s notation) that my friend Brian Pioreck created. When I’m working with Mac users, I use Canvas to create the CLDs. In both cases, we can change the CLD and share the results via email.

Creating a CLD usually follows these steps:

  1. Bump headfirst, sometimes painfully, into a puzzling question.
  2. Think about the question.
  3. List some variables related to the question.
  4. Connect the variables showing how one influences others.
  5. Check the CLD by reading the story.
  6. Repeat steps 2 – 5 as necessary and appropriate.

What was that?

Here are some questions that usually start my systems thinking mode. “What is really going on here?” “Why is this happening again?” “You mean adding help might make things worse?” “What possible negative impacts could there be?” “How could that happen?”


Sometimes when I think about a problem, I can see the answer immediately. Other times I have to commit the problem to my subconscious and do something else until good ideas surface. I have favorite activities that involve my body, but leave my mind free (like bush hogging). Other activities (like Aikido, hitting golf balls) occupy all of me. Typically the more perplexing the problem, the more I need to focus on something else for a while.

Thinking about the question hopefully leads to a deeper understanding of the situation. If it doesn’t perhaps the question is too small or too big. Perhaps the question isn’t clearly stated. Try changing the question and see how it changes your thinking.

As I thought about the question, I remembered how sometimes the changes we make to help actually result in decreased results before things get better. This leads to the “worse before better dynamic”.


Now it’s time to list the variables you’ve discovered in your thinking. Choose things that can change. “Number of Problems Solved” changes and influences other variables. I like to use variable names that work with “As [insert name] goes up (or down), then [downstream name] goes down (or up).” This helps me prevent putting constants in the model. Let’s consider the following variables:

  • Number of New People
  • George’s Training Load
  • Number of Problems Solved
  • Relative Progress

In my experience, getting all the variables in the first pass doesn’t happen often. The point here is to look for hidden structures that create the observed dynamics. As the drawing takes shape, new variables appear, and old variables may not be needed. It depends on your point of view.

Which Comes First?

Since all the variables are related, and you can start reading a CLD at any point, it doesn’t matter which variable gets put in the drawing first. Pick one and get started telling the story. Once in a great while I do a hand sketch. Generally I head straight to the drawing package where I can cut, paste, drag and drop. So far, the results of getting someone to help George looks like:

Figure 4 – Adding Help

This means as more people are added, George will actually solve fewer problems in the immediate future so the relative progress goes down.

The Rest of the Story

As I draw the CLD, I find myself rethinking assumptions and conclusions. This restarts me iterating through the steps. Don’t be surprised if it takes several iterations to become comfortable with the CLD. For example, Figure 4 doesn’t include the results of George’s training load. Adding Figure 1 and Figure 4 together we get:

Figure 5 – The Solution

This happened in this situation. The additional skilled effort increased the number of problems solved to the point where the defect rate fell below 1%. This put George back in the original position of being able to solve the problems as they occurred.

The Never Ending Cycle

If two people take the same variables and each create a CLD they may not produce exactly the same drawing as I do. That’s OK. That’s also why it’s good to have other people review your drawings.

Causal Loop Diagrams give us a method for revealing hidden system structure. Being able to read and create CLDs provides a way to clarify our thinking and for sharing our current understanding.


I appreciate Johanna Rothman and Stuart Scott for their contributions to this article.

Shifting the Burden – Whose Monkey Is It?

©2005 Don Gray

“Repeatedly curing a system that can cure itself will eventually create a system that can’t.” - Marvin’s Second Great Secret, Jerry Weinberg

“Don, the software’s locked up again! Can you come up here tomorrow and fix it?” George was on the other end of the conversation. George and I had started working together when his employer moved a production line from Florida to Virginia. This move created all sorts of problems1.

The daily struggles getting the hardware, software and process playing nicely together had become a weekly check-in with an occasional on-site visit. This made the request seem a little odd.

Taking a deep breath allowed me to work through some quick thoughts2. The software was running on 15 different computers. There wasn’t any way they could all lock up at the same time. And what does “lock up” mean anyway? What’s going to happen different between now and tomorrow, or now and next Monday? And if I drop what I’m currently working on to rush up there tomorrow, am I really helping George? What long-term consequences result from this?

Solution #1 – The Quick Fix

Accepting that a problem is an undesirable difference what we want and what we have, George had a problem. Since I helped George with several other problems, it seemed natural that I should help with problem also. Using a causal loop diagram, the situation looks like this:

The more the computer locks up, the more Don gets called. The more Don gets called, the more problems he solves. The more problems Don solves, the less the computer locks up. This is a balancing loop that brings stability to George’s process. It’s also a symptomatic solution, a quick fix to make the pain go away. But following the steps in B1 only solves the immediate problem; it does not solve the underlying fundamental problem. Think of it as treating the symptom, not the disease.

Solution #2 – George Learns to Solve the Problem

There’s another possible answer. What does it look like if George solves the problem without calling Don? First George needs to learn “C” much better than he currently knows it. That takes time. This time delay gets represented by the “||” mark on the line. Then he needs to figure out where in the 5000+ lines of code the problem resides. That also takes time. Finally George can solve the problem, but by now something else is broken worse somewhere else, everything gets put on hold, and when George finally gets back, he’s lost his train of thought, and has to start solving the problem again. Diagrammatically we represent it this way:

This is also a balancing loop bringing stability to the system. B2’s advantage over B1 is B2 represents a systemic solution. The more the loop executes, the better the system gets at solving the problems. This reduces the system’s dependence on outside interventions. The disadvantage of B2 is the time delays involved in learning “C” and understanding the application code. The time delays do get less the more the loop executes,

Solution #3 – Combining the Symptomatic and Systemic Solutions

Since B1 and B2 both contain “Computer Locks Up” we can combine the two causal loop diagrams into a more complete problem-solving picture.

This shows the how the event “Computer Locks Up” can trigger one of two responses: a symptomatic response to make the problem go away quickly (B1), or a systemic response (B2) where the system becomes more capable of solving problems without external influence. This pattern occurs often enough that systems people have given it a name, “Shifting the Burden.” I’d been aware of this archetype, but preparing for my “Deja vu” session3 with Diane Gibson sharpened my awareness of what could go wrong.

An Unintended Consequence – Too Much Help

There happens to be a long term reinforcing loop that can show up with this archetype. This occurs when the symptomatic solution (B1) gets all the action. Don becomes better at both “C” and knowing the code base. This makes it easier and quicker for Don to solve the problems, and Don becomes indispensable.

This means the system’s ability to “cure itself” becomes atrophied. George loses his ability to persuade management to give him training. Production becomes accustomed to “great customer service” from Don. The ability to tolerate “pain” goes away, and the quick fix becomes the only fix.

Invoking the symptomatic solution not only starts B1, it initiates R3. Calling Don reduces the need to learn “C”, thereby weakening the system’s problem solving ability. Carried to the extreme, this becomes an addictive response, and cripples the system.

And The Final Answer Is

Either balancing loop can be chosen to a given problem occurrence. Handled properly B1 can be used to alleviate acute problems, while invoking B2 to solve chronic problems. This pattern of selectively, consciously choosing how to deal with each problem has resulted in George’s ability to solve more code problems and start making enhancements to the code base.

I appreciate Stuart Scott and Jerry Weinberg for their suggestions about this article



Humor and General Systems

© Michael Bolton

Jonathan Miller is one of the great Renaissance men of popular culture. He has been a medical doctor, an opera director, a television documentary writer and producer, but he first gained prominence as a performer in the British comedy revue Beyond the Fringe. Several years ago, I attended a lecture by Dr. Miller at the Ontario Science Centre in Toronto. The topic was ?Humour in Science?.

Dr. Miller began with an apology and an explanation. When the Science Centre had approached him to present a lecture, he had been given a title for the talk, but nothing more. He apologized for those who were anticipating ?Laughs In The Lab? or ?Six Pranks You Can Play With Bunsen Burners?. Instead, he had chosen to speak on what science had to say about humour?why people had developed it in the first place.

He remarked that all humans smile and laugh in the same characteristic way. He also remarked that when biologists look for an explanation for some characteristic of a species, they look for biological advantages ? the ways in which that trait would allow a species to adapt to its environment. Humans were by no means the fastest or strongest animals in their environment; the most dramatic adaptation that humans had made was to develop their intelligence, and Dr. Miller contended that humour was a part of that. Humour, he said, allowed us ?to alter our categories, to see things from a different perspective.? That ability, in turn, allowed us to deal with new information, and to develop new models of the world. This, he suggested, explained everything from children?s play to gallows humour.

Over the years, I?ve heard many very smart people (some of them funny) suggest the same kind of thing. Marshall McLuhan used subtle jokes and wordplay as a means of probing ideas. Richard Feynman was an inveterate prankster. Martin Gardner used humour and parody as a means of disposing of ideas that he considered foolish; ?one horselaugh,? he said, ?is worth a thousand syllogisms.? Wade Davis, the great Canadian explorer and anthropologist, remarked that the Inuit made laughter and jokes central to their culture as a means of helping them to maintain social ties that were essential to survival in Canada?s north.

In the last few years, I?ve begun to notice how certain jokes neatly express general systems ideas and problems with requirements. (I note that there?s a risk here: analyzing a joke is one of the most unfunny things that one can do. Oh well.)

George Carlin is, to me, one of the best observational comics of all time. One of his lines:

Some say the glass is half-full. Some say the glass is half empty. I say the glass is too big.

The observer who can only see the contents of the glass may not have insight into the problem; the dominating observer will recognize the possibility that what we think of as the ground might be the figure. On the other hand, one dominating observer might miss something that another kind of dominating observer would see; a student recently remarked to me that the glass was completely full? of air and water.

Here?s another one from George Carlin:

When it?s time to board, people come running around say ?Get on the plane! Get on the plane!? To hell with that; I?m getting in the plane.

In a document, a single preposition can change everything. Some people recognize these little differences and their significance. These people get to sit in seats that are less windy than others.

This next joke doesn?t come from any particular comedian; it?s just out there in the popular culture, and no one knows where it came from. (If you find the reference to blondes insulting, please mentally substitute ?balding Canadian guy in his mid-forties?, and change ?she? to ?he?.)

A blonde is walking along the edge of a river. She wants to cross, but sees no bridge and no tunnel. After a while, she sees another blonde across the way. She shouts, ?How do you get to the other side?? After a brief pause comes the reply: ?You?re ON the other side.?

Like general systems thinking, this joke teaches us to recognize the significance of where we are relative to the thing that we?re observing.

Steven Wright says:

I have a full scale map of the United States. It took me all last year to fold it.

Models are designed to make it easier to understand something. The value of a model lies in the way that it shows certain information while leaving out other information. A model might not be so useful if it fails to simplify the problem in certain dimensions.

Here, by the way, is the same joke told in a somewhat more sophisticated way. A colleague, Mark Garnett, supplied a story from Del Rigor en la Ciencia, from a book called El Hacedor by Jorge Luis Borges:

?In that Empire, the Art of Cartography reached such perfection that the map of a single Province occupied a whole city, and the map of the Empire a whole Province. With time, these outsized maps failed to satisfy and the Colleges of Cartographers created a Map of the Empire which was the same size as the Empire and which completely coincided with it. Less addicted to the study of Cartography, subsequent generations understood that this extended map was useless and not without impiety handed it over to the justice of the sun and the elements. In the Western Deserts some rootless remnants of the map remain, inhabited by Animals and Beggars; there is no other relic of the Geographical Disciplines in all of the Country.”

As Mark points out, Steve Wright?s story is simpler, and perhaps models the problem more efficiently. Or maybe Borges? Empire was bigger than the United States.

One important general systems lesson is that the notational system shouldn?t affect the result. In English, we overload certain words in certain ways. Here?s a joke that takes advantage of that?and if we notice the paradox, the joke helps us to understand both the transitive property and the difference between the null set and the empty set:

How is a cheese sandwich better than complete happiness? Nothing is better than complete happiness, and a cheese sandwich is certainly better than nothing.

Like general systems thinking, comedy encourages us to see things from different perspectives, the better to understand them. I look forward to the day when we can go to nightclubs, and see general systems thinkers riff for half an hour on the similarities between epidemiology and corporate communication.

Nah; I’m just kidding.