Good business communication.

This really isn’t a programming tip, but it is vital if you are a programmer. How you should talk to a client. I have learned this the hard way many times. And though all these tips may be good, USE YOUR JUDGEMENT! All clients are different; don’t do something you believe will be bad.

1. Grammar
Probably my worst, I don’t know where I would be with out MS word. You will not be taken seriously unless you spell everything correctly and your grammar is good. Most people you work with are not English scholars, so perfect grammar isn’t completely needed. Just make it the best you can.

2. Don’t engage in small talk unless they start.
Business is business, personal talk is personal talk. They generally should be kept separate. It just seems odd to have your programmer ask you how your day is going. Though, if the client wants to have a quick chat, do so if you have time. If you don’t have time or don’t want to, politely inform them you have work to do.

3. Don’t over-mention payment.
The price of the item you are working on was agreed upon when you started. The fact that you will be paid is implied. Try to stay away form mentioning it or it will give the client the impression you only care about the money. When the end comes and it is time to ask for payment, don’t use phrases like “Please pay me” or “Please send me my money”. Better to use “Please send funds to [place]. I will send you the files as soon as receive them”. It sounds less focused on the money and changes the focus to giving the client his files asap. Leaving a good last impression can mean a return client.

4. Don’t play the blame game.
It is not uncommon for a client to misinterpret what you say. When it was harmless I apologized for not being clear and continued. Was I unclear? I don’t think so, but to quickly resolve the harmless conflict I took it and went on. When the misunderstanding is of some significance, it becomes purely circumstantial. Don’t take the blame for what isn’t your mistake, but don’t blame them for your mistake. More not taking the blame for what isn’t your fault later.

5. Don’t use too many large words or complicated sentences.
Not to call clients stupid, but coming at your client with a barrage of large words that are sure to send them to dictionary.com is a bad idea. They will instantly take it as you trying to manipulate them into something. Or they will just think you are an idiot compensating with large words. For instance, you would not want to message them

Just say

6. Speak to them according to their tech knowledge.
Different clients have different knowledge of how programming works. Some of my clients are less experienced programmers and want to know how I am building it. Others don’t even know what a database is. Generally, don’t tell them the inner workings of the program unless they want to know. They hired you to make a good program, they should trust you. You aren’t a teacher, if they don’t know how anything works; politely inform them you don’t have the time to explain it. If they know what they are doing and want some insight into the program, just tell them.



Off of the polite tips, here are some tips for realistic communication in the event that blind politeness with get you ripped off.

7. Don’t take the blame for what you didn’t do.
If you make a mistake, take the blame for it. But if the client misread something that was clearly his mistake, it is his fault. If it has no impact on anything, just take the blame to avoid conflict. But if it affects something (another feature, something works different, ect), politely inform them the error is on their part and you cannot fix it for free. This is purely circumstantial, there is no formula to say if it is your fault or not. Decide objectively and fairly. Also include a clause in your policies that leave you as the decider of where things go in lack of detail.

8. Be as assertive as you have to, when you have to. But not more.
If a client is doing something that is wrong, inform them of that. I had a client some time ago that wanted something that he simply didn’t specify earlier. He was insisting it was implied; I eventually had to reply “No offense intended, but a reasonable person would not expect that to be implied. Since it was not clearly specified, I will not program that feature for free.” He was mad, but the project worked out and he did return later for more work.


You can find this and other articles like it at my Programming Tips blog

__________________