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.

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

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.

convert this post to pdf.

©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?”

convert this post to pdf.

This column originally appeared on Stickyminds.com.

Conflict is inevitable at work. Sooner or later, you will disagree about what to test, when to test or how long to test software. How you.and the person you disagree with.approach the conflict affects both the outcome and how you feel about the exchange. Let’s listen in as Jim, a test manager, and Pam, a development manager work through one of those inevitable conflicts.

* * *

Jim, the test manager, started the coordination meeting with
Pam, the development manager, by stating that he needed her team to turn over
all the code on the first Monday in September. In a previous meeting, they’d
discussed having the code complete in October, but Jim’s statement sounded like
a demand to Pam rather than a starting point for discussion.

Pam asked Jim what was behind the change, and when he said
he wanted to begin testing early, Pam was thrilled.

“That’s great,” Pam said. “Early testing will really help
us. We won’t have all the code done until the October date we discussed
earlier, but we’ll have features ready to test starting in August. I can turn
over features every two weeks from August through September.”

“No, I need all the code for early testing the first week
in September,” Jim reiterated.

“Is the issue that you don’t have anyone to assign to
testing earlier?” Pam probed.

Jim shook his head. “No, we need the code all at once.”

Pam asked more questions to understand Jim’s concerns and
offered more options, but Jim stood firm.

Later, Pam mused to herself, “It’s almost as if he needs me to lose in order for him to win. I
offered everything I could think of so the situation would work for both of us.
Now we’ll have to hash this mess out with the VP. Why does Jim always have to
have his way?”

Meanwhile, Jim was thinking, “Why did Pam try to weasel out of this? If I agree to her options, she wins.”

Scenes similar to this one play out in business every day.
The people and the topic may be different, but the ways Pam and Jim are
approaching their differences represent common approaches to conflict:

• Collaborative Problem
  Solving–Pam is approaching her conflict with Jim by trying to find options
  that will work for both of them. She’s looking for the interests behind Jim’s
  position, sharing her interests, and looking for options that satisfy both
  parties.
• Competition–Jim, on the other hand, is approaching the conflict with one aim in mind: achieving his goal. He’s not willing to explore other options; he’s intent on pressing his preferred solution. If he get’s his way, Pam doesn’t get hers.

In addition to Pam’s Collaborative Problem Solving approach
and Jim’s Competition approach, there are three other common approaches to
conflict:

• Yielding–In this style, one person yields, accommodating the other personís wishes without pressing his or her own interests.
• Avoidance–Sometimes people do
  everything they can to avoid a conflict. They pretend the difference doesn’t
  exist to avoid the unpleasantness of confrontation.
• Compromise–In compromise, people try to meet halfway. Each gives up some of what he wants and achieves some of
  what he wants. Compromise is common, though not always satisfying since no one
  is completely happy with the solution.

All of these are valid and useful ways to approach conflict
in some situations. And each can be destructive when misapplied.

In the story about Pam and Jim, Jim could have achieved his
stated interest had he been willing to look for more options to meet the goal
of early testing. His desire to prevail–competition–in this situation will
damage his relationship with Pam, and may hurt his reputation with the VP.

Pam’s approachócollaborative problem-solving, while
appropriate in this situation, might not be helpful when there’s a clear
downside to meeting the other’s interest—for example if the other person
wants to pursue an illegal or unethical action. Pam’s collaborative approach
also takes time in order to uncover interests, generate options, and reach a
mutually satisfying outcome. It’s worth the time when long-term relationships
are at stake, but may not be when time is of the essence or the relationship is
transitory. (If a store clerk in the airport wants to talk on the phone with a
friend instead of serving you, and you have a plane to catch, you probably
won’t use a collaborative problem solving approach. You just want to pay for
your item and be on your way.)

Likewise, yielding is fine when one person doesn’t have much
investment in the outcome and the other person does. Yielding hurts when it’s
habitual–one person always gives in to the other. Others may perceive habitual
yielders as doormats and walk all over them. An
example in the workplace is when someone always says “yes” to all his manager’s
requests without discussing risks and negotiating. The long term cost of
habitual yielding is resentment, depression, anger, and contempt.

Avoidance may be the best policy when there’s nothing to be
gained by working through an issue. For example, one manager walked away from a
conflict with a peer when they couldn’t agree on a testing standard. He saw
that the situation would correct itself as soon as the standard (which he
believed was misguided) was published to the organization, and that arguing
with his peer would only damage their relationship.

We often hear that compromise is the ideal, and sometimes it
is. But looking for compromise often ends in a half-horse, half-camel solution
that isn’t fully satisfying to anyone. Compromise leads people to miss novel
solutions that can satisfy both parties and may be better than either of the
original solutions. Pam could have compromised and agreed to turn over
partially completed features, but that wouldn’t have worked out well for either
Pam or Jim. Compromise is the best option when it’s clear that a collaborative
solution isn’t possible.

Like Pam and Jim, most of us have a preferred style for
approaching conflict. Sometimes it works for us–and sometimes it doesn’t. When
we approach every conflict with the same style, regardless of what’s at stake
and without consideration for maintaining important relationships, we may win
in the short term but lose in the long term. Or we may avoid a difficult
conversation but build up resentment. We’re all more effective when we develop
our ability to approach conflict with the style that suits the situation.
Consciously choosing which approach fits best, given the stakes and the
relationships, is a winning strategy every time.

convert this post to pdf.

“England, though at present enjoying a very high state of prosperity, still shows some symptoms of a decaying nation. Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to finding a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible; if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple. Import the same principle or show the same machine to an American, or to one of our colonists, and you will observe that the whole effort of his mind is to find some new application of the principle, some new use for the instrument.” — Charles Babbage, 1852

As early as 1852, Charles Babbage could see symptoms of decay and infer from them a vision of future performance. In so doing he provides a perfect description of the blaming style of communication, which emerges in ‘decaying’ organizations–be they nations or software engineering organizations. What is a “blaming style of communication,” and why is it important in systems development?

What Is Congruence?

Congruence is a concept that describes the human experience of alignment between the internal and external–what is thought and felt (the internal), and what is said and how it is said (the external).

In order to operate congruently in the world, you need to take into account three general factors: self (the internal world), other (the immediate external world of people), and context (the larger external world of things, structures, processes, laws, and cultures).

• Self: You must consider your own needs and capabilities. Suppose you are a manager who doesn’t trust anyone else’s judgment, so you try to attend every technical meeting. Doing this, you’re likely to overload all your available time, and then be unable to do the managerial job, nor to make real technical contributions in any case.
• Other: You must consider the needs and capabilities of other people. For instance, if you are a programmer who refuses to be bothered to write readable code, then testing and maintenance of your code will be a great burden, if not an impossibility.
• Context: You must consider the reality of the context in which you are operating. For instance, if you are a manager who insists on sticking with an old design that no longer has the capacity to handle the task, your project may be doomed no matter how hard everyone works. Or, if you are a manager in a start-up company and spend money as if the company had a billion-dollar cash balance, your organization may be out of business before its software product is ready for market.

Congruence is integrity at the most basic level and thus has immense value to a project and each individual in it. Without integrity, we cannot build trust; without trust, we don’t feel safe; without safety we have a hard time being congruent. Thus, congruence reinforces congruence in a powerful loop which improves the chances of producing a quality product, on time, and within budget.

On the other hand, the same loop causes incongruence to reinforce incongruence. If a project is allowed to ride such a downward spiral, the integrity of information is destroyed. Soon it becomes impossible for anyone to know what is really happening. Such projects invariably fail, and when they fail, they are invariably found to have been keeping two sets of “books.” Their external picture is not congruent with their internal picture, and they die. Or worse yet, live forever–the living dead.

If congruence is so important for project success, why aren’t all projects congruent? One reason is that congruence is not without a price. Another is that congruence usually involves risk. The level of risk is somewhat contingent on the kind of congruence being demonstrated–mental or emotional.

Mental congruence

In the United States, it’s relatively easy to express our thoughts with out too much incrimination–freedom of speech was a foundation upon which the country was built. Even so, there may be a price to pay for “speaking up.” For example, differing with a colleague or someone in authority at the wrong time can put us on a fast track to isolation, reprimands, reduced opportunities, and subtle door closings. Thus, we’ve all learned the importance of being careful about what we say where and to whom. Saying the wrong thing can lead to heated debates, followed by proclamations of who is right or wrong and who is good or bad. At that point, we’ve lost most possibilities for enhanced understanding and effective communication.

Emotional congruence

In our culture, feelings are reserved for athletic events, celebrations, funerals, near death experiences, deeply felt spiritual experiences, fights, and exchanges between intimate others, the very young and the very old. We even have many feelings about our feelings and some of the strongest have to do with shame and embarrassment over having them. Feelings are personal and lie close to our heart, where we are tender and vulnerable. No wonder we have all become so skilled at denying our feelings–which necessarily makes us incongruent.

Suppose you are a developer who is scared that you won’t be able to deliver a product when you promised. You try to tell your manager about your fear, but he tells you in no uncertain terms what will happen to you if you don’t express more confidence. “Why are you so negative? Aren’t you a team player?” One way to protect yourself from such negative responses is to live in your head. Perhaps you say, –”It’s just an estimate; I’m not attached to it,” meaning you won’t be hurt because you’ve distanced yourself sufficiently to ward off anything that might hint at rejection. But, though you deny your scared feeling to your manager, you still feel it, squashed down inside. You can stand back away from your ideas, but you always remain standing in your feelings. And, of course, you have been incongruent, and deprived your manager of your best information.

When you share your feelings, your heart-self is being presented to the outer world–exposed to the elements. When you’re scared and express your fear while maintaining consideration for the other person (your manager) and the context (the project), you are being congruent. Your critical issue here is, “Can I share my feelings and still be in control?” If the environment of your project is blaming, it threatens to remove your control if you tell the truth–so the temptation to lie about your feelings and your ideas increases. That’s why blaming cultures lead to “double books,” and that’s how they lead to failure.

What is Blaming?

In a congruent organization, your manager asks, “Where does your project stand?” and you answer, “I’m rather scared that I’m not going to make my schedule.” This starts a problem-solving discussion, out of which the two of you make new plans to get the project back on track. In a blaming organization, however, your manager may well tell you that only inferior people lack confidence. In that case, problem-solving will be replaced by blame-avoidance.

From a writer’s point of view, congruent interactions aren’t very dramatic; people just act sensibly, are considerate of one another, get their work done, and enjoy what they’re doing. That kind of behavior might not make as good a soap opera scene as your manager throwing a tantrum and you cringing in the corner, but it definitely makes a better project.

Not that a blaming culture conducts every interaction in a dramatic, blaming way. Under ordinary circumstances, congruent coping is the rule, but if circumstances were always ordinary, we wouldn’t need managers. When feelings of self-esteem are low, they are manifest much more dramatically in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving or hating, and acting irrelevant. We can’t deal with all of these in a short article¹ , so let’s discuss blaming, perhaps the most common and most directly destructive of the coping styles.

Under stress, people tend to lose their balance, and one or more of these three essential components may be ignored, leading to a characteristic incongruent coping style. For example, when people fail to take other people into account, they fall into a blaming posture. Here is a typical blaming action you may see in software organizations (italicized words are stressed in this style of speaking–because multiple stressed words in a sentence are a linguistic sign of blaming²):

Manager, as programmer arrives late for a meeting: “You’re always late. You never show any consideration for other people.”

Why is this incongruent? If the manager really is feeling and thinking that the programmer is always late and inconsiderate, isn’t she being congruent by saying so? Yes, but that isn’t what this manager said. She didn’t say, “It’s my impression that you’re always late to my meetings.” Instead, she pronounced her impression of lateness as if it were a scientific fact, never offering the possibility that the programmer might have a different impression. She generalized experience in her meetings as if they necessarily applied to all meetings, never allowing for the possibility that her experience might not be the only one that counts.

If the manager really is feeling and thinking that the programmer is always late and inconsiderate, she might say, “I think that you’re always late, and I feel that you’re not being considerate of me and the others. Is this your perception, too?” (And leave out the stressed words.) Even better management style would be to give the programmer a chance to provide a different perception before launching into interpretation. At the very least, that prevents embarrassment in situations such as the following:

Manager, as programmer arrives late for a meeting: “It seems to me that you’re always late. Is this your perception, too?”

Programmer: “Yes, and I feel bad about it. The reason I’m always late is that I have to donate blood for my 9-year-old son, who’s dying of leukemia, and the only time they take donations is just before this meeting.”

Manager: “I’m sorry about your son. I didn’t know about it. Let’s figure out a new meeting schedule so you don’t have to be late.”

More generally, it allows for the possibility that there may be other considerations that count besides those of this one manager. For example, perhaps the programmer is coming from a meeting with customers–a regularly scheduled meeting which overlaps the manager’s meeting.

But what if the programmer really is always late, with no reasonable explanation? Isn’t the manager then entitled to blame the programmer? Not really, because this situation is not about entitlement, but about getting the project done. For that purpose, the problem is most effectively resolved using a non-blaming confrontation with the facts about the unacceptable behavior. By foregoing blaming, the manager keeps the communication clear and open, maximizing the chance that the programmer will receive the intended message. And, of course, receiving the intended message maximizes the chance (though it doesn’t guarantee) that the problem will be solved.

When blaming, problem-solving is less likely because the facts of the case become a minor issue–the major issue in blaming is “who is important and who is insignificant.” When blaming, a person is saying, in effect, “I am everything, you are nothing.” Of course, this stance comes not from really thinking “I am everything,” but just the opposite. Directing the attention at another person–and blaming is often accompanied by a pointed finger–is a self-protective device to distract others from the inadequacy the blamer feels.

Like all incongruent coping, blaming is reinforced by feelings of low self-esteem. When you blame, you attempt to build yourself up by tearing down others because you don’t have the confidence that you can amount to much–or even survive–any other way.

Blaming usually fools people who are unsophisticated, or whose own self-esteem is at a low ebb. The knowledgeable observer, however, sees the amount of blaming as a sure measure of how inadequate the blamer feels. Moreover, if blaming is the preferred project communication style, then it becomes a measure of how far an environment has degenerated–how little communication is being directed at the project’s issues, compared to the amount that is being directed to puffing up the communicator’s weak self-esteem.

In a blaming organization, it’s not merely the managers who blame, as illustrated by these examples:

Programmer, when asked by a manager to volunteer to talk to a job applicant: ‘Why don’t you do it yourself? I’m not going to do your job for you. If you were better organized, you wouldn’t need to ask me such things.”

Customer, when project manager asks about the possibility of revising the requirements: “You never get the requirements right the first time. If I told you once, I told you a thousand times: Do the job right the first time, then you won’t bother me with revisions.”

(To test your understanding of the blaming style of communication, you might try to improve the congruence of these examples.)

How Blaming Hurts A Project

Of course, people are not perfect, so it’s impossible to conduct a large project without occasions on which people cope incongruently. Normal project management can deal with these situations–when they are exceptional. But when the whole environment encourages blame, each new situation further elaborates the incongruence. Fred Brooks³ once asked, “How does a one-year project get to be two years late?” His answer was “one day at a time.” Our answer is “one incongruent communication at a time,” as the following example illustrates:

One of the developers was developing a module that produced a printed report when it was tested. The manager put a lot of pressure on the developer to be ready on time, with no excuses allowed. The programmer produced the report, and the manager was pleased (though he didn’t show it, of course–it was “just an expected part of the job” in this blaming culture).

A month later, other people tried to use this module and discovered that it was not finished after all. The developer had used a word-processor to produce a fake report that looked just like a correct test report should look. He thought this would buy him time (it was a month, after all,until anybody found out) to finish the module. Unfortunately, since he was in over his head, a month wasn’t enough time.

The manager blamed the programmer. The programmer said nothing, because in this culture of blame, saying something only brought further streams of blame down on your head. The person who reported this incident said that in this organization, failure is not allowed under any circumstances. People who have problems in a project and can foresee slippage are unable to cry HELP! and receive appropriate assistance. According to the managers, each programmer is responsible for meeting the deadlines that the programmer agreed to. Inaccurate estimation is “not allowed” and perfection is to be achieved from day one–otherwise you are put in the pillory of blame. In this situation, fake test reports are the rule, not the exception.

Blaming is the dark secret underlying the failure of many projects. A blaming culture hurts a project in at least six major ways:

1. People commit to plans they know they cannot achieve, at least to delay blame.
2. People hide facts that managers need to control the project, as in the above example.
3. When problems are finally revealed, people avoid coming forth with creative solution ideas, for fear they will be blamed if the ideas don’t work, or simply appear dumb at first glance.
4. In day-to-day operations, a major portion of everyone’s effort is devoted to positioning themselves so they will not be accused when the time of reckoning arrives.
5. Those people who somehow feel safe enough to focus on the job at hand find themselves spending large amounts of time checking up on the reliability of others’ communications.
6. People feel bad most of the time, and spend a lot of time fiddling with unproductive tasks or simply staring at the walls.

What Incongruence Looks and Feels Like

Organizations can be changed from a culture of blame to a culture of congruence. To make this change, the first step is measurement, or at least detection–but how to measure blaming? Actually, an experienced consultant can detect a blaming organization within a few minutes of contact, because symptoms are everywhere. Indeed, people within the organization already know it’s a blaming culture-but of course within a blaming culture, blame is undiscussable, and moreover, the undiscussability is also undiscussable.⁴ Paradoxically, the existence of undiscussability makes blaming easy to detect. The manager of one project issued a memo saying that there would be no more discussion of project morale, and that he would entertain no questions on the subject because everyone should be grateful to be working on such a terrific project. This could happen only in a blaming organization.

Executives

A culture of blame usually starts at the top. Members of the top level of management are inclined to see the other people in the organizatation as the source of all problems. The employees are seen as “ungrateful” for the jobs, pay, benefits, and opportunities management has bestowed on them. They are seen to “lack an appropriate work ethic,” “not know the value of a dollar,” “have authority problems,” and “resist change.” These perceptions leave upper management in a predicament: “Do I fire them, or do I fire the people who hired them?”

Such managers feel that they are trying to realize a vision without getting the necessary support, which leaves them out on a limb. The internal kinesthetic experience of these executives is normally a dull and chronic headache-unless the profit margin is really down. In that case, they have more acute feelings, like pain in the chest and burning in the gut. Their low self esteem reflects outwardly in the form of frequent downsizing, re-engineering, avoiding serious problems, futile memos, and, of course, humiliating of subordinates. Towards themselves, they often practice addictive and self-destructive behaviors (which cannot be discussed, but are alway the subject of gossip).

Middle Management

When the top leadership is incongruent, middle managers constantly receive mixed messages. Project managers are told of their importance, then find that their seniors have bypassed them to intervene directly in projects or change the rules without consulting them. They feel as if they are living on a roller coaster–unable to predict whether a particular day or week will be an upper or downer. After being publicly humiliated a few times, they decide their best strategy is to try to stay out of trouble by not ever rocking the boat. Even though they cannot perform at their best, they try to appear important and extremely useful.

In the blaming organization, top managers try (perhaps unconsciously) to teach their middle managers their own blaming attitudes. When one project manager complained of her inability to get the developers to work faster, the Vice-President of Development said, “If your dog won’t jump high enough, get a bigger stick to beat it with.” Living in hail of such incongruence from above, middle managers’ survival issues stay close to the surface. As they did when they were children, they figure out how to either appease, please, or avoid the power owners. By so doing they insure their survival–and pass the blame on to lower levels.

Employees

At the bottom rung of a blaming organization, employees are usually looking for someplace else to work unless the company is in a stable condition with little competition-or if their retirement is within view. The way to survive is to hide out and appear only to pick up a regular pay check.

Employees are discouraged from thinking creatively–new ideas are interpreted as blaming the management or attempting to usurp their power and prerogatives. Employees are not rewarded for industriousness–but they are frequently punished for perceived “laziness.” Employees cannot seem to find their managers–except when there are problems. Then, the major efforts are directed as attaching blame rather than solving the problem at hand.

The style of blaming varies from organization to organization. It can be harsh, vindictive, direct or indirect–but it is always contagious. Some organizations have polished their blaming style to a high degree of subtlety–without raised voices, merely by a look, or a memo, or an e-mail message, or a phone call, or a visit if things are really bad. In other organizations, the blame is loud, angry, and frequently done in front of an audience of peers–ensuring that all get the message of who is right, who is good, who is in charge, and who should become invisible.

In such an environment, defensiveness becomes pervasive. To those without formal power and authority, it seems that those with power really don’t care about them–and would banish them with no feeling at all. Thus they feel justified in retaliating (in advance, and in secret), and in avoiding their managers and their problems.

Regardless of the style, blaming from the top always generates fear, malaise, errors, accidents, and passive-aggressive responses from the bottom. Those on the bottom feel small and act from a place of powerlessness. The lack of emotional safety effectively erodes the trust level and makes any attempt at congruence extremely risky. This envirorunent sounds awful and it is–both for the person who has regressed into emotional immaturity and, sadly, for the person at the top who is doing the blaming.

Those on the bottom of any large organization can easily come to feel a sense of dependency on those above them in the hierarchy. When blaming is the primary mode of dealing with people, this dependency is exacerbated. Then, out of a feeling of dependency, people easily generate a feeling of hostility. As this hostility grows so does the debilitating experience of shame–that overly critical judge that lies latent in all humans.

What Congruence Would Look/Feel Like

Most people who have experienced a congruent organization won’t tolerate the misery of working in a blaming organization. But many people haven’t ever had that experience, and have a hard time believing what a congruent organization is really like. Let’s look at what would happen if a healthy dose of congruence could be magically applied on a large scale to an incongruent project organization.

Executives

If we could magically install congruence in the internal programs of those blaming executives, their style would shift dramatically. For example, if they would truly consider the others involved in their communication, they would be more likely to believe in the intent of people to contribute, to be productive, to belong, and to learn–and would take deviations from this ideal as evidence of ineffective management. Their belief in the inherent value of all people along with a healthy respect for the constraints of the work context would engender energy, hope, appreciation, understanding, and gratitude among their employees.

An executive who truly does not believe in the good intentions of the employees will be likely to say, ‘No excuses! You will get this done on October First.” But, with employees whose intentions are bad, this style (or any other style) isn’t really going to work.

A congruent executive who truly does believe in the good intentions of the employees will be likely to say, “We need this badly by October First. What do you need from us to help get it?” This kind of mutuality and support enlivens a genuine “can do” feeling that increases the chance that a project meets its goals–and that nobody has to make false promises to escape abusive blaming.

When the top level managers sustain their commitment to congruence, they see that most workers appreciate the opportunity the business provides them in developing skills, meaning, relationships, and monetary rewards. They also know how to cope when the occasional worker doesn’t seem appreciative or even productive. Managers who know how to use their power congruently generally get the results they seek–not perfection, which they know not to expect.

These leaders know they have a special kind of power–power they use with awareness and sensitivity. They do not resist accountability to those they lead, but demonstrate the same level of integrity they seek from others. And if they cannot match the levels of commitment they request from others, they are open about that. They know they are sometimes going to be weak and vulnerable and need support–perhaps even to see the value of their own visions. They use their awareness of this human reality to nurture their capacity to empathize and to have compassion for themselves and others.

Congruent executives know that their principal job is developing their organization’s capability, not just pushing the same old shoddy products and services out the door. They involve themselves seriously in organizational improvement efforts while simultaneously involving others in the organization to ground these efforts in real-life, practical operational input and decision making. They know that synergy is needed for organizational development, and they know that synergy comes from high quality connections among people–regardless of level.

Middle Management

When the top folks begin to operate from congruence, the middle managers receive direct, clear messages–not mixed messages with double meanings. Communications are more open, making it is easier to know more about what’s really going on. Given higher quality information, they know more about how to be useful, so they can more easily join their leaders in their visions. Knowing more clearly the strategic directions desired and feeling that they count in this process frees them to contribute more generously and thoughtfully–rather than merely playing safe. Success becomes a goal that all can share.

Given their unique vantage points, middle people have useful input to assist in predicting problems, projecting realistic time lines, and forecasting trends. What they see, hear, think and feel is valued, and they are in a position to initiate behaviors that prevent project weaknesses from growing into project failure. They know the necessity of interdependence, so if major problems do develop, they can be counted on to provide–and seek-truthful information. They are not ashamed or afraid to work for those who employ them. Indeed, they have pride about their commitment to the organization–and know it is a commitment not so much as to schedules and budgets, but to the truth about schedules and budgets.

Because congruence at the top trickles down, middle managers take notice of the difference in their leaders. They respond to the modeling by passing it on to their constituencies. Everyone in the organization knows what is at stake in doing each job well, so everyone feels safe to tell what is wrong, what is getting in the way, and what is needed to fix it. Honest reporting of facts and feelings is genuinely appreciated, and do not put people at risk of being humiliated or losing their jobs. That’s why congruent organizations deliver their projects as promised.

Congruent middle managers encourage high quality communication. Their belief in people’s ability to learn and change towards more congruence make those around them responsive. With congruence radiating from the center of the organization, everyone can have a place, position, and function of importance and value–so things get done, and done right.

Employees

Working at the front line of a business where the top leadership is congruent, is entirely a different experience from working in a blaming organization. Commitment and energy are the norm, not the exception practiced by new employees until they “learn the way things are around here.”

Congruent organizations hold to an ideology that doing well in the marketplace is connected to doing well with employees as well as with customers. The perspective of the leadership includes a global consciousness about the existence of multiple non-linear factors, the importance of connections among all the various parts of the whole, and the necessity of all parts knowing their value. Workers feel that this is a company going somewhere, where growth is a natural state and everyones’ efforts count.

Workers in a congruent organization tend to have a long range view and can usually maneuver as needed to meet the changing needs of clients and customers. Employees trust that what they see and hear is real. They share in the enthusiasm of creating a future. They may not like everything that happens–for instance, they don’t always feel that they are rewarded adequately for what they give–but they don’t feel that there is a chronic pattern of undercutting, diminishing, discrediting, and devaluing them and what they do. They can risk congruence knowing that it will act as a catalyst for optimizing successful outcomes that benefit everyone.

Congruence is the bright secret underlying the success of many projects. A congruent culture helps a project in at least six major ways:

1. People commit to plans they know only after open negotiation, so plans are more likely to be realistic in the first place.
2. People come forth readily with facts that managers need to control the project, as soon as they are known, so managers can act early and act small to correct the problems.
3. When problems are revealed, people readily come forth with creative solution ideas, increasing the chances for quick and effective solutions.
4. A major portion of everyone’s effort is devoted to getting their jobs done, and helping other get their jobs done.
5. Because human fallibility is considered normal, an appropriate–but small–amount of time is spent assuring the reliability of communications.
6. People feel good most of the time, and thus are productive most of the time.

Congruence in Large Systems Development Efforts

In the course of developing systems, people engage in numerous acts of communication–about requirements, schedules, interpersonal problems, designs, progress, and just about anything else. That’s why effective individual communication is important in all projects, large and small. That being said, effective communication becomes even more important as the size of the development effort grows. The number of necessary communications goes up non-linearly with the size of the project, so the effect of imperfect communication style is magnified. Thus, if the quality of individual communications remains fixed while the project grows, the overall quality of communication will go down.

For instance, a certain level of congruent communication might be adequate for a producing a product with 25,000 lines of code, yet be totally unacceptable for a product with 2,500,000 lines of code. In order to develop larger and/or more complex systems, then, it’s not sufficient to pay attention to technical issues–accepting that the existing communication style will be adequate. Managers must also improve the project’s communication culture, and thus they must pay more attention to congruence.

To make matters worse, unless we manage well, tougher projects tend to dimish congruence–because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.⁵

Congruence, of course, is but one of the factors in effective communication–other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

Achieving Congruence

When Deming said, “Drive fear out of the workplace,” we think he was talking about changing the blaming organization to the congruent organization. This kind of change is made by one person at a time–hopefully starting at the top–and one step at a time. The steps can be broken down into six ‘A’s’, as follows: Awareness, Acceptance, Authorship, Articulation, Application, Activism. Let’s look at how each of these steps takes place in the context of an individual trying to change a blaming organization.

Awareness

Awareness says, “This is happening. This is real.” Awareness comes from experience, when I allow myself to experience the world around me as it is–not as it is supposed to be, or I wish it to be, or someone else tells me they want it to be.

Awareness is always the first step, and probably the hardest, because generally we’re not aware that we’re not aware. Here’s a personal example of how lack of awareness stops the change process before it can even start:

Jerry was attending a project meeting in a software company–a meeting called by the company President to find out what was going on in a late project, After some coaxing, one of the developers said that she was afraid to go to Nat, the Development Manager, with problems, because of the reception she got. Nat got red in the face, stood up, and shouted angrily, “How can you say that? My door is always open to hear your problems! The only thing I won’t tolerate is if you’re all emotional when you come, or if you don’t have a proposed solution!”

In the calmest voice he could manage (it’s hard to stay calm when someone is being so angry, even if it’s not directed at you), Jerry turned to the President and asked if Nat ever came to him with problems. When the President said yes, Jerry asked if the Nat was always calm and carrying a proposed solution. Before the President could answer, Nat interrupted: ‘Why would I come with a problem if it wasn’t important enough to get excited about? And, if I had a solution, why would I come to him?”

Although it was now clear to everyone else in the room that Nat was demanding that others “do as I say, not as I do,’ he was unable to see the incongruence. Lacking awareness, there was no way Nat was going to change–and indeed he never did change, up to the time the President released him to seek greener pastures.

Nat’s case is quite typical. Since incongruence is a defense, incongruent people erect all kinds of shields that close off information about congruence. Their own incongruence, and that of others, is invisible–it is accepted, especially if it is the norm in the organization. This invisibility makes it very hard to reach them with any kind of information on the subject.

In other words, when you’re being incongruent, you’re losing your ability to take in what’s going on in the world (inner or outer). So, you don’t know that you need changing. And, even if you did, you haven’t a clue what to change to. No wonder it is so difficult to transform an incongruent culture, when the very first step–awareness–is so hard to come by.

Awareness comes from experience, when you allow yourself to experience the world around you as it is–not as it is supposed to be, or you wish it to be, or someone else tells you they want it to be. But in the blaming organization, where people shield themselves from experience, becoming aware usually requires help. Helping others become aware takes the skill to develop safe environments and to build relationships. It takes the patience and caring to watch for signs of awareness and help build on them. It also takes a belief and a commitment that “part of my job is to help the people on my team to develop– the most important part.” If you don’t believe this, then certainly don’t try to help people become aware. Otherwise, you’ll find yourself saying, “You aren’t aware of what a lousy employee you are, but I’m going to make you be aware!”

But awareness of the overall situation is not sufficient–you also need self-awareness. Self-awareness says, “This is me. This is mine.” You may be fully aware of the blaming, but as long as you merely say, “This is a blaming organization,” you’re not doing anything to change it. When you say, “I am a part of this blaming organization,’ you move forward. You own the blaming as a part of yourself and your behavior–not just something that “they” do (to you).

Self-awareness is often followed by depression or shame or guilt. Some people react with anger, at themselves or at any convenient target. Yet Self-awareness is empowering–the thought that since I own it, it’s mine to do something with.

Acceptance

Acceptance moves the change process beyond self-blaming and says, “I’m not a bad person because I do this. My intentions are good, though my actions may not be effective.” Acceptance means that you understand that taking responsibility is not the same as blaming yourself. Thus, you have mercy on yourself and your all-too-human imperfection. You stop being angry. You forgive yourself for not doing better in the past, based on your present understanding and standards. And, as you forgive and accept yourself, you gain compassion for the others involved–thereby increasing the chance that you can communicate with them and effect change.

At the point when you’re trying to reach acceptance, it’s critical that you not be punished or humiliated by someone else. You need a little help in getting off your own back, or else you think so little of yourself that you couldn’t possibly do anything about the situation. Of course, in a blaming organization, you may have a hard time avoiding this kind of punishment, which is why authorship and acceptance are usually done internally, and kept internal for some time.

Authorship

Authorship is the first decision point, when you say, “I have choices. I can do something about this.” With some encouragement, you accept that you are responsible for choice in your life. You understand that you don’t have to react, but that you can chose your response–that you create, in large part, your own interpersonal context. You know there are some parts of the context that you can control and some that you can’t; and you know accurately which is which.

Articulation

Articulation is the public commitment to change, and says, “I’m going public with this (for accountability and support).” Articulation is ineffective if attempted before the prerequisites are in place. If you can’t accept yourself or how you have reflected yourself out to the world, or if you don’t know that you have choices or feel you can gain support for those choices, then speaking out is merely ineffective bravado.

But, when the prerequisites are in place, you cannot be effective by keeping silent–you must decide to speak out. In the process of speaking you transform your inner awareness to another kind of experience. You hear yourself and you notice the response you get from others. You make public, if you will, your self–your mental and emotional position.

Initially, of course, you must seek out safe places to disclose your truer and more honest expressions of your thoughts and feelings. When you become more grounded in the power of your true self then you can seek the kind of support that challenges and confronts you, as opposed to the kind of support that coddles and consoles.

Initial steps of articulating congruence are often awkward. That’s why a responsive and receptive listener satisfies one of the requirements for promoting the development of congruence.

Application

Application says, ‘These are my choices (my new ways of coping).” You learn to be congruent yourself, first in your most immediate, safe, and encouraging context. Then you expand the contexts in which you can respond congruently. Don’t try to “not be incongruent.” This paradoxical command only invokes the incongruence of perfectionism. (”If I can’t be perfectly congruent all the time, I’m worthless.”) Focus on congruence, practice congruence, and the incongruence “muscles” will simply atrophy.

With support and practice you can begin to use and test out congruence in your immediate relationships. We suggest that you continue to design for success, so that initially these tests of your new skill are done within environments where you will more likely be given the benefit of the doubt. As you experience success, then you can be centered even in more turbulent and conflicted arenas. In other words, once you “get the call,” don’t march into the president’s office and announce that henceforth, all the guilty parties must stop blaming, or else.

Activism

Activism says, “Now that I can make a difference in myself and my most familiar world, I’m going to help spread this throughout the organization.” Activism is applied leadership, starting at the point at which you have enough competence at being congruent to reach out and be proactive–anticipating, initiating, instigating–but not inflicting. You cannot operate from an incongruent position and force other people to be congruent. (”I have to blame them, because they’re so blaming. Once they change, then I’ll be able to change.”)

In any case, you don’t have to inflict congruence on anyone. Congruence is contagious–when directed consciously to creating a safe, nurturing, productive environment. It may spread more slowly than you’d like, but once it starts moving, it’s hard to stop.

Notes:

1. For more on how blaming and other incongruent styles impact software work, see Weinberg, G. M. (1994). Quality Software Management: Congruent Action. New York: Dorset House.
2. For more on incongruence and verbal patterns, see Hardin, S. E. (1989). Success with the Gentle Art of Verbal Self-Defense. Englewood Cliffs, NJ: Prentice-Hall.
3. Brooks, F.P. (1982). The Mythical Man-Month. Reading, MA:Addison-Wesley.
4. For more on undiscussability, see Argyris, C. (1993). Knowledge for action: a guide to overcoming barriers to organizational change. San Francisco: Jossey-Bass.
5. for more on such system dynamics of projects, see, for example:
   Senge, P. M. (1990). The Fifth Discipline: The Art & Practice of the Learning Organization. New Turk: Doubleday.
   Weinberg, G. M. (1975). An Introduction to General Systems Thinking. New York: Wiley-Interscience.
   Weinberg, C. M. (1991). Quality Software Management: Systems Thinking. New York: Dorset House.

convert this post to pdf.

The introduction of the new $20 bill has me thinking about the Bureau of Printing and Engraving today. They’re one client I ever had who couldn?t use the slow-payment excuse that they’re short of cash, since they print the stuff. One of the most irksome parts of being an independent contractor is the client who doesn’t pay, or at least seems like they won’t pay in time for you to pay your own bills.

First of all, this is not a new problem, so it’s important not to take it personally. Taking it personally only gets you annoyed and out of your best thinking mode. True, some clients believe that contractors don’t need to think creatively: “Just keep your ideas to yourself and get back to coding,” they say, but they’re wrong. Creative thinking is your best ally when it comes to getting your fair share of the cash.

There are, of course, traditional ways of enticing your clients to pay you on time. My father was in the auto painting business, and I recall how careful he was to pay his paint bills on time in order to earn his “2% discount for payment in less than 30 days.” Knowing that this discount strategy worked well to motivate my father, I once tried it on a slow-paying client.

This multi-billion-dollar company had typically taken 4-5 months to pay my tiny bills. I started adding that “2% discount” clause to my bills, and sure enough, it motivated them to change their behavior. They still paid in 4-5 months, but they now deducted 2% from every bill.

I learned several lessons from this experience. The first lesson is that large clients have payment patterns that no rinky-dink contractor is going to change. I call this Gilb’s Law, because I once asked Tom Gilb about a recruiting firm in Europe that wanted me to do some work with them. I’d had some trouble getting payments overseas, so I asked him about their payment practices. “Oh,” he said, “they always pay. Eventually.”

In short, their consistent pattern was reliable, but slow. The second thing I learned was that I can use the client’s consistency to my advantage. Knowing that they typically paid 6 months late, I inflated my normal billing rate by an amount equal to 6 months of interest on that rate. If they wanted to compete with my bank for my CDs, that was fine with me (but I did add a tiny bit more because they didn’t offer Federal Deposit Insurance).

This strategy has worked well for me ever since. The most important part is that I no longer get annoyed with my clients for playing financial games with my money. It’s never a good idea to get annoyed with your clients, so it’s never a good idea for someone like me to feel that I’m a victim of my client’s lack of adaptability. After all, if I’d wanted to be a helpless victim of a large corporation, I could have been their employee?and gotten health insurance to pay for my psychiatric bills.

A few clients actually understand their own slow-pay patterns and have worked out solutions that I have adopted as my own. (As Tom Lehrer says, “if you steal from one person, it’s plagiarism; if you steal from many, it’s research.”) I gave a short course once at a large government agency, and I was picked up at Washington National airport by Chuck, my contact at the agency. As we drove to the agency, Chuck asked if I was in a hurry to get paid. “How much of a hurry?” I asked. (That’s another good consulting technique?answer difficult questions with other questions.)

“Well,” he answered, “we seem to have a difficult time processing this kind of payment in less than eight months.”

“In that case,” I said, “I’m in a hurry.”

“I thought you might be,” said Chuck. “But don’t worry, we can pay you in cash.”

This wasn’t the Bureau of Printing and Engraving, so I was rather surprised that they could actually do cash business. I told Chuck of my doubts, but he reassured me. “In fact,” he said, “we’ll get you paid in advance, just in case there’s any hangup.”

And, sure enough, when we arrived at the agency, he took me directly to a barred window marked “Cashier.” The little guy behind the window lacked a green eyeshade, but otherwise looked just like the teller in a bank about to be robbed in a Clint Eastwood Western. He didn’t even blink when Chuck slipped him a hand-written voucher for $2,500. He asked me for some identification, then a signature, after which he counted 25 hundred-dollar bills into my hand. I was then led to the classroom where I gave a stunning class, never once being distracted by worries that I might not be paid.

I’ve now added “cash in advance” to my repertoire of payment possibilities. It’s especially useful in cases of doubt or complication, such as working overseas. There can be drawbacks?every solution creates new problems, as every consultant knows. Once, after an extended tour of Japan, my sponsor had me in for a tea ceremony, during which he handed me an envelope wrapped with a red ribbon and containing, I presumed, my fee for the visit?in cash, as our contract had stipulated. I thought it would be discourteous to count it in front of him, but as I was about to slip it into my inside pocket, my translator suggested it would be rude not to count it.

Knowing that cultures differ, I opened the envelope and counted over $10,000 in crisp new American money. The amount was correct, but counting it raised my anxiety about carrying so much cash. I wanted to take it to a bank and convert it to some sort of non-negotiable instrument, but I was told, regretfully, that it was “Honor Old People Day,” so the banks were closed. That night, I slept with the money under my pillow (and not too well).

The next morning I had to leave for the airport before the banks opened, so I had to carry the cash with me all the way home. I learned, also, that when you carry more than $10,000 cash into the USA, you have to have a friendly discussion with the customs agents?a discussion in which you must convince them that you’re neither a counterfeiter nor a drug dealer. I also discovered that it wasn’t even that easy to deposit that much cash in my own bank?once again, lots of rather personal questions.

In other words, cash has some disadvantages of its own, in addition to the disadvantages of money in general. Disadvantages of money? Yes, life is never as simple as we contractors think it should be. Indeed, the worst accounts receivable situation I have had to solve?the one that took all my creativity and more?was when, Lily Gilding Limited (LGL), one of my best clients paid the same bill twice .

The bill was $4,240. (It would have been $4,000, but I had added the interest for their 4-month pay cycle.) The first check arrived right on schedule?that is, four months late. Unfortunately, even before I had time to spend all of it, a second check arrived?same invoice number, same amount, same date.

LGL was a good client, so it wouldn’t have been good business to try to pretend that we didn’t get the second check. We called their Accounts Payable Department right away to tell them of their double payment, but they said, “No, you must have made a mistake. We couldn’t possibly have paid you twice. We have controls . You’d better have the manager of your Accounts Receivable Department check your records.”

I smiled, thinking of how Lois would feel being called the “manager of the Accounts Receivable Department,” but I kept my mouth shut. A/P departments can only talk to A/R departments, not to the do-everything-person-named-Lois in a small consulting firm. Lois checked everything again, and I double-checked Lois’s records. Same result. LGL had definitely paid twice.

After about twenty calls back and forth, I became convinced that LGL could never admit to such a mistake. I then brought the matter to the attention of my contact person, Nel, and she made a few phone calls on my behalf. Next time I was consulting at LGL, Nel told me, “I’ve tried everything I can think of. My advice to you is just to keep the money.”

“But I can’t do that,” I protested. Mostly I was thinking that LGL might someday discover their error and think I was dishonest. It’s always harder take being thought of as dishonest when you really are dishonest.

“No, really,” Nel said. “Even if you could finally get us to take it back, it would cost us more than $4,240 to get it cleared up. Believe me, this is the best solution for both of us.”

Well, she was right, of course, but Lois is one of those honest Nebraska farm women who simply couldn’t keep money that didn’t belong to her. She simply wouldn’t accept any solution that involved us keeping their money, so I turned the problem over to her?having exhausted my own creativity. And, as usually happens when I have the courage to admit I can’t solve a problem, Lois found a way.

Her solution may not always work for you, but since LGL was a good client, Lois simply deducted $4,240 from the next bill she sent them and called it a rebate. Apparently they were happy to receive a “rebate,” and we never heard another word from them. Another accounts receivable problem solved, and another happy client!

What?s the moral of all this? It reminds me that when you?re in business for yourself, your problems never end, and even that wonderful event – getting paid – can be one of your worst problems.

convert this post to pdf.

(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.

Participants

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.

Penalties

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

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.

Conclusion

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

convert this post to pdf.

[Note: In September, 2000, at the SEI's Software Engineering Symposium in Washington D. C., Jerry was the recipient of the 2000 Stevens Award. The award recipient is recognized for outstanding contributions to the literature or practice of methods for software development. In receiving the award, Jerry gave the Stevens Lecture on Software Development Methods, the purpose of which is to advance the state of software development methods and enhance their continuing evolution. The following column is abstracted from part of his Stevens Lecture. ]

I remember one summer day during World War II when my father, Harry, and I were discussing the water restrictions that had been imposed because of drought conditions. I was worried that we might run out of water, and my father said, “Yes, it could happen that we run out of water. Lots of things can run out – water, sugar, meat, gasoline, bread, even air. But there’s one thing that will never run out.”

“What’s that?” I asked, looking for reassurance.

“Reasons,” he said. “People will never run out of reasons.”

Harry was the first change artist I knew. At that time, he was working for Sears, starting up new stores and installing new procedures in existing stores. He often took me on trips, and I got to see him working. I particularly recall the difficulty he had teaching salespeople about Sears’ policy on returned tools and paint.

The policy was simple: The customer was always right, so just replace anything that they didn’t like, no questions asked. If possible, find out what they didn’t like about it, but never, never question their right to a replacement. I’d watched him coach salespeople through a number of these transactions, so I thought I understood what he mean by never running out of reasons. Even though the policy was clear – replacement with no questions asked – the customers always had elaborate stories of why the item wasn’t satisfactory.

But only later did I realize that it wasn’t just the customers he was talking about. He was also talking about the salespeople, who never ceased to have reasons why they couldn’t or shouldn’t apply the policy in each particular case.

Recently, I found myself recalling that summer day, half-a-century ago, when a client asked me to find out why their Software Engineering Process Group was having so much trouble getting people to adopt new software tools. It couldn’t be the tools themselves, they reasoned, because quite a few people had adopted them and liked them. So, I set out to interview both adopters and rejecters, to discover the reasons some were using the tools and some were not. Here are some of the answers I obtained:

Darlene: I installed it because the boss told me to use it.

Porter: The boss told me to use it, so I didn’t use it.

Ursula: I installed it because the boss forced me to use it.

Marcy: The boss forced me to use it, so I installed it, but I don’t use it. He wouldn’t know the difference.

Quentin: I used it because it was like what I used before, so I knew I wouldn’t have any trouble adapting to it.

Chuck: Why should I use it? It’s nothing new; it’s just like what I used before.

Carl: Hey, I used it right away, because it was new and different.

Cynthia: I’m not going to use anything that’s new and different. Too many things aren’t tested, and something’s sure to go wrong.

Mary: Of course I used it. Everyone else was using it.

Roy: Everyone else was using it – what a bore! You won’t catch me following the crowd.

Frances: Why should I use it? Nobody else was.

Edgar: Hey, I got to be the first one to use it!

Mort: I couldn’t use it. It didn’t do all the things I needed.

Alan: The thing I liked best about this tool was that it didn’t try to be a Swiss army knife and do everything anyone could possibly want.

Gerri: It was the perfect tool, because it had every feature I could possibly want.

Chico: Every time I hit a key by accident, it would invoke some obscure feature that I didn’t want in there in the first place. Finally, I trashed the whole thing.

Orion: I’m so busy, I needed a new tool to save me some time.

Belle: I’m so busy, I don’t have time to install and learn a new tool.

May: I’m not that heavily loaded. Why would I need a time-saving tool?

Paul: Well, I wasn’t so busy with other things, so I had time to install and learn a new tool.

Earl: It was freeware, so it was a bargain.

Justine: It was shareware, so it couldn’t have been any good.

Jacob: This tool costs $3,000. It must be good, so I’m using it.

Neelie: I’m saving the company $3,000 by not using it.

Willis: I won’t use it because I don’t like the way Microsoft makes software.

Samuel: I knew it would be good because Microsoft makes it.

—–

Well, there were more, many more, but that’s enough of the infinite reasons to make my point. By this time, you may have noticed that I have arranged these reasons in pairs. Why? So you could see the pattern that I saw:

Every single reason to use the tool was matched by the same reason for not using it – and vice versa!

In other words, these reasons may look like logic, but they’re not logic – they’re just reasons. In logic, the reasoning comes first, then comes the decision. But in real life, it’s usually the other way around – first we make the decision, then we make up whatever reasons we need to “justify” the decision and make it look like logic.

And why would we go to all this trouble? Somewhere along the line, we’ve learned that emotional reasons aren’t good enough, so we have to fool people into thinking we’re more rational than we really are – so they’ll leave us alone to do what we intend to do in the first place.

I recently read about a fascinating psychological experiment conducted in a large office at the high-speed copier. When there was a line of people waiting to use the copier, an experimenter would walk up with a handful of papers to copy and try to butt into the front of the line.

In one set of trials, the experimenter would say, simply, “I want to copy these.” People were indignant, and refused to let him get in front of them.

In a second set of trials, the experimenter would say, “I want to copy these because my boss needs them.” People then willingly let him go right to the front of the line. In other words, if the experimenter had a good reason, then people were willing to let him go first, even if meant they had to wait longer.

But the fascinating phenomenon was in the third set of trials, where the experimenter would say, “I want to copy these because I need to copy them.” And guess what? The people let him go to the front, just as they had done when he had a “good reason,” even though this “reason” was totally vacuous. In repeated trials, the experimenters discovered that any “reason” would work, as long as they used the form, “I want to copy these because X.”

We seem to be conditioned to respond to this kind of pseudo-logic, and we instinctively know how to use it. Imagine telling your boss, “No, I’m not going to use this tool.” You know that the next thing you’re going to hear is “Why not?” So, you’re never dumb enough to “just say no,” but, instead, you’re going to say, “No, I’m not going to use this tool because X,” where you supply the X from the list above or from your own favorites. You might get an argument, but half the time the conversation will simply end there. And, if the boss does continue, you’ll then supply reason Y, then Z, then A, B, C, and D, until she gets tired of the game and quits.

But I’m not telling you all this so you can beat your boss in The Big Game of who gets to tell who what to do. I’m telling you because one of these days – perhaps today – you’re going to be on the other side of the equation. You’re going to be the change artist trying to introduce something new – a tool, a process, a document, a technique, anything new at all. And when you try, you’re going to find yourself faced with an infinitely high wall piled with reasons, mortared in place with that word, “because.” [Or "so," or other forms of pseudo-logic.]

And what will you do then? Rather than go back and forth with a potentially infinite chain of “why-because,” save yourself some time and energy by recognizing that you will always lose this game, so switch to another. One of these new games is to try to convert to real logic.

When you get the first “because,” simply say, “You’re right. There are lots and lots of reasons why you might not want to do it this way, and you’re exactly right to start raising them. Let’s carry this through.”

Then you take out a sheet of paper and draw a line down the middle. On the left, you label the column “Reasons Why Not.” On the right, “Reasons Why.” Then you write their reason in the left column and ask for one in the right column. If they can’t come up with one, prime the pump by showing how their own reason could just as well go on the right.

Continue filling out the columns until you have 6 or 8 or 10 reasons on each side, then say, “Okay, now let’s consider what’s the real problem here.” And off you go, possibly getting into real logic for a change.

A second approach is to short-circuit the game right at the beginning. When they start listing “why-not” reasons, you interrupt and say, “You’re right. Not everybody is right for this tool. Since you don’t have the right qualifications, I’ll go look for someone else.”

Sometimes, they’ll let you go – and then at least you’re saving time. But sometimes, they’ll stop you and start giving reasons why they are, indeed, the right people for this tool. And you can be sure they’ll have an infinite number of them.

convert this post to pdf.

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:

Aaron:

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

Bonnie:

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

Carter:

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

Darlene:

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:

Aaron:

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

Me:

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?

——————————————————————————–

Bonnie:

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

Me:

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

——————————————————————————-

Carter:

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

Me:

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.

——————————————————————————–

Darlene:

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.

Me:

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.

convert this post to pdf.

This morning’s news brings a story of a small manufacturer of add-on
hardware suing large computer manufacturers for alleged illegal price-cutting.
I was surprised. I thought the lawyers had finally learned the futility of suing
hardware makers over pricing.

Ordinarily, I have an aversion to lawsuits, and even to news about
lawsuits, but my surprise told me I might learn something if I looked further
into this one. It seems that the company’s sale of add-ons had fallen by some
thirty percent in one year. Stockholders usually want explanation when sales
drop even by a factor of one percent, so management looked around and
discovered that the big guys had dropped their prices on similar add-ons, just
around the time sales began to fall.

My older sister, Charlotte, is a lawyer. Charlotte’s always bragging that
law school is great training in logic.
She taught me the logical fallacy that goes by the Latin name,
post hoc ergo propter hoc, which in English means “after
this, therefore because of this”. The fallacy lies in thinking that because one
thing comes after another, the first thing is the cause of the second. Because
manufactuers dropped their add-on prices, the plaintiff’s lawyers reasoned, its
own sales fell.

The courts will decide whether the company’s post is truly the
manufacturers’ propter, but obviously there is another explanation. Anyone
who has studied the history of hardware prices knows that once a particular
line starts losing value, it drops incredibly fast-along with any add-ons.

So it could be that the company was the victim of its own belief that it
could continue making profits with an obsolete technology. If so, they
wouldn’t be the first to make that mistake in reasoning.

I never went to law school, but this fallacy is so common among high tech
managers that it deserves an impressive Latin sounding name. Forgive me, but
let’s call it bonus antequam, ergo bonum postquam”: it was good before, so it
must continue to be good.” Or, if you prefer Street English to Fractured Latin,
“Shut up and keep rowing!”

The high tech business has great appeal for people who would like to
make a lot of money. One good idea can make you as rich as Midas-but a
second good idea can transfer the golden touch to someone else and put you in
the poorhouse. It is no business for cowards. As soon as you lose your nerve,
you stop investing in new ideas. And as soon as you stop investing in new
ideas, your days are numbered.

Hardware or software, it makes no difference. Poor managers destroy the
environment that nurtures new ideas, the ideas run dry, someone with more
daring improves on your idea, and finally, sales plummet. Some managers
react by going outside to buy new technology. Better managers react by
changing the environment to get the ideas flowing again. The worst managers
call in the lawyers and sue the competition for stealing their ideas or competing
unfairly.

In a high tech market, the return on resources invested in new ideas is a
thousand times greater than a similar investment in lawsuits. Lawsuits are
tempting only when innovation is drying up-at least in the organizations that
were the early leaders.

That’s easy to see from the outside, but it doesn’t feel that way to the
insiders. When this happens to us, we feel genuinely robbed, cheated, and
betrayed. These angry feelings destroy our ability to keep innovating, so
lawsuits seem the only reasonable alternative.

I understand these angry reactions because I’ve felt that way myself when
someone had “plagiarized” my work. Sometimes entire paragraphs and even
articles have been copied word for word without a hint of credit.

When I cool down, I begin to see things differently. I’m in the ideas
business, not the lawsuit business. My big payoff comes from writing
something new, not hanging onto things that are done and gone. Sure, if the
culprits have actually copied word for word, I’ll have my secretary write a mild
letter suggesting that they must have made a clerical error in forgetting to
obtain permission and make a reference. People, who have to copy the work
of other verbatim are not much of a threat to my continued existence, so why
threaten them? (I have sued once, and won a bundle, when the plagiarizer
claimed I had plagiarized him. That behavior triggered a different kind of
anger.)

When the copy is not exact, I often write a personal letter to the copier,
noting the remarkable similarity and suggesting that our thoughts and interests
have a lot in common. This sometimes brings apologies, and sometimes starts
a long-lasting friendship with someone whose thoughts and interests do run
parallel to mine. One such friendship is worth the price of hundred old ideas-
even if they were actually stolen-and is often the source of a hundred new
ones.

But sometimes I have trouble cooling down and getting rid of my
irrational desire to sue. Lately, I’ve come to understand that this anger actually
is a symptom of something else-a strong feeling of inadequacy. Just like those
managers who fear that innovation is finished, I’m afraid that I no longer have
what it takes to turn out new ideas.

Instead of reacting by creating a batch of new ideas, I start grasping for
ways to protect the ones I’ve already produced. In short, I’ve lost my nerve.

I’m not ashamed to admit that I sometimes feel that way. When it takes
all the running you can do to stay in the same place, it’s no shame if you
sometimes feel weary of running. Every technical hotshot, at some time or
another, has to face the feeling of wanting to stop and live off past glories.

Each time that happens to me, I get frightened, and angry, and unable to
produce new ideas. Then I rest for a while, do some new things (like writing
novels) and eventually get back into the racket again.

convert this post to pdf.

Throughout my career, I’ve watched in dismay as one software manager
after another falls into the trap of achieving delivery schedules by
trimming tests. Some managers shortcut test work by skipping reviewing
and unit testing in the middle of their project. Others pressure the
testers to “test faster” at the end. And, most frequently,
they just drop planned tests altogether, hoping they “get
lucky.”

I’ve written several essays about the dangers of test trimming,
but nobody seems to understand, so I asked myself, “What am I
doing wrong?” Perhaps I wasn’t practicing what I was preaching.
Perhaps I was trimming tests myself. Perhaps my writing needed
more testing!

So, I wrote a story about taking shortcuts and read it to my
granddaughter, Camille. Here’s the story:

Rhubarb Cakes for the Queen of the Forest

Once upon a time, all of the animals in the forest were in an uproar.
Calling Crow had just proclaimed that in two hours, the Queen of the
Forest would arrive for a visit to choose a new Royal Baker.

“She’s going to hold a baking contest,” Calling Crow cawed.
“And the winner will be named Royal Baker?and win a prize of
100 pieces of gold!”

“What do we have to bake for her?” barked Burly Bear.

“Rhubarb cakes,” Calling Crow cackled.
“They’re her very favorite dessert.”

Rapid Rabbit ran nervous circles around a rhododendron bush.
“Rhubarb cakes? But the Queen is coming in just two
hours, and my recipe for rhubarb cakes takes three
hours.”

“So does mine,” complained Canny Coyote.

Burly Bear sharpened his claws on the bark of an ancient aspen.
“Mine, too.”

Prudence Porcupine popped up and headed for her kitchen.
“Then I think I’d better get started, and not just stand around
complaining?”

Each of the bakers pondered how they could make their rhubarb cake
in two hours.
“I’ve got it,” thought Rapid Rabbit.
“What takes the longest time is putting in a little sugar at a
time, stirring for five minutes, and tasting to see if it’s just right.
I don’t really have to test the sweetness a little at a time. I’ll just
throw in the right amount of sugar all at once, and that should save me
an hour.”

Burly Bear reasoned to himself,
“I have the biggest oven, so I can put the cakes on the top
shelf, in the very back where it gets super hot. And I can stoke the fire
with lots and lots of apple wood because that burns hotter than any
other wood. If I bake the cake at a higher temperature, I can save a
lot of time and have it ready when the Queen arrives.”

Canny Coyote didn’t have such a big oven, but he figured,
“if I just cut an hour off the baking time, the cake might be
a little soft, but I’ll put in lots of sugar.
The cake will be so sweet that the
Queen won’t notice.”

But Prudence Porcupine had a different way of thinking.
“I know my rhubarb cakes are delicious, but if I take any shortcuts,
I’m pretty sure the cake won’t come out right. I’ll just tell the Queen
that my cake is going to be late, but that it will be worth
waiting for.”

When the Queen arrived, Rapid and Burly and Canny all had their
cakes on display in the clearing, and the Queen was invited to taste
each cake in turn.

She took a bite of Rapid’s cake and made an ugly face.
“Yuck. This rhubarb cake is so bitter.
Why didn’t you add more sugar?”

Then she turned to Burly’s
cake and asked, “Why is this one all burned and black?
Well, maybe it’s better on the inside.”
But when she tried to cut a slice, the burnt crust was just too hard to cut.
Instantly, the Queen moved to Canny Coyote’s table
without even tasting the bear’s cake.

She tried to cut a slice of the coyote cake.
“This cake looks rather mushy.
Oh, it’s all gooey and runny when We try to cut into it.
We think it would make Us sick if We put it in Our mouth.”
(Queens always call themselves “We”
because they believe they are speaking for the entire nation.)
The Queen stuck out her tongue at the cake and refused to taste it at all.

Finally, the Queen turned to Prudence’s table and asked,
“Why is there no cake here? We distinctly said
that every baker was to make a rhubarb cake.
Who dares to refuse a Royal Proclamation?”

Prudence stepped forward, bowed to the Queen and said,
“My cake is in the oven, Your Majesty.
It will be ready for your tasting in one hour.”

“But We said the cake must be ready NOW
” shouted the Queen.
“That was a Royal Order, and cannot be disobeyed.”

Prudence bowed so low her quills caught some fallen leaves.
“Yes, Your Majesty. And I wished I could have made a rhubarb cake
in two hours. But I don’t know how to make a cake that
way that would be fit for a Queen, so I did my very best and took three
hours. If you want to punish me,
then you are the Queen and may do whatever you like.”

“Humph,” growled the Queen,
thinking of suitable punishments.

Prudence brushed away the stuck leaves.
“But the cake is in the oven now,
and you can just begin to smell how tasty it’s going to be.
In one hour, it will be fresh from the oven,
and a fit dessert for your refined tastes.
In the meantime, I’d be happy to tell you a story,
to make the time pass more quickly.”

“What story?” demanded the Queen.

“I thought I’d tell the one about the Princess and the Pea,”
Prudence offered. This delighted the Queen because that story was about her,
when she was a young princess. So the Queen listened to the story,
and laughed and cried and clapped so hard that an hour passed
by very quickly.

Then Prudence put on her mittens, opened the oven, and took out a
perfect rhubarb cake. The Queen loved it so much she ate the entire cake,
with just a small slice for Prudence. Then she gave Prudence a woven bag
with one hundred gold coins and announced to the whole forest that Prudence
Porcupine, though she was at times a little prickly,
was the Best Baker in the Forest and now would be the Queen’s Own Baker.

**********

When I was finished reading, I asked Camille what was the lesson
of the story. She said,
“Burly and Roger and Canny were not real bakers.
They were just pretending because they wanted to win the prize,
but they didn’t know how to bake a real cake.”

“Very good,” I said. “But maybe they did know,
but were afraid of the Queen.”

“If you’re afraid to do what you know is right,
then you’re not a real baker.”

Camille, who was not yet five years old, understood this story perfectly,
so it passed my test.

I wonder if forty-year-old software managers will be able
to understand it?

convert this post to pdf.