Originally published in Cutter IT Journal Vol. 14 No. 10, October 2001.
Imagine this scene. For months, you have been trying to solve a sticky problem in your organization. Finally, after much study, experiment, and thought, you have devised a solution. For this scene, any solution will do — code inspections, UML, an automated test tool, Extreme Programming — as long as it requires people to change what they are doing.
You gather your courage, call people together, and make your proposal. From your right, Charlie says, "But we tried that before, and it didn't work." To your left, Pam says, "But we've never done that before." Right in front of you, Lee says, "But that's no different form what we're doing now." From the back of the room, you hear a rising chorus of, "But we don't have time!"
You don't really have to imagine this scene, do you? You've lived it. Perhaps you're living it right now. You're getting resistance. Now what do you do?
Realities of Resistance
When I get resistance, my first step to resolving it is to remember the two realities of resistance. First is the Harsh Reality of Resistance: I cannot make another person do anything. People always decide for themselves how they will respond to my proposals, my requests, and even my demands. What's more, no matter how brilliant my ideas, people always choose their responses based on their own point of view and not on mine.
Fortunately, there is also a Hopeful Reality of Resistance. I can sometimes change a point of view — either my own or someone else's. Sometimes I can influence a person to accept my point of view and to do what I ask. Sometimes I learn something new, adopt the other person's point of view, and drop my request. Sometimes, as I work to understand the other person, the two of us end up at a third point of view, different from where either of us started, and we both change in ways we hadn't expected. In each case, the resistance has vanished.
Every Response is a Resource
If you want to resolve resistance, you must build mutually compatible points of view with the people who are not doing what you ask. You might attempt this by redoubling your effort to persuade, by trying to explain your viewpoint so clearly, so brilliantly, and so convincingly that the other person is won over. Unfortunately, there are problems with this method. One is that it requires you to know what information the person would find clear, brilliant, and convincing. Another is that people are not always open to being convinced.
A more reliable method — the key to resolving resistance — is to become curious. Before trying to convince someone, learn at least one more thing about the person's point of view. A great way to learn is to explore people's responses — especially the responses that strike you as resistance. Every response carries valuable information, clues about the person, about the environment around you, about your request, or about yourself. Treat each response as a precious resource.
I have asked hundreds of people about their reasons for doing or not doing something that another person had asked them to do. From their answers, I have identified four broad factors that affect how people decide whether or not to do what another person asks:
- expectations about the request
- communication about the request
- the relationship with the person making the request
- influences from the environment
Let's explore these factors to see how they give you clues to what people are thinking and feeling about your requests. If you can interpret these clues, they can give you new options for resolving resistance. You just might end up with an outcome even better than what you were asking for.
The First Factor: Expectations
Different people will respond in different ways to your request. What seems like an obvious, wonderful idea to Richard will seem irrelevant to Dick, and downright dangerous to Ritchie. Why such different responses to a single request? Because each person has a unique and personal point of view — that is, a unique and personal set of expectations about your request.
When you make a request, people ask themselves something like these three questions:
- Will I be able to do this?
- If I do it, what will be the results?
- Do I want those results?
Each person answers these questions differently. The answers describe the person's expectations about your request — expectations about ability, expectations about results, and expectations about value.
People's expectations strongly influence how they respond to your requests. If you want someone to change behavior, you must either adjust your request so that it fits with the person's expectations, or adjust the person's expectations so that they fit with your request. In order to do either of these things, you must understand the person's unique expectations about your request. Let's look at how people's responses give you clues about their expectations.
Expectations about Ability
My friend Louise invited me many times to go sport kayaking, navigating white water rapids in a one-person rubber raft called a "duckie." For years, I declined, fearing that I did not have the skill I would need. One day Louise told me about a company that offered a sport kayaking package for beginners that included training, life vests, and three expert guides to accompany a group of beginners down an exciting but relatively mild river. I was intrigued. At long last, I accepted Louise's invitation.
The expert guides strapped us into seemingly unsinkable life vests, showed us to our duckies, and trained us briefly. Then we set off down the river. Several times during the day, I fell out of my duckie and did a little freestyle white water swimming. By the end of the day, I was shooting the rapids with at least a little skill, and I yelled with exhilaration as I splashed through the longest, most treacherous rapids at the end of the course.
I had declined Louise's invitations for so long not because I was unable to survive the rapids, but because I had feared I would be unable. My reluctance had come from my expectations, not from my actual ability.
If people do not believe they will be able to do what you ask, they will be less likely to try. Sometimes people will tell you directly, "I don't know how to do that." In those cases, one option is to offer people opportunities to build their skill and knowledge, and to practice. Another is to adjust what you are asking people to do, so that it falls within their abilities. A third is to make the environment safe for experiment and play. Louise did all of these things when she told me about the beginner's sport kayaking trip. If you can do these things, people may find, like I did, that they have abilities they didn't know about.
Of course, people may not always tell you their doubts about their ability to do what you ask. Such doubts are deeply personal and often risky for people to admit, even to themselves. Instead, they may invent a plausible, acceptable reason ("That will never work here."), or walk away without making a clear commitment, or simply refuse without explanation. If you suspect that expectations about ability lie unspoken behind someone's reluctance, do not push. If the person does not see your relationship as a safe place to discuss such a tender topic, your probing could do more harm than good.
One option is to frame your request as an experiment, something for people to try, to see what will happen. And again, try to make the environment safe, so that mistakes are not too costly. In fact, this can be a good idea whenever you are asking people to try something new, whether they are reluctant or eager.
Expectations about Results
Suppose you have just recommended that your test group use GooeyBot 2000 to test your program's user interface. Ruth says, "That will never work here." Seth says, "That would cost too much money." Troy says, "We tried that at my last company, and it didn't work." These responses tell you about what results Ruth, Seth, and Troy expect.
When people make such clear statements as these, first check your own expectations to see if you can find some agreement. Do you have any doubts about whether GooeyBot 2000 would work in your test group or for your software? How much money do you think it would cost? Is Troy's previous company similar to yours in some important way? When you find agreement, tell people about it.
If Ruth, Seth, and Troy have expectations that you do not share, or do not understand, ask questions to explore their expectations more fully. Ask Ruth, "What will stop this from working here?" Ask Seth, "How much money do you think it will cost? How much can we afford?" Ask Troy, "How did you use GooeyBot 2000 at your last company? What happened? What led it to fail? What might have been done differently to make it work better?"
Compare what you learn to your own expectations. Would GooeyBot 2000 work here? Would it cost too much money? As you learn, you may need to adjust your own expectations, which may change your recommendation.
If you still have differing opinions, then describe own expectations, and explain how you arrived at them. Brainstorm with people to identify the assumptions each of you is making, and negotiate a way to test them.
Sometimes people are reluctant to do what you ask not because of what results they expect, but because they do not know what to expect. For example, suppose you have just proposed that your development team use Extreme Programming for its next project, instead of the cumbersome waterfall-based methodology the team has used for years. The project manager, Ulrich, says, "Tell me again, how will this work?" Verna, a key customer, says, "I don't understand how this will make a difference."
When people do not know what to expect, they are less likely to make a significant change. Family therapist Virginia Satir said that people prefer the familiar over the comfortable. Even if the current situation is uncomfortable, or inefficient, or marginally effective, people at least know what to expect — the same thing that happened yesterday, and the day before that. Before they will leave familiarity of the status quo, people usually need a reasonably clear idea of what to expect.
If someone asks you directly, as Ulrich has, go ahead and describe your own expectations. Your explanation may convince Ulrich to try Extreme Programming. If not, it gives you a starting point to explore how your expectations differ.
Verna, on the other hand, hasn't invited you to explain anything but only told you that she doesn't understand. Offer to describe how Extreme Programming will make a difference. If Verna accepts your offer, that's great. If not, perhaps you have a communication problem or relationship issue to work out before you can talk about expectations.
What about your own uncertainty? Are there aspects of your request about which you are uncertain? If so, acknowledge the unknowns and invite people to explore the possibilities with you. If you are completely certain about what you are asking, you are likely viewing your ideas through rose-colored glasses. Hold everything and try to think of three things that might go wrong. If you can't think of at least three things, ask a few other people to suggest ideas. They won't have any trouble.
Expectations about Value
Even if people believe they would be able to do what you ask, and even if they expect the same results that you expect, they still may refuse. People will do what you ask only if they want the results they expect. People's decisions about whether or not to do what you ask ultimately come down to values — their values.
Here is an example of how values affect people's choices. Debra and Cyril work in the IT department of a large company. Debra manages the support team that will support the new customer tracking system that Cyril's team is developing. Debra has repeatedly asked Cyril to make sure his team documents the architecture of the new system before deploying it, and Cyril has repeatedly refused. The problem is not Cyril's ability. He could certainly ask his talented engineers to document the architecture. The problem is not that Debra and Cyril have different expectations. They both believe that documenting the architecture would delay release by about a week and save several thousand dollars of support costs over the next year. The problem is that Debra and Cyril value these results differently. Support costs are paid from Debra's budget and not Cyril's. A delay delivery would affect Cyril's next performance appraisal, but not Debra's. As long as Debra values support costs over delivery, and Cyril values early delivery over support costs, they will remain at an impasse.
In many cases, it is easy to tell what people care about, because they tell you. When Cyril says, "No way! Wasting time documenting the architecture would blow my schedule," you know that Cyril values his schedule. When Seth says, "No way! GooeyBot 2000 would cost too much money," you know that Seth values money. When Edward says, "No way am I doing the dishes again! I don't want dishpan hands!" you know that Edward values his soft, smooth hands.
In these cases, Cyril, Seth, and Edward are saying, "This is something I value — something I do not want to lose." As transitions specialist William Bridges has observed, it isn't change that people resist. It's loss [Bridges].
When people resist because they expect to lose something they value, there are a number of things you can do to deal with the loss:
- Acknowledge the loss. If there will be a loss, acknowledge it. Be careful not to dismiss the loss as you acknowledge it. For example, do not say, "Yes, this costs money, but it will also save time." Instead, say, "Yes, this will cost money," and stop. That way, people are more likely to understand that you hear what they are telling you and that you are not deaf to their concerns. Once people know that you have heard them, you can talk about some of the following ways to deal with the loss.
- Provide a gain instead of a loss. Remember the advertisements for Palmolive dishwashing detergent? "Palmolive softens hands while you do the dishes!" Can you show that Extreme Programming may increase the project manager's control, rather than diminishing it? Can you show that code reviews would help your project deliver sooner, rather than later?
- Prevent the loss. Can you (or Debra) lend Cyril an engineer or two to document the customer tracking system's architecture so that his engineers can stay focused on hitting the release date?
- Restore the value after the initial loss. Can you show how time spent now on design reviews will be repaid by time saved later?
- Compensate the loss with some other value. Can you show that improving the system's reliability will reduce support costs, even if it means shipping two weeks later?
- Limit the loss. Can you upgrade the company's e-mail servers on the weekend, when fewer people will be affected by the down time? Can you try Extreme Programming on one small project, rather than across your entire development organization?
No matter which other alternative you choose, always acknowledge the loss. Acknowledging the loss is important even when you can restore, limit, or compensate for the loss, and it is crucial when none of those alternatives is possible.
The Second Factor: Communication
The second key factor that affects how people respond to your requests is communication. As we saw in the previous section, people will sometimes respond in ways that directly and clearly communicate about their expectations. However, not every response will be so direct and clear. For example, suppose you ask Albert, a project manager, to write a risk management plan, and he replies, "But this is just a small project." What are Albert's expectations? You may have to do a little detective work to interpret the clues in Albert's statement.
One detective tool is Jerry Weinberg's Rule of Three Interpretations: Before responding to any one interpretation of the clues, think of at least two other possible meanings [Weinberg]. Then, check to find out what the person actually meant.
Here are three possible ways to interpret Albert's response:
- I am afraid to think about what might go wrong."
- "The risks on a small project are so few or so inconsequential that there is no need to manage them."
- "The cost of developing a risk management plan is too high for a small project."
There's no guarantee that Albert intended any of these meanings. Our purpose is not to guess what Albert meant, but to remind ourselves that Albert could have meant any number of things. With that in mind, we can now check with Albert to test our interpretations. "Do you mean that you expect very few problems?" Then listen to what Albert says.
Also helpful is Miller's Law, which says, "To understand what another person is saying, you have to assume it is true and try to imagine what it might be true of." [Elgin]. When you want to understand what someone is saying, you can apply Miller's Law by asking yourself, "In order for this statement to be true, what else would have to be true? Under what circumstances would it be true? In order for me to believe that, what else would I have to believe?" I call these questions "Presupposition Probes," because they expose presuppositions, the unstated, but implied, meanings in the statement. Presuppositions always carry information about the person's expectations or beliefs.
Suppose you have asked Betty to institute a system of design reviews for her project, and she says, "No way! We're already behind schedule!" In order for this statement to be true, what else would have to be true? For one thing, there would have to be a schedule. For another, Betty would have to know the project's current progress compared to the schedule. Further, the statement makes sense as an answer to your request only if instituting design reviews would put the project even further behind schedule. Once you are aware of the presuppositions, check whether Betty intended to convey them. You might ask, "Do you expect that design reviews would put you even further behind schedule?" Then listen to what Betty says.
The test of whether you have understood Betty and Albert is to tell them what interpretations you have made, and ask if you understood correctly. Then listen to what they say.
The Third Factor: Your Relationship
The third key factor is relationships. Every time you talk with someone, your relationship enters the conversation before your words do. It affects what you and other person are willing to talk about. It affects how you interpret each other's words and actions. It even affects whether people are willing to talk with you at all. If you want to understand a person's point of view, you must have a relationship that supports clear, honest communication.
I once asked a group of people about their reasons for refusing some request. One person said, "I didn't want to give him the satisfaction." Another said, "I didn't like the way they asked. They demanded it of me." A third said, "I thought, ‘Why should I listen to you?'" In these examples, the nature of the request itself barely matters. What matters is the relationship between the two people involved.
Relationship issues can be especially difficult to resolve. People do not often come right out and say, "I don't want to give you the satisfaction." More likely, they will quietly ignore your request, or agree to do what you ask and then not follow through, or invent an "acceptable" reason for refusing, or play dumb, or any of a hundred other possibilities.
If people are talking to you about your request, even if they are resisting, that is a usually a good sign. You can at least learn something about their expectations. If people are not doing what you ask and are not talking with you about it, that may be a clue about your relationship. If you suspect that your relationship leading to resistance, set your request aside temporarily and focus on improving the relationship.
One way to improve a relationship is to listen fully to the other person's point of view. Use the Rule of Three Interpretations, the Presupposition Probes, and other communication tools to make sure you understand what the person is saying. Then ask, "Is there more that you want to say?" Repeat until the person feels fully heard and understood.
Another technique is to explore your own thoughts and feelings about the person and your relationship. How do you describe the person? How do you describe your relationship? What feelings do you have about the person, and about the relationship? How would the other answer these questions? (How could you find out?) How might your thoughts and feelings be affecting the way you interact with the person and the way you interpret the person's responses to your requests? What one change could you make in your thoughts and feelings that would most improve your interactions?
Improving your relationships will probably not eliminate all resistance — even your best friends will not always do everything you ask. But if you can create a relationship that invites people to listen, consider your requests, and talk with you about their expectations, you will have a much greater chance of negotiating a result that satisfies you.
The Fourth Factor: The Environment
In some cases, people are willing, and even eager, to do what you ask, but they feel constrained or discouraged by circumstances around them, in or out of the organization. These external circumstances form our fourth key factor, the environment in which people choose how to respond to your requests.
When people choose not to do what you ask, they may offer reasons that point outside themselves:
- "The managers won't go for that."
- "We are not allowed to do that."
- "We're too busy."
These statements express a special kind of expectation. They say not only, "That won't work," but, "That won't work in this environment." Not only, "I can't do that," but, "I can't do that in this environment." This distinction offers an encouraging possibility. Is there a way to adjust the environment to create a context in which people will choose to do what you ask?
One way to create a more favorable environment is to remove the obstacles that prevent or discourage people from doing what you ask. If Jeff says, "I'm too busy to do code reviews," can you do something to reduce his workload? If Karen says, "My manager would never let my team program in pairs," can you help Karen negotiate with her manager to allow the team to try pair programming for one week?
A second way to improve the environment is to supply some nec
essary resource that the environment currently lacks. If Linda says, "I don't have the authority to hire a facilitator for JAD sessions," can you help Linda to obtain the authority, or ask an authorized person to hire the facilitator? If Myron says, "I would love to finish the budget, but the home office has not sent me the information I need about last year's expenses," can you motivate the home office to send Myron the information he needs?
So far, I have assumed that you agree with the expectations people are expressing. But what if you do not agree? What if you think the expectations are unwarranted or irrelevant? For example, what if you think Karen's manager just might allow the team to program in pairs? You can handle that as you would any other disagreement about expectations — make sure you each understand the other's expectations, then find a way to test them. You might invite Karen's manager into the conversation, and simply ask him whether he would allow the team to program in pairs. You may learn that Karen was right. Or you may learn that the manager is actually excited about pair programming. Either way, at least one of you has learned something useful. Sometimes what people need most from their environment is accurate information.
I have also assumed that you are taking people's responses at face value. But what if you believe someone is not being sincere, and is offering not reasons but excuses? For example, what if you think that Karen herself does not want to pair with other programmers, and is using her manager as an excuse? First, consider the possibility that Karen is being sincere and act accordingly. If you can't bring yourself to believe that, then either Karen is not telling you her real reasons or you are not able to trust what she says even when she is being sincere. Either way, you have a relationship issue to resolve.
How to Eliminate Resistance
I have discovered a foolproof way to eliminate resistance. All I have to do is to stop giving advice, stop making proposals, and stop asking people to do things. If I never ask people to do anything, they have nothing to resist!
But of course, I won't stop doing those things.
How lucky, then, that I know a second way to eliminate resistance. All I have to do is to stop thinking of people's responses as resistance. I can think of each response as simply a response. Even better, I can think of each response as information. With every response, I learn something that I did not know before. I learn about other people's expectations, or about my own. I learn about how I am communicating about what I want. I learn about the relationships I have established and how I may need to strengthen those relationships. I learn about what is possible here and now how I may need to adjust the environment around me to better support the requests I make. Each thing I learn gives me new possibilities, new ideas about what I can do to move a step closer to resolution.
When I think of people's responses not as resistance, but as information, I am better able to work with people to create results that satisfy them as well as me. This approach works well for me. I believe it will work for you, too.
I would like to thank Esther Derby, Dwayne Phillips, and Naomi Karten for their feedback and encouragement, and Lucy Lockwood for suggesting the title "Resistance as a Resource."
Bridges, William. Managing Transitions. Reading, Mass: Addison-Wesley, 1991.
Elgin, Suzette Haden. BusinessSpeak. New York: McGraw-Hill, 1995.
Weinberg, Gerald M. Quality Software Management, Volume 2: First-Order Measurement. New York: Dorset House Publishing, 1993.