A prospective client describes the problem domain. It seems easy enough for your abilities, and your consulting fees aren't an obstacle. You're already counting the money you're going to make from this IT consulting project, when the client says: "Oh, and we use <technology X>. How well do you know <technology X>?"
The answer that wants to jump off your tongue is, "Oh man, <technology X> and I go way back. Why, I even invented a form of <technology X> before it became popular. No problem."
But the truth might be closer to "I read something about <technology X> once on a blog, um, somewhere -- and I thought something like well, that's nice, but what would you ever want to do with it?"
So, what answer actually comes out of your mouth? Something in between? I thought so. Me too sometimes... in the past... a long time ago.... Honest.
Little white lies = big trouble
There are good reasons why you don't want to stretch the truth. Beyond the fact that you don't want it on your conscience that you are lying to your client, there are four practical reasons why these little white lies can turn into big problems.
- You're going to have to spend a lot of your own time getting up to speed on <technology X>. You won't be able to bill for that time because you already said you know the technology. If you had told the client you didn't know the technology, they may have offered to fund your research.
- You'll be looking over your shoulder all the time to see if your colleagues notice that you really don't know as much as you said you did. This uses a lot of unproductive energy and strains work relationships.
- You won't be as likely to ask questions when you need to because you'll think that's something you're supposed to know. Every project has unknowns and asking questions not only sorts those out, but it also raises issues that might not have otherwise come to light. There are no stupid questions -- only stupid IT consultants who don't ask questions because they're pretending to know more than they do.
- As a newbie to <technology X>, your first product using it will very likely suck. Well, even if it doesn't suck, it won't be as good as the product you could produce with more experience. If your client thinks, "This is what our <technology X> expert created?!?" then you can kiss that follow-up business good-bye.
What's behind the pretense?
Are IT consultants sometimes tempted to lie because of the ego suppression required to admit our ignorance, or are we afraid that we won't get the contract? I think it may be a combination of the two. It's easy to think, "Oh man, if I don't know <technology X>, I must not be much of a consultant after all. There's no way they'll hire me."
A confident consultant who has some experience will think, "I'm good at other things, and I'm sure I could learn <technology X>, too. Maybe I can sell them on that, but if not, perhaps it's for the better. And maybe I ought to look into this <technology X> for future gigs."
And you could always propose <technology Y> instead. How well that suggestion flies depends on how deep the client is into the project and how religious they are about <technology X>.
Do you ever oversell your skills?
I came clean about my past transgressions, now how about you? Do you ever stretch your experience and fake it till you make it? Or do you always give your prospect a straight-up assessment of what they can expect from you?
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.