5 Ways to Make Technical Conversations Easier for Your Non-Tech Peers
Have you ever spent 5 minutes in a meeting trying to explain a technical issue and by the end of it, someone looked confused and said, “Sorry, I don’t get it.”? If you have, then you have encountered a form of poor or ineffective communication.
As an engineer, one of the most important soft skills you’ll need is communication. By perfecting your communication skills and making them more effective, especially when speaking with non-engineers, you’ll be able to take your engineering career to the next level. Let me give you an example. This is an example of a conversation between Steven (engineer) and Okta (non-engineer).
We can see from the example above that there is no connection between Steven (speaker) and Okta (receiver). This conversation will usually take longer than expected, causing some people to become frustrated, which is not a good thing.
Wikipedia defined communication as the act of developing meaning among entities or groups through the use of sufficiently mutually understood signs, symbols, and semiotic conventions. The examples I gave earlier are still examples of communication; however, they were ineffective because the target person (or non-engineer) was unable to understand the information that was being delivered.
To communicate effectively, we (the sender) must present or deliver information in a way that is most easily understood by the person to whom we are speaking (receiver). Let’s revisit the conversation between Steven (engineer) and Okta (non-engineer), but this time we’ll make some changes to make it more effective.
Have you noticed the differences? In comparison to the earlier conversation, which talked a lot about HTTP, the example above is more concise and short, and I believe you already get the idea of the problem that Steven (speaker) wants to explain.
The next question is how we, as engineers, can communicate effectively with anyone, including our non-engineer colleagues. There are a few things we can do to accomplish this, but first, let’s clear up a few points.
Communication consists of 3 core elements: the speaker, the message, and the listener. The person delivering or presenting the message is known as the speaker, then the person or people who have gathered to hear or see the message is referred to as the listener and the message is a piece of information or ideas that the speaker is presenting to the listener on a specific topic. I hope this can make understanding the article a little easier as I will use these terms a lot.
Let’s go!
Change Your Perspective
You must put yourself in the shoes of the person you are communicating with to communicate effectively. This is significant because it will assist you in determining what message you need to create before speaking with the individual.
For example, if the person you’re speaking with is a product owner with limited technical knowledge, you may need to tailor your message to make it more understandable. Feel free to use technical terms during the conversation if the person is an engineer with extensive technical knowledge.
If you already know the person, shifting your perspective may appear simple. The next issue is what would happen if you didn’t know the person or were conversing with them for the first time. Take a look at the following conversation between John (engineer) and Mary (newly joined product owner)
This is an example of John assuming Mary knows about the Acme API, which she does not because she is new to the company. In this case, the best rule is to “Don’t assume, always ask.” It means that if we are having a conversation with someone we have never met before, it is acceptable to ask them questions frequently in order to gain their perspective.
Let’s take a look at a previous conversation and see how the “Don’t assume, always ask” rule can help improve communication.
The example above provides John with a better understanding of Mary’s perspective in terms of her knowledge, which he can then use to craft a more appropriate message to ensure that Mary understands what he is saying.
More Action Less Code
We sometimes explain issues with our software by describing the code literally because writing code is our day-to-day work. This is fine when we’re speaking with another engineer, but we also do it with our non-engineer coworkers on occasion. Consider the following exchange between Anne (engineer) and Claudia (project manager).
Anne explains the problem in the example above by revealing the code that caused the problem. This is not incorrect, but Claudia is having trouble understanding the message because he is unfamiliar with the code.
When speaking with a non-engineer, we can address this problem by concentrating on the code’s action rather than the code itself. This is because anyone can understand action, but only engineers can comprehend code. By focusing on the action rather than the code, we can have more effective communication in the conversation earlier.
Even after focusing on the action in the communication message, we may introduce technical terms that are difficult for non-engineers to comprehend, such as complex functionality flow. If this occurs, it is acceptable to simplify the message as long as it contains the essential information that we want to convey to the recipient. Let’s take the previous example and simplify it.
Can you spot the differences? The message is now shorter but still conveys the important information Anne wants Claudia to know, and she is aware that there is a problem without knowing the technical details.
The Simpler, the Better
There are many terms in the technology field that are difficult for non-engineers to understand, and it is our job to translate these technical terms when we want to craft a message during a conversation, especially if the listener has little technical knowledge. Consider the following exchange between Akmar (engineer) and Nigel (non-engineer).
In the example above, Nigel is perplexed by the term “Bcrypt,” a technical term he has never heard of. We can replace these terms with a more general one that a non-engineer can understand to make communication more effective.
The disadvantage of translating technical terms into simpler terms is that it may reduce the amount of detail we want to convey to the listener. As engineers, we know that “Bcrypt” is a hashing algorithm, but “algorithm” can refer to anything. This is fine, though, because we still deliver a message that contains the essential information we want to convey and that the listener can understand.
Always Try to Satisfy Curiosity
Curiosity is one of the reasons why people usually want to know and understand the new terms introduced to them in the workplace, and we, as engineers, must take advantage of this behavior to educate these individuals. This may appear to require a significant amount of effort, but believe me when I say that it is more of an investment for the people. Because it will make future communication with these individuals much easier.
In the previous example, “Bcrypt” is a new term for Nigel, but if Akmar can teach him about it and he understands it, it will be useful information for him. In the future, Akmar and Nigel’s communication will be more effective, especially when it comes to password hashing algorithms.
You won’t be able to educate your listener on a certain topic without first gauging their level of understanding. If they have beginner-level knowledge, don’t talk to them on an intermediate level. Take a look at this example conversation.
Could you spot the issue from the example above? Sure, Akmar has already translated the technical terms into simpler ones, and he even went out of his way to explain “Bcrypt” to the listener. However, the flaw in this conversation is that Akmar is attempting to give Nigel a 5-minute presentation, which Nigel, as a non-engineer, finds difficult to comprehend, causing Nigel to become confused as a listener.
When you, the speaker, recognize that the topic at hand is complex or will take a long time to explain, the responsibility to break it down for the listener is yours. Communicating is like eating a huge melon — you don’t eat it whole, you cut it into smaller pieces first.
Even though the conversation above appears to be lengthy, it is still considered effective communication because the speaker (Akmar) is able to communicate with the listener (Nigel), and the message is understood by the listener. Keep in mind that just because a conversation isn’t brief, doesn’t mean that it’s ineffective.
Did you notice anything unusual in the example above? If you pay attention to the conversation, you’ll notice that Akmar (the speaker) is constantly asking Nigel questions to ensure that he understands the message. When you’re breaking down information into smaller chunks, you’ll need to do this, because we have to make sure that the listener understands every chunk of information we gave to them.
Another important thing to remember when teaching someone something is that it is acceptable to repeat the explanation if the listener requests it. We must understand that when it comes to absorbing information and storing it in memory, everyone has different abilities. Some people may have a quick process, while others may not.
Communicate Visually
When it comes to more complicated subjects, you might want to use your drawing skills to represent the information. Because most of the time, it is easier for people to process information visually rather than speech or text. This doesn’t imply that you should draw the visual aid yourself; you can draw with anything, have someone else draw it for you, or use simple tools you can find online.
Take a look at this conversation between Jane (project manager) and Andy (engineer) as an example.
Jane has a hard time understanding Andy’s flow simply through verbal conversation, as shown in the example above. What if Andy drew a diagram flow that looked something like this:
As you can see, there are no changes to the flow, but it will greatly improve the listener’s understanding process. This is particularly useful in an era when companies rely heavily on remote communication.
When it comes to tools, I believe there are numerous options for representing your message in an image or picture. Personally, I like diagrams.net because it can sync with Google Drive, and I also like mermaid.js because it allows you to create a diagram with code. Finally, you can draw with any tools that you are familiar with.
That is all there is to it. This is the last section of the article. I hope that after reading this, you will be able to improve your communication skills and communicate effectively with non-engineers on your team. Please leave any questions or feedback in the comments section. See you!
