Leadership

Getting beyond the 'bull' perception


Once there was a cattle rancher who had a problem: his cows hadn't borne any calves for a long time. He hired various bulls to do the job, but even though they appeared to work fervently at their task, nothing was ever produced.

One day the cattle rancher met an old friend he hadn't seen for years. As they were catching up, he mentioned the difficulty he was having with his herd.

"Oh, don't fret another minute," his friend replied. "I've got a prize bull that will take care of everything for you. I'll bring him over just as soon as I get home."

Shortly thereafter, the bull arrived, and was released into the pasture with the cows. A couple of days later, the rancher called his friend on the phone.

"Hey, you remember that bull you brought over here?"

"Yep. How's he doing?"

"Well, I haven't seen him do a thing -- except he goes around to each cow and sort of whispers in their ears. After a few minutes he moves on to the next one, but he never does do anything more."

"Oh, well, he's not supposed to do anything -- he's a consultant!"

A colleague told me this story right after I started consulting. It made me laugh, but it also made me think. Full oft in jest have I heard truth, I say.

Regular employees often view consultants as outsiders who aren't part of the team, spout useless buzzwords, don't get anything accomplished, collect big fees, and leave the project in a mess for them to clean up. Not without cause: I've worked with several consultants who deserved that reputation.

When joining a new project, how do you overcome the natural resistance from other team members?

  1. Get real. Just because you're a consultant doesn't make you a higher being, so don't behave like it does. If you're on-site, dress like your colleagues. Eat with them. Joke with them. Make sure your work area and equipment is equivalent to theirs. Most importantly of all, cut the jargon. Your team members can see what you're really saying with all those buzzwords -- "look at how much I want you to think I know". Which is usually a cover for "I'm treading water", because if you know your subject you can express it in terms that anyone can understand.
  2. Get some skin in the game. Make sure that a well-defined part of the project belongs to you, that its success directly affects your compensation, and that your team members know that. They'll be much more likely to believe in your flight plan if they know you're not going to walk away from the crash site unharmed.
  3. Get on with it. Start producing. Hit the ground running. Beat your project deadlines. Team members will respect and welcome you if they see that you really can help them get the job done. Go out of your way to help team members become more proficient at what they do. At the same time, don't be condescending. Be willing to learn from your team members, and give them credit for their contributions. That will demonstrate that you aren't concerned with proving your worth to management at their expense. Make it plain that we're all in this together, and together we can get it done.

These are a few dynamics I've noticed when working with regular employees. How about you -- what would you add? Do you have any experiences of evil consultants to share as negative examples?

About

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 b...

20 comments
Locrian_Lyric
Locrian_Lyric

a consultant is hired to locate a problem. He arrives at the client site, walks around for 15 minutes, pulls out a piece of chalk and draws an "X" on a piece of machinary and says "There's your problem". A week later, he sends in his fee... 50,000 dollars. The company is outraged and demands an itemized bill. He responds with this. Bill: Materials : 1 piece of chalk $.05 Billing rate $400/hr .25 hrs work $ 100.00 Knowledge of where to place the "X" 49,899.95 If you're a consultant, you're payed for what you know more than what you can do.

apotheon
apotheon

That was an interesting cautionary tale. There's just one problem with the substance of the joke: Often enough, many corporate shops could really benefit from the advice of a consultant who does nothing but consults. Of course, such a person would be able to do more as a vice president, most likely. The problem is that without an MBA and at least fifteen years of management experience -- or a father-son relationship with the owner -- it's highly unlikely such a person would get a VP job. Well all know how well nepotism and an MBA qualify someone to make good decisions, I trust. All in all, however, you make some excellent points about the way "consultants" actually work in the real world, and how they should go about getting their jobs done. Sadly (or, in my case, gladly) I don't have any "evil consultant" stories to tell. I guess I've lucked into getting to avoid that sort of problem so far. The closest I've gotten to an "evil consultant" is being the next guy they hired -- so I never really saw what work the previous guy did (or didn't do) in any kind of useful context.

Sterling chip Camden
Sterling chip Camden

A long time ago (before I knew very much about the Windows Platform SDK) my client hired on a "WinAPI expert" as a consultant to help get the project moving. From day one, he was paranoid of the axe falling, so he kept making excuses for why things didn't work. Needless to say, his fears were soon justified. Granted, programming the Win32 API in C back in those days was pretty extreme -- actually it still is -- and we had to target Win32S as well, which made things even more interesting. But rather than trying to smokescreen your way through pretending to be an expert, better to admit what you do and do not know. He still knew a lot more than the rest of us did, and we actually learned a few things from him.

meryllogue
meryllogue

Isn't "what the consultant does" supposed to be part of the RFP? The whole "deliverables" section? If I hire a consultant to help me find the problems, know I am going to want to know how to fix the problems, and (possibly) use the consultant (or another one) to fill in expertise gaps in my internal team.

Sterling chip Camden
Sterling chip Camden

But it's also important that the knowledge shared actually benefits the project, rather than just sending it on a technology-du-jour wild goose chase. To do that, a consultant often has to get his/her hands dirty working on the details of the problem domain. Knowledge is fine, but how to apply it is wisdom.

alaniane
alaniane

People often perceive that a good manager needs to have an exhaustive knowledge of the field that he is managing and that he should be a star performer. In reality, a good manager needs to know how to manage the people working under him and the resources involved. However, try appointing a person who is not an expert in the particular field as a manager and the other members of the project team will revolt because they feel that the manager is incompetent. The same goes for outside consultants. They may know how to find the problem; however, if they do not actually do the work to solve the problem, then they will be viewed as incompetent. For most businesses and people, perception is more important than reality.

ShaneHo
ShaneHo

Isn't it a bit ironic to follow 'Most importantly of all, cut the jargon' with; "Get some skin in the game" and "believe in your flight plan" and "walk away from the crash site unharmed"?

Locrian_Lyric
Locrian_Lyric

Don't confuse the two. When you hire a consultant, you are hiring someone with expertese and knowledge, as in my example. The 'how to fix the problems' is the chalk "X". "Here's your problem, replace that part". If you have gaps in your internal team, you have a gap in training or staffing that you need corrected and should not be corrected by throwing warm bodies at the problem. If I'm consulting, I don't fix problems, that's what your staff is there for. You get the use of my expertese, not the expertese itself, not my body, soul or brain. The same is true for all consultants. If you want someone to fix your problems or fill in gaps in your expertese, hire another FTE or upskill one you already have.

apotheon
apotheon

Something that kinda mystifies me about the expectations of "consultants", though, is described thusly: 1. There's a problem nobody at the company knows how (best) to solve. 2. A consultant is hired. 3. The consultant familiarizes himself with the situation, then learns about and analyzes the problem. 4. The consultant prescribes a solution, based on his newfound familiarity with the problem and input from the client. 5. The consultant implements the solution at exhorbitant cost, despite the fact that once a prescription is developed the rest is usually just grunt work that could be done by an intern. Can you guess which part of this five-step consulting process doesn't make much sense -- for either the consultant or the client? Ultimately, it's as though the consultant is paid only for the grunt work, not for the knowledge and wisdom. It's as though Richard_RPU's consultant was paid for swapping out the part, but if he walked out after making the x-mark and they spent $20 on the part, swapping it out themselves in five minutes, he wouldn't get a thin dime. The real mystery here is that consultants [b]actually believe that's the way it should be[/b], at least most of the time -- often enough so that those of us who disagree don't have any recourse, because "that's just the way it's done". This is the sort of thing to which I allude when I talk about consultants just consulting. There are some cases where that sort of "just consulting" actually happens, but mostly these are only in scam niches like "process optimization" such as the efficiency experts in [i]Office Space[/i]. If the consultant got paid for knowing what to do, providing a general plan for the solution, and putting the x-mark in the right place -- maybe paid half as much as he would be paid if he actually did the grunt work himself -- he'd spend considerably less time per client, run less risk of being unfairly branded incompetent by a company that is looking for a scapegoat, and overall be much better off. Meanwhile, the client could just pay him half as much, then actually implement the solution at greatly reduced cost, ultimately saving gobs of money. It would overall be a significant benefit for all parties concerned in the majority of cases, in my experience. There are exceptions, and there are specific independent contractor fields where this approach couldn't really apply (such as when the expert knowledge involved is the simple ability to actually write the software in question, et cetera). All in all, though, I think consulting in general suffers from the negative consequences of the generally corrupted "property rights" ideas enshrined in law in Western democracies, where people expect to "buy" some kind of semi-tangible end product, rather than paying for the service they really need. If they're not "buying" some quantifiable, financially tangible solution "product", they figure they don't need to pay anyone for anything -- even if what's being offered up to (but not including) the point of implementing the solution is far, far more valuable than the solution itself.

apotheon
apotheon

Those are metaphors, not jargon.

Sterling chip Camden
Sterling chip Camden

I posted this before reading your last response. Seems like we're on the same page.

Locrian_Lyric
Locrian_Lyric

A friend of mine built a framework for a Y2K project, as well as templates that he tested on one of the admins. He was brought in as a consultant and the company didn't have any skilled programmers to add to the project. He identified the problem (lack of skilled headcount) designed a framework with that in mind, used his expertese to code the framework and templates and got the project out the door early. THAT is what a consultant is for. Now, had this been a usual consulting arrangement, they would have had him doing the grunt work.

Sterling chip Camden
Sterling chip Camden

... it's usually not that clear-cut a distinction. Software has many layers of abstraction, and often the consultant is the only one who can lay the proper foundations on which others can build. I generally don't write application-specific code, but I put a lot of hours into building frameworks and supporting class libraries.

Locrian_Lyric
Locrian_Lyric

I think there is a real issue in the industry with calling everyone 'consultants' as a catch-all term. A consultant is one who follows my example above. You've got a problem, nobody can fix it and nobody can even identify the source. Consultant walks in, spots the problem and says "You need to replace the network card on this machine, do nightly defrags on that one, reset the timeouts to ten minutes for this process because the default is five and from the looks of it, you're taking about six, ten should allow for additional mishaps and slowdowns" Now, if after that point you need people to impliment that, you would need either staff or a contract employee to do the work. To have the consultant impliment those solutions would be a waste of money on your part and a waste of time on his.

meryllogue
meryllogue

Perhaps there is a semantics issue fizzing in my brain.

Sterling chip Camden
Sterling chip Camden

I thought your comments were quite germane. I didn't respond to that part because I agree with it wholeheartedly.

apotheon
apotheon

In a world where the "tangible product" problem doesn't exist so much, one of the key skills of a consultant would be that of assessing how much of the actual implementation the consultant would have to do for the client -- and one of the key responsibilities of the client would be to pay for the extra work of beginning implementation [b]as extra work[/b]. Most of the time, simply identifying the problem and the necessary solution is not an option, in my experience -- but it is the best option a nontrivial percentage of the time (if I had to guess, I'd say it would have been the best option about a third of the time, but it's basically never a practical option because of the way business relationships work). Sorry about the wild tanget about "if I were king of the world", but it got into one of my pet peeves about things that just don't work the way they should in this business.

Sterling chip Camden
Sterling chip Camden

You're absolutely right -- the consultant should be able to draw up a plan of attack for others to implement. But I've often found it to be the case that my client was unable to execute the plan on their own. If I had left it at the prototype stage, the project would have failed and I would have been blamed. At a minimum, they needed for me to code up the guts of the solution, upon which they could then build (or mimic). And I agree that the notion of tangible property often obscures the recognition of real value. Ultimately, though, if the user doesn't end up with a solution that works (whether I actually code it or not), they paid for nothing.

apotheon
apotheon

It worked, as far as I can see. In my opinion there's no need to apologize.

Sterling chip Camden
Sterling chip Camden

Jargon is when you throw overused terms at your client in order to make them think you know what you're talking about. I used metaphors (that I don't think are overused) in order to add humor and hopefully improve understanding. If I failed in that, I'm sorry.

Editor's Picks