X +
Blog > September 2013 > The Human Element of Miscommunication – Part 2

The Human Element of Miscommunication – Part 2

18th September 2013 - Emerson Sklar

“Half a league, half a league, Half a league onward…”

So begins the classic poem by Alfred Lord Tennyson describing the ill-fated, eponymous Charge of the Light Brigade at the Battle of Balaclava during the Crimean War. Rather than charge into unsuspecting (and vulnerable) naval gun battlements, an assumption of vocal acuity and an errant wave of the hand caused Lord Cardigan to lead 670 men into an area afterwards dubbed the “Valley of Death.”  Almost half the cavalrymen engaged were lost, all because of something that could have been averted with a simple request for clarification.

With such vibrant morbidity fresh in your mind, and without further ado, that brings us to the topic of today’s discussion – types of miscommunication.

While my distinctions may differ from the traditional, I have found miscommunication in the technical world to typically fall into one of two categories:

  • Improper information volume
  • Misunderstanding

*It’s important to note, by the way, that I do not consider things such as plain lack of subject matter competence or willful disregard of the information provided as types of miscommunication. No amount of explaining will help a child to understand plasma physics, and as the saying goes, you can lead a horse to water….

Improper Information Volume
This situation can occur when the relaying party does not properly understand the level of information sharing necessary to properly empower the listener to achieve his or her goals, and is further broken down into hypo- and hyper-communication.

Let’s imagine that I am a project manager tasked with creating an instant message program. If I meet one time with my developers, inform them I just need some sort of program that can enable me to chat with other users, and release them into the programmatic wild to implement my request as they see fit, I may not have adequately conveyed my expectations and desires for this project.  Without properly filling my directorial role as a project manager, my developers may then spend a few weeks toiling away, trying to discern exactly what characteristics and requirements such a program would need. If I had instead formulated deterministic and measurable requirements for this endeavor and provided them to these developers, I could have saved them a tremendous amount of time and money performing unnecessary tasks. This is a classic case of hypo-communication.

On the opposite side, let’s say my developers perfectly understood my complex requirements from the beginning, but I nonetheless require them to attend a solid week of meetings before unleashing them to actually begin work.  Furthermore, we structure our schedule such that we spend an hour at both the beginning and end of every day providing status reports, talking about any challenges or issues we are facing, and reevaluating the current progress of the project. In this case, not only are we spending so much time focusing on other things that we are impeding actually accomplishing work, but we risk clouding the original communicated  intent of the project through information overload. This course can prove just as disastrous, both in terms of monetary cost and project success, as providing too little information and is a great example of hyper-communication.

Misunderstanding occurs when the sender’s message is not comprehended as intended by the recipient.

Let’s first look at a simple example – I used to be a part owner in a video game company, and I determined one day that my website would be better served by a green background than its (then) current red one. I contacted my web developer; she implemented the modification; and I logged back on to the site the next day and beheld a hue somewhere squarely between mashed peas and ectoplasmic slime. I contacted the developer again, insisting she misunderstood my intentions (a fault for which she could not be fairly held accountable), and demanded she change it to a much more vibrant color. I logged back in the next day, and was presented with a site festooned in Tron-like neons so bright they could be seen from the international space station. In frustration, I had her revert to the old red color scheme and absorbed the cost of two days of wasted productivity.

Now, let’s revisit the instant message program from before. Ignoring the issue of communication volume, let’s say my main stated requirement was to have something just like Google chat.  A few weeks and several thousand dollars later, my developers return with a program that does just that – lets me send a message from my machine to another user of the system. However, we’ve all used chat programs in the past – most facilitate some sort of group chatting, file or image transfer, historical conversation logging, and authentication. I had assumed (a key word, and one which we will return to later) that all would understand that any chat program would obviously need this kind of functionality, but failed to expressly communicate those assumptions. My developers assumed, just as improperly, that they properly understood my requirements as I intended to communicate them.

This is far more dangerous than the first examples of miscommunication – while it may be obvious to all involved that meeting once for a month-long project is inadequate, it is much more difficult to recognize instances where both parties think they’ve properly understood and been understood  - that they are “on the same wavelength” - and don’t realize their errors. Unfortunately, this is also something that is becoming more and more prevalent, with the increasing frequency of purely digital work relationships as well as technical outsourcing (where a language barrier may be an impediment).

Both of these cases arise from a lack of understanding of the common ground between both parties, and both can be traced back to the Principle of Parsimony. Also known as Occam’s Razor, this states that the simplest of two possible paths is often the better one. As such, we constantly walk a fine line between trying not to waste our time and trying not to waste our listeners’ time – no one wants to spend hours returning to their superior asking for clarification about something that should have been simple, and similarly no one wants to spend hours explaining something repeatedly which should have been understood the first time. There is no formula for the perfect amount of time to spend on communicating an idea, nor is there a formula for the perfect way to communicate it such that the listener understands correctly. Luckily this is no Sysiphean task we have undertaken, and clear ameliorations are in sight.

So tune in to the next episode, where we will discuss ways to combat this costly foe and look at the path towards our Eden of understanding.


Requirements Management

Emerson Sklar
Solutions Engineer

Technical Account Manager at Micro Focus, Emerson is a computer scientist with over 5 years’ experience developing high-quality, robust software.



Blog post currently doesn't have any comments.