Management Speak: We have to do it the way we’ve always done it, even if it is wrong, because changing it would cause too many problems.
Translation: Everybody involved in creating this monster is either dead, retired, or laid off.
Revealing the name of this week’s source would cause too many problems
Month: October 1999
Getting to neither no nor yes (first appeared in InfoWorld)
Computers operate on binary logic – one or zero, true or false, yes or no.
I guess it’s contagious.
A while ago I gave a simple piece of advice: Never say no. Quite a few correspondents ignored the essay that followed. Instead they applied the binary system to my advice, inferring that I’d told them to always say yes.
False inference. The binary system is wonderful in its place. Applied to human decision-making, though, it’s usually disastrous, forcing a universe of possibilities into two oversimplifying buckets.
To illustrate, imagine a business manager asks you to install a Windows NT server for his department (we’ll pick on NT today – next time we’ll choose a different OS to victimize) so he can run a particular packaged application, in violation of your standards and personal judgment.
What do you do?
You can say “I’m sorry, but that would violate our standards,” or, “We try to avoid NT because it’s far less stable than the other solutions on the market.” Care to guess how the manager will describe your encounter?
“He was a typical chip-head. He never listened to me. He just kept on telling me that what I want won’t work, without once explaining why and without explaining how it is that three of our competitors are doing exactly what I asked him for.”
Is that the way it happened? From your perspective no, from his perspective yes. It’s binary, and his audience is listening to him, not you.
How should you handle a request like this? Be non-binary by responding with a “forcing question” – one that directs the conversation into the right channels. Say, “NT is just an operating system. Let’s hold off on that discussion until we’ve talked through what it is you’re trying to solve. Now what is it you’re trying to accomplish?”
Wham! You’ve forced the conversation into a productive direction. After a while you understand what your new-found friend is trying to accomplish, and then he says, “Now when can I have my NT server?”
Don’t say, “I really think you’d be better off using Linux,” (or Solaris, or AS/400, or Network Computers, or what-have-you). Use another forcing question: “I’m curious – where did you hear that an NT server is the best solution?”
He’ll tell you. He may have heard it from his peer in another company or the sales representative from the application vendor—or it may be that NT is the only operating system he’s ever heard of.
After he tells you, chances are he’ll ask, “Why … is NT the wrong choice?” He’ll ask because the intelligent conversation he just had with you (in which you remained almost entirely silent) has established you as an expert.
If he doesn’t ask, you have more forcing questions to ask, like, “Have you thought through the integration issues you’ll face by going down this path?” He’ll almost certainly either explain his thinking about each issue you raise or ask you to explain it to him.
Don’t take this to extremes. Three issues are enough. Your goal is to move from his proposing a solution to mutual problem-solving.
Let’s imagine all is for naught and this particular manager turns out to be an obstinate fool, insistent on this direction despite your best efforts to bring him to his senses. Do you say no now?
Nope. Your job isn’t to say no. It’s to help this guy succeed. Tell him that. Then use a different negotiating tactic called “absent authority.” Say, “Unfortunately, NT is outside our standards, which means I don’t have the authority to make this decision – let me describe the process you need to go through.”
Make sure the process for approving all bad ideas belongs to the IS Steering Committee, which is chaired by the CIO, populated by the company’s key executives, and responsible for approving resource allocations for IS projects.
Let someone else say no, not you. And if the IS Steering Committee approves this request and is willing to fund it … that’s its privilege.
Yours is to go make it work.