When it comes to hiring or promoting a software engineer, communication skills can be used as the tie-breaker between two equally talented people.

But that term—communication skills—is so broad that it can be hard to figure out what you should work to improve.

Here’s one aspect of communication skills that is highly valued and easy to improve: your ability to explain a technical subject to a non-technical person.

Why is this valuable?

Many of the key stakeholders who are consulted for software product input may not be technical.

End users are often experts in the domain of the software product, but that doesn’t necessarily mean that they are “technical.”
The senior management team that approves funding or budgeting likewise may not be technical.
Immediate members of the team such as Project Managers, Business Analysts and Technical Writers may be highly skilled in their specific jobs—but also not technical.
Somebody on the team needs to be able to communicate with these stakeholders. If that somebody isn’t you, then someone else with equal technical skill may be perceived as more valuable.

What does this consist of?

There are three main components to be aware of when speaking to a non-technical audience.

(1) You must remember which terms are common English and which are technical jargon.

Like professionals in any industry, software engineers become so familiar with the language of their work that they forget what is and isn’t jargon.

For some perspective on this, think of the last time you went to a medical specialist. How much of what you were told went right over your head? Did they refer to parts of the body by their Latin names or their common names? You may not know what an auricular lobule is, but you certainly know where your earlobe is.

There isn’t anything wrong with your doctor using the formal Latin name as long as they immediately translate it into the common English—or explain what and where the body part is.

Awareness of your own industry’s jargon is a great place to begin improving this area of your communication.

(2) You must develop a mental technical-to-non-technical translation device.

Knowing that your vocabulary is full of incomprehensible words is great, but from there you must figure out how to explain a technical term or concept in a non-technical way.

This translation effort is just that—an effort.

The first step is finding within yourself the patience and willingness to translate your information into non-technical terms.

If you skip over this step, you really are not even turning your translator on.

The second step is figuring out ways to explain often quite complex concepts in lay terms. Sometimes this means simplifying the concept, i.e. sacrificing some of the nuances of it. Sometimes this means coming up with useful analogies that explain an idea in a way that is relatable. Sketching something out is often very useful.

Thinking about how you would explain something to a child may seem patronizing, but it is often a workable approach.

(3) You must realize that communication is always two-way.

Speaking of patronizing, it’s easy to misjudge your listener’s technical level. Just what does the listener already understand? One way to ensure that you start out at the right level of explanation is by asking the listener what they do and don’t already know.

Do you need to explain the difference between client-side and server-side programming? Or does your listener already understand? Why not ask?

Along with asking questions of your listener to gage the right entrance point for the conversation, another tool you can leverage is your power of observation. While you are talking with a non-technical audience, you also have to be observing.

It is almost always obvious when the lightbulb goes off in your listener. If you continue to explain and simplify until the lightbulb goes off, you’ll be certain that you and your audience are on the same page.

Finally, it is very useful to introduce some silence into your explanations. Put a period on a paragraph—and then take a breath.

Let your listener digest. Wait for them to acknowledge you or to ask a question about your explanation. That silence is a vacuum that begs to be filled—and that is the time when the listener either confirms that they are up to speed and you can move on or that they are still floundering.

Summary

Some software engineers balk at the idea of speaking with non-technical stakeholders. Those same software engineers often have all of the raw material to be great communicators. It takes some effort as described above—and a lot of practice!

This is a technical article catered to developers, technical project managers, and other technical staff looking to improve their skills. Sign up to receive our technical articles in your email inbox.

If you're looking for a job in the tech industry, visit our job board to see if you qualify for some of our positions. If you're looking to hire technical talent for your company, please contact us.