by Rick Brenner
Have you ever thought "Why did I ever agree to do that?"? Have you ever wished that you knew better how to say no — or even how to avoid volunteering to do something — without suffering undue consequences? Giving a firm and clear No can feel good if it comes from a place of high self-esteem.
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 was 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 a 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."|
Here's an example. You're a project manager of a large project. Of course, the project is late (see, for example, "Why Complex Technology Projects Are Usually '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 VP's (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 isn't 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.
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.
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's 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 plural? There are actually two: the confrontation you're 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's 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 that you're 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.
When I say-no to people who desperately want to hear "yes," they must finally face the problem, or even better, we'll 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're 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 there 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's 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.
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 such situations suggests 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's 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. Some of them have happened to me. So to avoid these consequences, we say-yes.
But the fear stays with us, even after we say-yes, and it's compounded by the knowledge that we agreed to try to do what we know is truly impossible. The next time there's a crunch, we face the same dilemma, and we make the same choice. Impossible goal is piled on impossible goal, until we're 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.
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 feel 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 people who desperately want to hear "yes," they must join me in facing the problem that we have. It might be that the problem isn't one of our 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. The owner of a problem is responsible for addressing it, even if the problem's creator is somebody else. And in organizations, the owner is usually us.
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.
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're saying-no with the knowledge that you can deal with what comes. You're 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.
Adm. Leighton Smith and President Clinton. 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." Photo courtesy Frontline.
As you practice, you'll find your own ways to say-no. But here are a few to get you started.
Do you sense that people in your organization might be saying-yes when they really want to say-no? I can do a one day workshop (or a 90-minute interactive talk and demonstration) on the problems of saying-yes and the advantages of saying-no.
Contact me to discuss your specific situation, by email at rbrenaujbckPqPGFrBvJtner@ChacgTqDSglsDhUuFUOeoCanyon.com or by telephone at (617) 491-6289, or toll-free at (866) 378-5470 in the continental US.