Assumptions play a lot in communications: If I try to say “Equality is good”, nobody really knows what I am talking about. For Equality, some people color this with “Equality of Outcome”, and some people color this with “Equality of Opportunity”: Race, gender, politics, justice, law, etc. are assumptions put into play just by invoking “Equality”. For “good”, some people will assume I am talking about the environment, some about personal well-being, those of my group, or just in general. Some may take good to mean “better than currently exists” or “the best possible”. Even the quality “good” is subjective: “Good” may mean to one person a lot of money, others the freedom to be their own boss, and still more just an adequate sleeping place and food. If I want anybody to understand whatever I meant by saying “Equality is good”, I have to reduce the assumptions dramatically so that everybody knows my thought or intent clearly. Without clarity, you can waste a lot of time, effort, and material going down the wrong path.

Getting your ideas across (or receiving ideas), whether it be a request, specifications for a task, or just transfer of knowledge, is not easy. The pitfalls intrinsic to communication apply equally to all types of communication. While this applies to all forms (Speech, written, or full audio/video), I will be mostly be giving examples of speech. The pitfalls include:

Not hearing what is being said correctly

Not having the same viewpoint

Disregarding at least part of what is said

Trying to “Win”

Putting all the responsibility on one party

Not hearing what is being said correctly: A United Airlines flight took off from Kahului destined towards San Francisco an Dec 18, with 281 souls onboard. The plane got to 2,100 feet before it plummeted to 781 feet above sea level before levelling out and resuming flight to the destination. After investigation, it turned out the pilot had requested the co-pilot to set flaps to 5 degrees. The co-pilot had heard 15 degrees and set to flaps to 15 degrees, leading to the drop in altitude. The pilot, not knowing the co-pilot’s error: assumed that the co-pilot had done what the pilot said.   The pilot spent a bit of time looking for the cause, before discovering the 15 degree flaps: If the co-pilot had confirmed by repeating what he/she heard, the pilot would have been able to clear up the error before it was implemented. In other words, this takes a conversation: By repeating back what you heard, you help clear this up. In other words, you need two-way communications. Also, whenever possible, avoid verbal orders.

Not having the same terminology or viewpoint: During a troubleshooting session, I was trying to assist a field technician in adjusting an HMI program on a PC, for a SCADA system developed years ago. I believed we needed to log off the Windows Operator account, and log onto the Windows Administrator account. The HMI program (SCADA) had its own operator and Administrator account, separate from the windows operator and Administrator login. I spent time trying to get him to log out the HMI program, and to log off the windows operator account, then log back on as Windows Administrator. Each time, the field technician reported success, without mentioning any problems. To aid this, I said things like “Log off SCADA”, and then “Log off Windows”. The field technician did not recognize that he was required to log off the Windows operator account. I tried to use the technician as a remote set of hands and eyes: I did not explain fully what the goal was, and he did not hear what I meant in the words I was using. The moral of the story is: Spend the time to define and clarify words, phrases, and intent before actually communicating what is needed.

Disregarding at least part of what is said: A boss gave me a task to take a third party-provided automatic vent (Damper), and use it to open only when the space got too hot. The damper was designed to open on both hot and cold extremes, and close when the temperature was within range. I read the manual, called the manufacturer, and went to some lengths to come up with a way to limit the functionality, to no avail. With this information, I went to my boss and said that the vent would open if it got too hot, and that it would also open if it got too cold: Should I install it with this problem? His answer was yes. The boss disregarded the part of the conversation where the damper functionality would not fit the task (I assume because he could not believe a third party would design a product that way). A few months later, after installation, he was notified by a field technician of this flaw. The boss acted like I had not told him months before. The best way to deal with this is to confirm using a second medium of communication, like E-mail: I should have sent a confirming E-mail to provide a different approach, or at least get a receipt that could be used at a later date.

Trying to Win: Communication failures will happen, and a lot of the failures are about assumptions. Some of the failures are not necessarily about the assumptions, but instead because not everybody wants to come to an understanding, or they want to assign blame after a failure: Some people just want to win. For these people, the problem is not about trying to communicate: It is about adjusting the factors of the communication, playing with the less defined portions, and/or asserting falsehoods. I will not give an example here, because most of my examples are “triggering” in one form or another. Most of these type communications provide a straw man, change scope, have a definition change, or bring up an additional set of factors that are not really relevant to the communication. For work, always get confirmation in writing before acting on a task.

Clarity in communication is ALWAYS the responsibility both parties. For example, I once worked in a place where the jobs used Basic, C++, Sequel Server, and various PLC manufacturer languages. A co-worker sometimes had questions about doing some of the work in the different languages, like “if-then” and “switch/case” logic trees, or “Do – While” loops. If a he asked different former colleague, he would get an answer for one language, and not fitted to the actual task at hand: While technically correct, the answer did not really help the co-worker. If the co-worker asked me, I would find the language he was working in and the functions he needed to code: Then I gave the best answer I could, fitting it to the environment he was working in.

I will admit there is a time cost associated with reducing assumptions. I assert, however, the probability of time, effort, and lost material cost increases dramatically when you communicate without clarity.