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

__________________

In addendum to #2 about small talk. I think you can gauge quite early on if they're a client who enjoys small talk. I'm not a big fan of small talk, but it's pleasant to get your clients onto a personal level. However! You have to be really careful not to get too personal with your clients as I just don't think it works. There's a sweet spot between getting close and keeping your distance that's perfect for business acquaintances.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

Nice article. Clients can be a real handful, from my own experience, I would also suggest not giving clients your personal MSN information, if you want to chat in real time, use another account.

__________________
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Some good tips there, thanks :)

Alan

Good read. Thanks for sharing!

Good tips; and kudos for mentioning spelling and grammar. Sometimes it's hard to take someone seriously when they've bad spelling and grammar, unless you already know they don't speak English natively.

__________________
Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So far the Universe is winning. - Rich Cook

Awesome article! I enjoyed reading the little part about big words haha

I'll be sure to have a little read up on your blog.

It made for some difficult reading! Even for someone who's rather exceptional at English, I found myself pausing for moments to convert some of the less common words to a meaning in my head.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

That part was down right fun to write. It took almost 45min, I had to go to the thesaurus so many times.

__________________

I actually understood most of it, although it did take me a good 5 minutes haha

I just had to nitpick, but you didn't say something FUNNY like "moolah" just to break the humdrum-ness of the "letter".

Though if I took the time to be that serious, I wouldn't say "moolah" either.

__________________
Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So far the Universe is winning. - Rich Cook