First some background. I work for an IT consulting company, and I have 15 DR's (all billable technical consultants). I've been in the industry for about 14 years, and the first 12 of those I was a billable consultant myself; I've been in management for about the last 2 years.

Mark and Mike have talked a lot about people in the IT field, and they're dead on. In fact the very first podcast talked about the challenges that many IT folks have building effective networks. That podcast hit very close to home, and much of the truths of IT folks that they spoke about, and continue to speak about (they mention IT folks frequently) is what I am struggling with now.

There is a big difference between working for an internal IT organization, and being an IT consultant. Some of my DR's "get it". They have been consulting for a long time, they are great in front of the customer, etc. However, some of my other DR's don't. They have worked previously within an IT organization and this is their first consulting role. They fit the classic IT stereotype: Email or IM instead of phone call, would rather stay in for lunch than invite a customer out, don't see the value of going to happy hour with one of our execs when they are in town (we work in a remote facility), etc.

Everyone on my team is a great technologist. But for some of them, their barometer of a successful engagement rests solely on the quality of the solution that we built for a customer, and not on whether or not the customer is actually happy. It's entirely possible to build a 'perfect' solution but the customer isn't happy because either we didn't manage the project well, didn't communicate well, just plain didn't provide good customer service, or any of a number of other reasons. On the other hand, we could provide GREAT customer service and only build a mediocre technical solution, but the customer is thrilled to death and wants to do more work with us.

An example is a customer that asks us to build an application that does "x". So a developer spends some time on it and builds an amazing product that not only does "X", but it also does Y, Z, and the rest of the alphabet. The developer demo's the product like a proud parent, happy as a clam at this marvelous product that he's just created. The customer see's it and isn't pleased at all. They didn't want the alphabet, they just wanted X. All of these other bells and whistles are going to make the product terribly complex and difficult for the end users, not to mention difficult for IT to manage. So the developer, feeling dejected, strips all of the extra bells and whistles and delivers the 'dumbed down' version to the client. The client is thrilled. However, the developer isn't. When the developer looks at the product, he doesn't see a product that meets the customer's needs; instead he see's a product that is only a tiny shell of what it could be.

That's very difficult for a technologist to grasp. I know because I've been there personally.

But I'm kind of going off in a tangent here. Here's the actual situation that I'm faced with. A customer hired us to migrate some databases. One of my DR's is onsite performing the work. The customer does not have expertise in this area, which is why they hired us. My DR lays out the plan and says 'let's do this, this, this, and this'. Customer says 'we can't do it that way, we have security policies in place that won't allow this. Find another way.' My DR says 'Every other company does it this way. This is the best way. Change your security policy".

I don't think I need to finish the story, you can see the problem already. My DR truly is correct in that what he is proposing is the best technical approach. To work around the client's security policies means more time, more money for the client, and ultimately doing it in a way that technically isn't a preferred approach. But that's what the customer wants, so that's OK. But he can't see that. To him it would be a failure; he would have to do the work the 'wrong' way. However, to the customer it would be a failure to do it the 'right' way, because that would mean breaching their security policies.

The problem that I have isn't about how to make him work through this particular scenario with this particular client. The problem is that I need to change his mindset. This will come up again and again and again with future projects and customers. I could look him straight in the face and tell him "customer satisfaction is more important than whether or not the technical solution meets your personal standards" and he could look straight back at me and tell me I'm wrong. He would say something like "my way is the best way and the customer just doesn't understand". And he's not the only one of my DR's with this mindset. And we have many more throughout our organization like this as well. And clearly this isn't just our problem, this mindset is common across IT in general. Our industry is traditionally very high C's and very low I's.

Sorry for the long post. Like I said, some of my team "get it" and have no problem here at all. But for some, it seems like nearly an impossible task to get them to understand, and believe, that customer satisfaction is more important to anything else. That may seem like a shocking statement but I'm sure those of you reading this that are managing technical resources understand this perfectly. It's almost as if I need to teach high C's how to be high I's.

In fact, anyone reading this managing technologists probably knew exactly what this post was going to say before you even read it :)

Any suggestions? How have others dealt with this?

WillDuke's picture
Training Badge

I know EXACTLY what you mean. The 2nd half of your issue, at least for me, is "What should we do about x?" My answer - "Explain the options to the client, and let them decide." I'm constantly reminding staff that we are consultants. Our job is to make clients aware of all the options and then let them decide.

You'd think this would appeal to a high C.

For me, it's all about setting expectations. When I hire someone we have a discussion. The first part of this discussion is present in the INTERVIEW.

"70%-80% of what we do is making the client happy. The technical portion of this job is definitely the easiest part."

Yes, I have to continually have this discussion. But it's always a reminder.

"Bob, can I give you some feedback? When you argue with a client about how to proceed you're not doing your job as a consultant. Remember we are here as part of their team to help them get the solution they want the way they want it. What do you think you could do differently?"
"But what they want is wrong."
"I understand that it might not be the best solution in your opinion, but it is what they want. Sometimes there are factors that they're aware of that they haven't told us about. As a consultant, we're supposed to help them get what they want. What do you think you could do differently?"

You get the idea. Often I will appeal to their creative problem solving side as well. Look at it as a challenge to come at this issue from another direction.

Other than that, go back through the members only casts and listen to the DISC casts, especially the C. There's some good stuff there.

juliahhavener's picture
Licensee Badge

I deal with a lot of technical people every day. My team includes 23 of them. A year ago, I had 14...when I got here, my director said, "I hired you 14 geeks, I sure hope you know how to talk to them, because I do not."

Luckily for him, I did.

I would really suggest discussing perception with your folks. As a technical person, I want it right. One of the hardest lessons I've ever learned is that "right" isn't right when it's not what the customer wants. It's all about the customer's [b]perception[/b] of what is going on. They are not technical experts. They are relying on you to build that bridge.

I've worked with my team members from very basic perception awareness (okay, you see it that way, how could someone else see it? How do you think this person might see it? That person? Someone without technical skills? Someone who knows this system inside out, but not yours?) to some fairly complex and long-ranging strategy items - how that plays out in terms of the perceptions of those around them.

I've been very successful getting my folks to buy in to it this way. Because now...being right doesn't matter. What matters is the customer's perception of right, which may be left, or it could be Albequerque. We don't know until we ask and then mold the product to fit that view OR mold that view to fit the final need.

I believe this has worked for me because it removes the value judgement of right and wrong/correct or incorrect and replaces it with the true customer value judgement...which I believe a consultant requires to be truly successful.

(I've been slow to respond on the boards and work is eating my time at the moment. If you have a question, pm me so I don't miss it!)