In two of my recent posts, I exhort you to tell IT consulting clients what's inconvenient for you to admit as well as what's inconvenient for them to hear. But what about if your client asks you to stretch the truth to someone else — would you?
Before you yell out, "No way!" consider these cases:Scenario #1: Your client is taking you along to an important pitch meeting. The prospect is a large organization that is paranoid about adhering to best practices and making sure they pick the industry leader. Your client is a leader in their field, but they have only a handful of employees. Your client is worried that the big prospect will think they're too small to take on the job, so they ask you to help create the impression that they're bigger than they are. You don't have to say anything that's actually false — they just want you to use phrases such as "the entire development team" and "at our main office." How do you respond? Scenario #2: Your client's software is having a problem interacting with a third-party package. Your client doesn't understand any of the details and needs you to discuss this problem with the vendor's technical support. The vendor's very expensive support agreement states that only the individual holding the agreement can call technical support. Your client asks you to make the call and pretend you are the holder of the agreement. Will you? Scenario #3: Your client says that you might be getting a call from a tax auditor to ask about travel expenses for a business trip you took on their behalf; the client is claiming the expenses on their tax return. Both of you know the trip never happened. Your client assures you that you have nothing to worry about — since it's all expensed, there's no tax effect on you whether you say you took the trip or not — and it sure would help them out of a jam. The client adds that they won't forget how you helped them out. What do you say?
All three of these examples have happened to me during my IT consulting career. It's very tempting to go along with your client's wishes because you want to make them happy, right?
Putting aside any moral considerations, think about the practical consequences of the proposed action on your relationship with the client. In all three cases, you'd be fibbing for money. Exactly to the degree that you're willing to stretch the truth to make or save money for your client, your client should expect that you would also be willing to stretch what you say to them if it helps your bottom line. If you fib on behalf of your client, there's a chance that your client might start second-guessing what you say to them, especially if it helps your bottom line. For instance, why should they believe that you put in 12 hours instead of 10 hours on that remote project? Or that you weren't doing something else half the time?
The way that you would answer the hypothetical questions is a demonstration of your trustworthiness. Would you believe someone who is cheating on their spouse in order to be your lover when they assure you that they would never cheat on you once the passion has faded? Well, some people do, but they're denying hard evidence to the contrary. Do you want to show your client your cheating side?
On the other hand, it can put your relationship with your client on the skids if you just say, "No, I can't do that." Here are possible ways to get out of lying without making your client into the scorned villain.
I'm not saying that I've never stretched the truth on my clients' behalf — what I am saying is that doing so damages your relationship. Plus, there's usually a way to tell the truth to your mutual advantage.
Have you ever lied on behalf of an IT consulting client? Tell me the truth.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.