Why you should talk to tech people

Lately, an old and regularly discussed subject has resurfaced on the Internet once again: at a software development company, should technical people be allowed to talk to customers, or should that be done by sales people? In this article, I will give you my take on the subject.

A while ago, I had such a conversation with a customer. For those who don’t know, I am a technical person, a real technical person. Despite that, I do have some conversational skills and from time to time, you might even call me social. Anyway, how did that conversation go? Did it go smoothly? Did we understand each other? Did we agree on various subjects? And the most important thing: was the client happy in the end?

To start off with the first question: no, it did not go very smoothly, especially in the beginning. Being a real technician, I started to ask why he wanted what he was asking for, what the underlying purpose was and finally I told him that he shouldn’t want what he wanted at all and that he should go into a different direction altogether.

The client was startled, to say the least. He expected someone who didn’t give him a hard time, who understood what he asked and just delivered. Instead, all of a sudden, the client was forced to rethink his entire plan.

I have been on the client side myself too, when it comes to technology. On one such occasion, when I was buying some hardware, I was talking to a real salesman. He knew a thing or two about the things he was selling, but mainly his job was to get the potential customer to buy their needs at his company. At first, I felt comfortable talking to him. He was nothing like the notoriously aggressive and commercial salessharks, no, this man was really trying to help me solve my problems. But as time went on, the number of questions that he couldn’t answer kept growing. At a certain point, all he was telling me was that he would "consult the tech department" with my questions. He really became a redundant link in the chain. He also never suggested something different than what I asked for, while, in retrospect, some things I asked for were not exactly the best solution.

I think that this is one of the biggest drawbacks of non-technical middlemen: They can’t answer all of the client’s questions and, maybe more importantly, they don’t know which questions to ask the client. The client knows a lot about his or her core-business, the technical person knows a lot about technology, but what does a middleman know?

Another mistake that is often made by non-technical salespeople, is that they promise the client whatever they want and they tell them whatever they want to hear, only to have to retract all these promises at a later stage, when the technical people tell them that it cannot be done.

When you talk to a technical person, communication might not go as smoothly, you might need more time to get to understand each other, but when you finally do, you are absolutely certain that the things you agreed upon, the things he or she promised you, can and will be done. I think this answers the second question. It took us longer to understand each other, yes, but the understanding that we finally achieved, was worth so much more.

This brings us to the third question, did we agree on various subjects? I am not talking about price and contractual obligations here. I am talking about the actual project subjects. This seems strange, doesn’t it? Agree upon things? What’s that all about? Shouldn’t the supplier just deliver what the client wants? Isn’t the customer always right? No, he is not. Sometimes, the client doesn’t know what he or she wants, or sometimes they want the wrong things and I see it as my duty to help them shape the outcome of the project and to correct them where needed. After all, that’s why they come to me, right? I am supposed to be the expert on the subject.

Technical people in particular are able to show different approaches and solutions to a customer. Where a salesman always takes the demands and questions of a customer as a starting point, a technical person is able to take the final goals, purposes and targets of the customer as a starting point and then to come up with a modified or completely different solution than what the client asked for. Technical people are just more creative in this area and this is very important, because a project that has a flawed design, will never satisfy a customer.

After all this, you might want to ask: "If communicating with technical people has so many advantages, then why do most software development companies still have salespeople, accountmanagers and other middlemen?" I can counter this easily, by asking: "Why do so many IT-projects fail?"

Of course, the client must be willing to invest some extra time and effort. If he just wants to hear that everything is going to be all right and the end result is going to be great, then he shouldn’t complain when in the end, things don’t look as rosy as they did in the beginning.

I must make two reservations, though. Letting technical people do all the talking can also have its drawbacks.

First of all, they exist. Those socially impaired geeks who are brilliant at programming, but just can’t communicate. Of course, you should never let them talk to the customers. But not all technical people are like that. In fact, those nerds often have lots of trouble fitting into a team, so although they do exist, you usually don’t find them in development teams where people have to do lots of communication. Mostly, they reside in the basement in the systems administration department (IT Crowd, anyone?)

And secondly, the decision to let the technical people do all the communication with the customer can drive the programmers crazy when the customer calls every single day with all kinds of trivial questions. Programmers are at their most productive when they can work uninterrupted for long periods of time. So, during the design and development stage, communication should definitely be done by technical people, but once the system runs, the technical people should be somewhat shielded from continuous interruption. This does not mean, however, that you need accountmanagers or salespeople after all. You could, for example, require your customers to only communicate via email if they have a non-urgent question, so that the technical people can respond whenever they see fit, albeit within a reasonable timeframe, of course, for example two days. You could also employ a separate support department, that handles all trivial questions and forwards the rest to the technical people.

So my conclusion is that in the end, letting technical people do the communication with the client is definitely the way to go. The extra initial investment will definitely pay itself back later on and both developer and client will look back on the project with satisfaction.

Oh, and as for the final question: In the end, the client was one of the happiest clients I’ve seen in a long time.