I often read great blog posts about good ways to communicate, but articles about knowing if or when you are communicating poorly are harder to come by. I’d like to talk about ways to identify and improve poor communication, from the perspective of the ‘unit test’.
In software development, a unit test is an automated way of ensuring good code. A piece of code is written which regularly checks another piece of code for proper functionality. Once the test is confirmed to be correct, it is not changed. As a result, whenever changes are made to the software, the test can be run to ensure that the code still runs correctly. The process of unit testing is like checking your car’s oil. The oil may be okay most of the time, but it’s a good habit to check it regularly because if anything is wrong, you want to know. In unit testing a test goes ‘red’ when it fails. It’s a visual indicator that something is wrong with the code. While I cannot expect to see a flashing red light anytime I fail at communication, (that would be pretty weird), there are ways to know when communication problems are cropping up.
So, what can I do to ‘unit test’ my communication? How do I know if I’m communicating effectively, and what do I need to do when I find out that, despite my best efforts, I’m not getting my point across? Whether you’re working remotely or sitting at a desk next to your teammates, effective communication can be achieved. Here are some ‘red flags’ that you can use to know when there is a problem.
Expectation Management
The first red flag has to do with expectation management. Expectations, and how we deal with them, are a vital part of teamwork in any scenario. The first time you get into a conversation and a boss, client, or team member tells you something along the lines of, “I thought you were going to do….” you will understand what happens when expectations are not properly managed. This often leads to frustration and can result in anything from wasted effort to termination.
The basic principle here is that bad expectation management is almost always caused by a failure to communicate. When this happens, people are left without a proper understanding of what needs to be done, and work on a project can slow significantly or even stop. Even worse, people can end up working towards the wrong goal or teammates can find they’re taking the project in different directions. For example, if one team member works on creating a login screen while another works on messaging, the team could end an iteration with a product that doesn’t having working messaging or login. In a worst case scenario, the client may not have wanted either of those tasks implemented yet.
If at any point you find that you are unsure what is expected of you or your team, it needs to be fixed. Simply put, when you find expectations have been mismanaged, assume communication failure, assume any responsibility that is yours, and work to correct the issue quickly. This is the first step in fixing any communication issue: Take ownership of the problem and work to correct it.
Repetition
I don’t like repeating myself. Nobody does. Sometimes repetition can be good. There are numerous examples such as when setting up a new project or teaching a task with multiple steps. You may need someone who is helping you to repeat some of the procedure. Listen carefully and if you still find yourself stuck, repeat the parts of the process that you do understand. This way, the teacher repeats less and can more easily determine what parts you may be having trouble with. For the most part though, continuous repetition is a ‘red flag’. Time is wasted and communication is ineffectively handled if we keep repeating the same information over and over.
A good way to deal with this problem is to create a shared information resource (something like a wiki or even an email). When knowledge is shared across a team or company, anyone who needs to can review the information when it is convenient for them. This means that repetition is reduced and overall understanding goes up. Productivity also increases as people are able to find the answers to frequently asked questions on their own.
Still Confused?
A different issue occurs when, despite something having been repeated multiple times or an information source having been created, there is still confusion. This is another red flag. A possible source of confusion in this case might be people’s differences in background, skill-set, and technical knowledge. Differences such as these can cause each member of a group to hear or read the same exact thing multiple times and still get different information. A good rule of thumb here is that when you think something is obvious, it probably isn’t for the person with whom you are communicating.
How do we deal with this? Ask the necessary questions: What about the way you are communicating with others is causing confusion? What do you need to explain in more detail? This is not disrespectful and asking should be done with tact. The bottom line is if we’re not seeing eye to eye on something, it’s possible one of us doesn’t know as much about the issue as the other. Once that has been determined, a good team will work together to determine the resources needed in order to help each member understand. For instance, if your team is explaining a technical problem to a customer and receiving only confused looks or blank stares, it is a good idea to pause and evaluate the situation. Perhaps your client is not technical and you need to break concepts down into smaller pieces, find a visual, or maybe even try to simplify it by just summarizing the problem.
Asynchronous Communication
Another ‘red flag’ arises when asynchronous communication, such as chat, texting, and email, causes confusion. Asynchronous means that when a message is sent, it may not immediately be seen or acknowledged by the recipient. When using asynchronous communication, it is good practice to follow up on the message if it has not been acknowledged within a reasonable amount of time.
Like many, I have plenty of emails in my inbox that I’ve only skimmed. This is not the best practice, but it isn’t always practical to read every word. I know that others have the same issue and when something is important enough, I like to touch base on these kinds of messages again to make sure everything is clear. Good communicators both patient and tireless.
Consistency: Every Single Time
At this point you’re probably thinking something like, “Matt, there isn’t really anything groundbreaking here.” And you are right! I’ve given a few examples of ways you can detect communication issues and some thoughts on how to solve those specific issues. An exhaustive list of communication problems would take more than any single blog could cover. With that in mind, we should always look for ways to ‘test’ our communication and resolve any issues that arise as quickly as possible.
Communication failure is so often the root cause of a problem specifically because we don’t think it will be. We know what we want to communicate, and it’s easy to assume that once we’ve sent a message or said what we felt was needed that’s that!
As a developer I know how easy it is to receive requirements from a customer and make assumptions based on those requirements that are wrong. This is why ,once I’ve seen the requirements, I always discuss them with the client to make sure I fully understand what they want. As the development proceeds I test and test again, communicating with the client and making sure that I’m working towards the goals they’ve set. I always want to test my assumptions and get rid of the ones that are incorrect quickly. This process seems so obvious, and yet I haven’t always been careful to go through it when dealing with other types of communication.
The ‘red flag’ here is the assumption that you and the person you’re communicating with are on the same page. Maybe you are, maybe you aren’t, but keeping an open line of communication and regularly checking up on things is the only way to ensure that you both continue to understand each other.
Some Final Thoughts
You can’t always know if you’re being understood by everyone. This is where the real work comes in, just like it does when trying to create good code or do a good job of any kind. Consistency, a willingness to learn, and effort is always required. Communication is no different.
You cannot automate good communication, but you can test it. You can create good habits that help you ensure both that you’re understood and that you understand those you’re working with. Good communication habits, like good tests, will help you know when there is a problem and help you solve it.
