Coaching technologists to be consultants

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?