Going to the decision maker matters for the IT Pros and Developers too

When I was in sales, one of the tenants of making a close was driving to the decision maker.  Anyone who stands in the way is a "gatekeeper" and is just there to protect the decision maker, like the offensive line in football.  Jeke past the tackle!  Watch out for the tight end!

The reason for focusing on the decision maker is to reduce the number of times that you have to hear the organizational customer say "no".  You have to wait througn 7 nos to get a sale as it is, you don't want to hear "But now you have to talk with Mr. Manager."  You want a check written after you hear yes.  Therefore, get to the decision maker.  There are a bevy of methods to use to get past gatekeepers, and young sales trainees - such as myself years ago - learn them by heart.

What I am learning, as I delve deeper into the Software Architecture role, is that getting to the decision maker is just as important for the professional IT consultant.  There are just as many gatekeepers in the IT department of midsized companies as there are in the purchasing department.  These are even more subtle, too, if that is possible; they might even think (incorrectly) that they are the decision maker, but they are not.  Whe you are consulting for a company, and have the opportunity to garner additional project hours by solving a new problem, you are often the only person in the building who can bring the new sale to a close.

The problem is one of feifdoms.  Someone in IT designs a network, or manages a server, or writes a key piece of software, or configures some middleware, and they think that they own it.  They do all the work, they make all of the key decisions, so they must own it, right?  Well, no.  Especially when a decision impacts something else in the company.  Now, if they do something on company time and get overruled, it's not a big problem.  They grumble, turn it off or whatever, and all is forgotten.

But if you, as a consultant, do it on their OK and it gets overruled, you might not get paid.

Suddenly, getting to the decision maker seems like a really good idea, especially when pitching a new piece of work.  Here are a few tips from my experience to help you get past the IT Manager of the Fiefdom, and to the person who writes the checks.

  1. First, know who writes those checks.  It is tough to find the real decision maker in some firms.  Often, the functional decision maker is the IT manager, but they have a higher power in the CIO or CEO or owner who might know little about technology.  It is essential to get this person's buy in.
  2. Remember that gatekeepers are your friend.  Don't tick off the 'owner' of the target system just because they don't write the check.  Your case is so much better off if both you and the system manager go to the decision maker.
  3. Have an elevator message ready.  Often, you will find yourself at the coffee shop or wherever with the decision maker, and might be able to catch him or her for a minute before or after.  Have a compelling 30 second pitch ready that describes what you are trying to do.
  4. Remember to listen.  Don't just talk.  Sometimes no is no.  Sometimes you have a bad idea, and that is why you are being blown off.  Sometimes you are explaining it poorly, and that's why you can't make the close.  Listen to the feedback.

Finding continuing work as a consultant often requires sales measures.  You can depend on a recruiter to get you into a client, but you often have to keep yourself there.  Having a plan to get tot he decision maker will make that process smoother. 

Comments are closed

Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList