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.
It’s really that simple.
Here are a couple of examples:
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.