Saying No: A Short Course for Managers
Saying "No" can be painful -- so painful that we sometimes avoid it just to avoid short-term pain, only to find later that the long-term pain is even worse. For example, when I've been asked to commit to deliver a product within a time period that's clearly too short, I have sometimes agreed to the request, even though I knew better. My own guess is that at one time or another, most of us have avoided saying "no" by saying "yes". We do this in spite of our experience that the price we pay for agreeing to do something we don't believe in is often far too high.
There are many people who would like to say "no," but I've decided to focus on project managers. Even for project managers, there are occasions to say "no" that I won't deal with here. But if you're manager, an executive, or an engineer, you can take what's here and modify it to suit your own needs.
A bit of shorthand just for this essay. Typing these quotes around the "no" and "yes" is only slightly less annoying than reading them, so I'll be using these constructions:
- say-yes This means "to agree to do something when you know in your heart that it's a long-shot at best, and probably impossible anyway."
- say-no This means "to decline to do something, and to tell it that way, because you know in your heart that it's a long-shot at best, and probably impossible anyway."
That piece of bookkeeping done, here's a road map:
What can go wrong when we say-yes
Why saying-yes doesn't "buy time"
How saying-yes prevents group problem-solving
Why it's destructive to play the blame game
Traps and pitfalls when we say-no
Some honest ways to say-no directly
Where to go from here
What can go wrong when we say-yes
Here's an example. You're a project manager of a large project. Of course, the project is late. You're sitting at one of those long conference tables with about 16 other people, including eight of your team leads, four people from Marketing, two sales reps whose accounts are key customers, and two VPs (Marketing and Engineering). You've just gone through the critical issues list and you gave a pretty good justification for your estimated completion date. Apparently the justification is not good enough, though -- five people in the room are now pressing you to commit to a date four months earlier than you believe you can meet. You can probably guess which five. Everyone is looking in your direction. You feel alone. You feel as if nobody is backing you up. You'd rather be interrogated by Kenneth Starr.
What are your choices? This isn't really very complicated -- there are only two basic options. You can agree to a shorter date, or you can try to persuade others that what they want isn't realistic. Let's suppose that you agree to a short date, and then examine the consequences.
Assuming that you knew what you were doing when you made the estimates, the project team won't make the short date -- no way.
By agreeing to the short date, you will have immediately undermined your own credibility with the team -- on this project, and in the future. After all, did you not believe in those estimates you so carefully drew up? If not, then they might ask "What else have you said that you yourself don't really believe?"
More damage will come to your credibility later, when the project comes in "late;" that is, past the date you just agreed to. Then some people might ask why you agreed to the short date, when even Ratbert could tell it was impossible.
Get ready for some serious déjà vous. When the news that the project is late hits the wire, when it is obvious to everyone some months from now that you won't make the short date, most of the same players, including yourself, will reconvene in this same room, with maybe even the CEO sitting in, and you will be in the same hot seat. It might even be a little hotter then. Did I say déjà vous? In some organizations, it's more like the movie "Ground Hog Day" [Ramis 93] -- it happens again and again.
At that point, the members of the project team will be even more tired and cynical than they are now, because they will have been burning the candle at both ends for all the months between the time you agreed to the short date, and the time it became unavoidably clear to everyone that the short date was a fantasy.
The quality of the work everyone has been doing will be in decline. Errors and omissions could cost you even more time.
Problems might have multiplied because of short cuts taken and risks that went unmitigated in the hope that things would fall the right way. And you know: things rarely fall the right way.
It might even happen that the sane date, the one you originally wanted, could become impossible because of all the compounded problems caused by rushing to the short, improbable date.
Trying to achieve an improbable date is like trying to cross an urban Interstate at rush hour. You might make it, yes, if you can move as fast as the Roadrunner. But chances are you won't survive. If a date is improbable, it's just improbable.
Why saying-yes doesn't "buy time"
Perhaps you believe that saying-yes -- agreeing to an improbable date -- is a bad idea because it just postpones the day of reckoning. Ah, if only it were that good! Agreeing to an improbable date is actually far worse than a simple postponement. While it is true that saying-yes introduces a delay, the delay itself actually makes the problem worse. Time passes, resources are spent, and opportunities for alternative strategies disappear. The project becomes more tightly constrained as time goes by. Your options narrow. Agreeing to an improbable date makes that improbable date even less probable than it was when you agreed to it.
The idea that we can "buy some time" by agreeing to try to do magic is actually backwards. You aren't buying time -- you're transferring it. When you agree to try to go for a date that you know you can't make, you're taking from the project the time you need to address the underlying issues that are plaguing the project. In exchange, you receive a postponement of the confrontations. Confrontations? There are actually two: the confrontation you are now having with the people who are demanding an early completion date, and the confrontation they must soon have with Reality.
When we say-yes, there is a transaction involving time,which we can understand using an analogy from accounting. In this analogy, there are two time accounts. One is for your career within the organization. The other is for the project you're managing. When you say-no, you let the time stay in the project account, and take whatever consequence comes as a charge to your career account. When you say-yes, you take time from the project account, and transfer it to your career account. You intentionally plan to use the time in your career account to postpone the confrontation you are about to have with the people who are arguing for the short date. This might be a good idea, if it weren't so much like embezzling. Using project resources for personal gain is a questionable practice. When you say-yes, you aren't buying time -- you're embezzling it.
How saying-yes prevents group problem-solving
When I say-no to someone who desperately wants to hear "yes," he or she must finally face the problem, or even better, we will face it together. When I say-yes, I deprive the organization of a real chance to face the issue. And I do it without letting anyone in on what I'm doing -- perhaps not even myself. A fundamental requirement for successful group problem-solving is a shared agreement that a problem exists. When you say-yes, you get shared agreement -- that there is no problem. This halts group problem-solving.
Let's go back to the hot seat in that conference room for a minute. As soon as you say-yes, you mollify the five advocates of the short date. Your stomach might go into knots, but at least these five people are off your back. And they are relieved of all responsibility for figuring out what to do about the problem. Chances are, this problem wasn't their only problem. So they're more than happy to move on to something else. The meeting ends shortly after you say-yes, and you walk out of their under the burden of a very significant action item: to do the impossible. But their minds are now elsewhere, and this is how group problem-solving comes to an end. The problem is now all yours. That's fine, if you actually have what you need to solve the problem. But since we're assuming here that you don't, the problem is still there, but by group agreement, it remains unseen.
Now let's think about what happens when you say-no. Suddenly, everyone in the room now knows that there is a problem. And most likely, people go to problem-solving mode immediately. In some groups, personal attacks and blame can result, as some people identify you as the problem (you aren't). And you might find yourself under attack. In other groups, those with more effective problem-solving practices, the group can now move to a collective exploration of the problem and possible resolutions and options. You probably know which kind of organization yours is.
The best route to a constructive resolution is through saying-no. It isn't a guarantee of an outcome you want, but saying-yes makes such an outcome a lot less likely by preventing group problem-solving.
Why it can be difficult to say-no
Probably the main reason we say-yes when we want to say-no is to avoid playing the blame game. Back to that conference room. My experience in situations like that is that if I say-no, the short-date folks in the room first try to persuade me that I must be mistaken. Failing that, they try to invent miraculous ways to cut work from the schedule. "We can save two weeks in testing," or "What if we remove these other features?" These conversations are inevitably unproductive, but for some reason, they occur with regularity. It's frustrating to engage in these debates, particularly if your partner in debate takes a position such as "Let's not be so technical about this," when the subject matter is inherently technical.
Why is this so difficult? The short date folks want something that is simply impossible. It should be so easy to say "I'm sorry, I don't know how to get all the remaining work done in the time we have left." What makes such a simple statement so hard to say? Fear.
In my own case, I fear losing my job, or I fear being passed over for promotion, or being downgraded on a performance review. These are real fears of real consequences. And these consequences really happen to people. They have happened to me. So to avoid these consequences, some of us -- including me -- have a tendency to say-yes.
But the fear stays with us, even after we say-yes. And it is compounded by the knowledge that we agreed to try to do what we know is truly impossible. The next time there is a crunch, we face the same dilemma, and we make the same choice. Impossible goal is piled on impossible goal, until we are carrying a heavy burden of guilt and obligation to meet impossible commitments. Is this a life you want for yourself? Wouldn't it be better to say-no? It never seems so, until after you say-yes. Next time you feel the urge to say-yes, remember that.
Why it's destructive to play the blame game
Often we confuse the responsibility for addressing a problem with the responsibility for creating it in the first place. In the confusion, we can sometimes come to believe that the people who created the problem are responsible for resolving it. If we do that, we can get into even deeper trouble, because it just isn't always true that the best people to resolve problems are the people who create them.
For example, let's suppose that I'm a project manager, and that I've made some inaccurate estimates that were used to compute a delivery date that we now understand we can't make. And let's suppose that Sales has committed to delivering the item to a key account. What now?
One possibility is that we can work 16-hour days, hoping to make the date. Another is that we can tell the customer that we made a mistake and that the product won't be ready on time. In the former approach, the project staff takes responsibility for solving the problem; in the latter, Sales takes some responsibility. Which approach is "right?"
There is no right. It depends. We can choose between two high-risk strategies. If we work long days, we could lose important people from the project team, and we could risk product quality, corporate liability, and harm to the customers. If we explain things to the customer, we could lose a customer. Tough call. But we make the decision on the basis of our assessment of the risks and benefits of each strategy, rather than on the basis of who is "to blame for this mess."
When an organization finds itself in a blame cycle, some people feel pressure to take responsibility for addressing a shared problem. When I agree to accept responsibility for resolving a shared problem, even when I agree that I contributed to creating the problem, I might be depriving the organization of better options for addressing the problem. Even though the other people involved might feel a sense of justice and relief when I say-yes, the organization might be making a significant error.
When I say "no" to someone who desperately wants to hear "yes," they must face the problem that they (or perhaps we) have. It might be that the problem is not one of their own making, it might even be that I helped make the problem. But it's important for everyone to understand something about problems -- the owner of the problem owns the problem. And the owner of a problem is responsible for addressing it, even if the creator is somebody else.
Traps and pitfalls when we say-no
One reason we avoid saying-no might be that we've had some bad experiences with it. As with most things we try to do, we can learn to do them better. So let's look at some of the traps and pitfalls that you might encounter as a no-sayer.
The cavalier "no"
Perhaps the most destructive way to say-no is to simply deliver the "no" without regard to its effect on your partner in the discussion. To appear not to care about the consequences of your "no" -- or worse, to actually not care -- almost certainly alerts your partner to a threat and could motivate him or her to attack, blame, or engage in otherwise destructive tactics.
To avoid this, as you deliver your "no," take care to communicate that you do care about the consequences, that you are still on the team, and that you are highly motivated to find another way. Communicate clearly that your "no" merely means that you can't find a way to do what you've been asked to do, and that it is very likely impossible. Communicate clearly that you believe another way can be found, and that you are ready to help find it.
I told you so
When you've predicted the current problem, it's very tempting to remind your opposition of that fact. For example, you might feel the urge to say, "I don't believe we have the resources to make that date now, any more than I believed we had the resources to make the original date six months ago."
Avoid this temptation. Even though it seems to you to be a strong argument that buttresses your credibility, it usually forces your partner in conflict to dig in, heightening the conflict, and making it more personal. Reminding people of your past successful predictions, or their past unsuccessful ones, almost always deepens divisions. Stick to the here and now.
Putting the punch line last
A great formula for jokes, but exactly the wrong thing for saying-no. When you say-no, put the "no" up front. Compare these two nos:
- I really would like to help out, but we don't have the resources we would need, and there probably isn't enough time, so I'm afraid we can't help with that approach.
- I can't help with that approach and I'd like to explain the problems I see. We can't commit the resources it needs, because we just don't have them. Even if we did, I don't think we have enough time.
When you put the punch line last, everything leading up to it sounds evasive and defensive. While the listener is waiting for the punch line, he or she is working on responses to your excuses. They might not even hear your punch line if they're too distracted with construction of their own reply.
When you put the punch line first, you increase the probability that people will hear it. And when you follow it with an immediate offer of an explanation of your problem, you have a good chance of moving the discussion toward problem-solving and away from confrontation.
I'm not to blame -- they are
If you've convinced yourself to say-no, but you still feel some fear, you might be tempted to make it easier on yourself by adding a blame statement as self-protection. For example, you might say "I don't believe Release 2.0 can make that date anymore. Perhaps we could have done it if the firmware team weren't still working on the problems in Release 1.0, but as things are, it's just not possible."
Playing the blame game rarely works. Even if you succeed in distracting people from the real problem -- the thing you are saying-no about -- they are distracted. They can't focus on the real problem because you've distracted them. To address the problem, everyone must focus on it, and blaming prevents that.
A better approach: be more direct, stick to the facts. You might say "I don't believe Release 2.0 can make that date anymore. We just don't have enough firmware folks to get the job done in time." When people ask why there aren't enough, you (or someone else) can explain what they're all doing. This approach sticks to the facts and avoids blame. It leads the group into solving a resource allocation problem.
Some honest ways to say-no directly
Saying-no well, and feeling good about it, starts from the inside. To feel good about the no, start by feeling good about yourself. Then adding the no is a small step. You are saying-no with the knowledge that you can deal with what comes. You are just stating the truth as you see it. To help you focus on this centered approach, use "I" (or possibly "we" if you're speaking for a team) statements as you say-no.
As you practice, you'll find your own ways to say-no. But here are a few to get you started.
I don't know how to do that.
If someone has asked you to do something, and you honestly don't see how you can get it done, say so. It's better to let them know now than it is to have them discover it later, after you led them to believe that you could do it. If everyone knows your limitations, you can get the help you need to get the job done. Remember, your limitations are not just yours. If you don't know how to get something done, there's an excellent chance that nobody does.
I don't know how to do that within the constraints we have now. Could you help me find a way to adjust the constraints?
This is a general formula that's probably more useful as a formula than an actual way of saying-no. It's easy to generate more specific examples of this formula:
I can't do that by the time we need it. Could you help me adjust some priorities?
This one is especially handy if you have to say-no because you're overbooked. Another way to say this one is, "Sure, I can do that, but it would have to be instead of something else that's less important." Now the two of you can begin some joint problem-solving about priorities. That's a very good place to be.
I don't know how to meet that date with the schedule we have already accepted from our supplier. Can you think of a way to get those components from them any earlier?
Now you've moved the discussion towards team problem-solving of a critical-path schedule issue. Perhaps someone in the room can work this issue better than you can.
I don't know how we can meet that date. What would happen of we were a week late?
In this example, you're moving the discussion to a question of the target date. In most cases, a one week delay is OK, so this is actually an exploration of the boundary of "OK".
I don't know how to stay within schedule and budget if we change the requirements at this late date. If we were to add this capability in a later revision, what can be done to keep the customer satisfied in the meantime?
Typically, the real issue for many in Sales/Marketing is customer satisfaction. You are more likely to be successful in problem-solving if you can move the team to problem-solving of the real issue.
We could do that. It would require more resources, and it would take longer, but we could do it.
This approach is "can-do." The risk, of course, is that the response might be "well, then do it, but we can't spare any more time or resources." But if you trust your audience to take you at your word, to understand that you really do need more time or resources, then this is a good option.
It's unlikely that we could get it done. It's possible, but I'd estimate that the probability is under 10%.
Project management is inherently uncertain. This is especially true of complex projects. Even if you are certain that you cannot make a date, or that you cannot include a feature and still make the date, you can't be 100% certain. Use this. When you deliver your "no," deliver it as a probability -- a low probability. This approach is actually more correct than simply saying "We can't do it," because it gives your estimate of the chances of success.
There is a problem with this approach. You might be dealing with someone who won't accept probability estimates. Some people might say, "Don't give me those probabilities -- can you do it or can't you?" If that happens, then you know that you're dealing with someone who isn't plugged into Reality. Anyone who expects a manager of a large, complex project to know anything for certain -- 100% certain -- is in Fantasy Land. You might have to avoid this approach, at least until they retire, or the project ends, or you can transfer or find another job.
One example of applying one of these formulas is a story told by Adm. Leighton Smith, Jr. (ret.) in the documentary Give War a Chance [WGBH/Frontline 1999]. When Adm. Smith was commander of IFOR in Bosnia, President Clinton visited -- with Secretary of State Madeleine Albright and a Congressional delegation. Smith was a "minimalist" in the debate about the role of NATO military elements in Bosnia, opposing policies that called for widening IFOR's mission there. Pressures from the "maximalists," who sought a wider role for IFOR, had been building, and at one point in the visit, the President asked the Admiral, in front of the Secretary and the members of Congress, if IFOR could guard the mass grave sites in Bosnia. Such a responsibility would have widened IFOR's role considerably, and Adm. Smith thought it was a dangerous idea. He replied, "Mr. President, we can do anything you ask of us, but there's a price to pay, and, in this case, it means a lot more forces." Later, the President privately thanked the Admiral for his answer, calling it "perfect," and saying "they needed to hear that from you." Adm. Leighton Smith & President Clinton (photo courtesy Frontline)
Where to go from here
Observe the people around you
The people around you face many of the same situations. Once in a while, you'll have a chance to watch someone choose between saying-yes and saying-no. When it happens, enter it in your say-no journal. You might learn a new way to say-no, or find an example of saying-yes. Track the example over the months to see how well it works out.
Observe yourself
You could surprise yourself. It might happen that you find a new way to say-no just by getting through life. When you find a good one, don't let it get away. Add it to your say-no tool kit.
Form a say-no circle
You might know other project managers who face these same issues. Perhaps they work at your company, but perhaps they work somewhere else. Through email or telephone, keep in touch -- exchange saying-no and saying-yes stories. Learn from the experiences of everyone in your say-no circle.
Are you a project sponsor? Reward those who say-no.
If you're a sponsor for a project, and your project manager says-no, reward him or her: "I'm really grateful for your honesty. I don't know how we could have gotten through this if we didn't know about the problem." Say this publicly. The most important raw material for sane project management is Truth. If you want more of it, reward those who deliver it.
References
McLendon 96: McLendon, Jean and Gerald M. Weinberg, "Beyond Blaming: Congruence in Large Systems Development Projects," IEEE Software, July 1996, pp.33-42.
Ramis 93: Ramis, Harold, director. Ground Hog Day. Columbia/Tristar Pictures, 1993.
Satir 91: Satir, Virginia, John Banmen, Jane Gerber and Maria Gomori. The Satir Model, Family Therapy and Beyond. Palo Alto, CA: Science & Behavior Books, 1991.
WGBH/Frontline 1999 Give War a Chance. WGBH Frontline, 1999.
Email this article to a friend.
Comments to:
