Knowing what to do. Being empowered to do it.

Back in the day, I did a fair amount of consulting.  I worked for a consulting company that made some very nice programs.  Some of our larger customers had their own software development teams.  So they didn’t want us to write their programs, but they wanted advice from us.  It usually started out like this:

Them: Have your developers ever experienced this sort of problem with your projects or processes?
Us: Yes we have.  It was painful.  We worked hard to overcome it.
Them:  Impressive.  Can you tell us how you did it?
Us: Yes, we would love to tell you about it (while we charge you hourly).  Of course, our circumstances are somewhat different from yours, so if you would like advice that will work for you, we will need to look at how you do things and suggest changes to your current process.
Them:  Here is a check, when can you start?

Most of those companies did pretty well, with the advice that we gave them.  It was very satisfying.  Unfortunately, we taught them our best fishing tricks.  Their problems were solved.  So we didn’t see much of them afterwards.  Occasionally, I will run into one of them, and they will say something like “Thanks again for that advice.  We still use it.”

In contrast, there were a few places where things didn’t go so well.  You could usually spot those places right away (after you knew what to look for).  Those places were usually interested in placing blame.  They also had a truckload of reasons why they could not change.  Every idea that we came up with, was shot down with either: a) we already tried that and it doesn’t work, or b) no, we can’t do that.  Are you ready to concede that this place cannot be improved?  No?  You will.

Most of the time, when I was brought-in to fix things, the customer already had their head in the right place and had already committed to change.  So, it was rare to meet with any kind of resistance.

The other kind of consulting

However, there were a few times when we needed to pay the bills, so I did a little of the other kind of “consulting” (where I simply do the work and don’t talk about methodology or other interesting topics).  Things were very different on those projects.

It can be pretty painful when you are on a dev team and you can see the team suffering from a series of symptoms.  If you know the solution to the problem, you want to help.  However, it really aches when you offer to help, and then instead of receiving gratitude for your insightful advice, you get treated as if you were some clueless dork.  They don’t recognize that you actually have good advice.  You are aghast, and even a little miffed by the curt response and short-sightedness.  Yeah, it burns inside a little.

Probably, the biggest difference between the two circumstances is “authority”.  A close-second would be the attitude of the customer.

The occasions when I came through the door as a (real) consultant, the customer was usually ready to change.  They recognized that they had a problem (which is the first step in solving a problem).  So, when I walked through the door, they handed me the keys to the kingdom and said “fix it”.  If I didn’t always get the cooperation I needed, then I had a little chat with the person in charge, and acquired the cooperation that was needed to fix things.

In contrast, when I came in the door as a mere programmer/dude, I had no authority to do anything beyond simply sitting in a chair and pushing a mouse.  When/if I suggested some changes that would make the process work better, the leader usually let me know how they felt about unsolicited feedback. I would get a quick reminder about knowing my place and then I zipped my yap and went back to doing my job.

Why The Resistance?

As far as I can tell, the biggest reason that people will reject good advice comes down to this:

  1. Talk is cheap
  2. Getting stuff done takes significant effort
  3. Change is hard and requires a lot of discipline
  4. Change also introduces risk
  5. Plus, there is the whole “fear of the unknown” thing

Combined, these create a pretty big barrier that prevents a manager from trying every good idea that comes along.  They usually have the bandwidth to only try one or two good ideas.  If they can’t tell which ones are good or bad, then they take advice from somebody that they can trust.  If they are distrusting (in general), then they don’t take any advice and might even do the opposite of anything that is recommended (because golly, it might just be a trap).

At the-end-of-the-day, your real goal is to provide a value to whomever is paying you.  If you can’t do the right thing (according to you), then work on building up some trust and at least make sure that you are doing the (other) “right thing” (according to the guy with the checkbook).

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Career, IT Psychology, Lessons Learned, Professionalism. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s