In the course of every project, there comes at least one moment when we have to tell our business partners what we need from them to get the job done. More often than not, they bristle at being told what to do. They don’t like being on the receiving end of ultimatums. Who does?
But they especially don’t like “those IT people” telling them what to do. That’s because we in IT are supposed to serve the business, and servants are expected to take orders, not give them. It doesn’t help that, even though we are perceived as being in a subservient position, we have gotten a not-entirely-undeserved reputation for being blunt, bossy and condescending that makes our business partners want to resist.
More often than not, being bossy is not our preferred mode of operation. But we often don’t have much choice. Some dependencies cannot be eliminated; some deadlines cannot be fuzzed. A lot of the time, we are the ones who are best situated to foresee potential difficulties. The issues may be regulatory: “You need to test this and provide an approval for the SOX auditors by Monday.” Others are logistical: “You need to sign a deal with the software vendor by next Wednesday.” And some are driven by process or politics: “We need your explicit signoff on the requirements before we start developing code.”
We don’t always realize that what we are saying to our business partners amounts to an ultimatum. To us, we are making simple statements of fact, merely illuminating project constraints. We can’t imagine that these facts might be interpreted as threats and demands, but they are. Read the three statements in the previous paragraph again. You probably see them as informative, even helpful. What you probably don’t realize is that our business partners hear a silent “or else” at the end of every similar statement we make.
So how can we avoid triggering their umbrage and defiance? There are three distinct things you can do: Empathize, explain and describe.
- Empathize with your audience’s point of view. Now that you know that they are hearing you say, “ Do this, or else,” you can consider how they might feel about that. Let them know that you understand that it sounds like you are delivering an ultimatum, assure them that you don’t mean it that way, acknowledge that you understand the pressure you are putting on them, and then …
- Explain why the demand has to be made and …
- Describe the consequences of failure to comply and/or the benefits of cooperating.
It’s really that simple.
Here are a couple of examples:
- “I wouldn’t ask you to do this if it weren’t really necessary, and I realize how busy your people are and that this means that they will have to do more work as we launch the project.” (Empathize) “But we are not accountants, and we need to understand your processes in detail to automate them.” (Explain) “Your detailed input will ensure that we build a system tailored to your needs.” (Describe benefits)
- “I know that it seems like we’re asking your people to test on the weekend because we’re not willing to be responsible for the quality of the system.” (Empathize) “The reality is that it is a Sarbanes-Oxley requirement that users sign off on the newly deployed system.” (Explain) “If your people wait until Monday to test the system, no one in the company will be able to use it until Tuesday.” (Describe consequences)
If you can avoid turning a project requirement into a battle of wills, you’re more likely to get what you need and strengthen your stakeholder relationships in the process. All it takes is a little bit of effort in thinking about the world from your partners’ perspective, followed by clear communication that lets them see that you have done that.
Paul Glen is the co-author of The Geek Leader's Handbook and a principal of Leading Geeks, an education and consulting firm devoted to clarifying the murky world of human emotion for people who gravitate toward concrete thinking. You can contact him at info@leadinggeeks.com.
