A man walks into a website company, and the goatee-chinned chap behind the desk says: “So, you want a PHP subroutine to run a select join on your client tables and then do a mail send?” The man nods, but he doesn't really understand – and let's be honest, how much do you?

Shakespeare once wrote: “We understand everything we know, and everything else is fog.” *

The average man and woman in the street has no idea what the letters PHP stand for, or ASP, or PERL, or even HTML; and even if they did, they still wouldn't be any the wiser. They don't know the difference between SQL and MySQL, or Java and Javascript, or a Microsoft server and a Linux server.

We in IT work in a highly technical sphere, and technical talk is the lingua franca of that sphere. For the average Joe, IT  may as well stand for ‘Infuriating Technobabble', so we forget it at our peril.

People have a basic need not to look like idiots. Confronted by baffling tech talk, the average person will more than likely bluff it out, thinly grasping what is being discussed and nodding sagely when they think it's appropriate. Few will ever stop and say: “Excuse me, I don't understand that.

What can be worse is when people hear tech talk and actually think they do understand it, when in reality, they are wildly off course.

Either way, tech-talking to clients is potentially a cause for confusion, errors, and all manner of other problems further down the track – and, worst of all, it can lead to lost business. A confused client is not one readily pulling out their cheque book.

The problem is, IT people are ‘code switchers' – and I mean code switching in its linguistic sense. For example, the IT  person at the bank or in the supermarket talks to the teller or the checkout person in plain, everyday English. But back in the office, they switch over to the argot of computers and programming – because everyone else in the office is fluent. However, the typical client visiting the office either isn't fluent or, at the very least, has only a minor grasp of the terminology being bandied about.

This is not a call to dumbdown communications for the client, but simply to think about communication from their perspective. What do they want? They are interested in practical matters, such as whether it will work, what the end result will be, and when it will be ready. If a client wants to send out an emailed newsletter, don't explain the MySQL select query you plan to use; just explain what they have to do, which customers will receive the message, and when.

Try to avoid acronyms – most are meaningless to the average person (“CSS, isn't that a TV show?”). Also avoid talking about the programming and underlying code that runs a website; talk about what can be seen. A client is only interested in what it does.

And finally, if in doubt, think of your grandmother. If you were explaining it to her, would she understand you?

* Shakespeare didn't write that, but unless your sphere of knowledge includes a decent grasp of his works, you probably didn't know that, and you probably nodded sagely in agreement.