You know how to explain things to an audience whose background is like your own. But how do you get the message across when the subject matter is bound to go over the listeners’ heads? Analogies. Lots of analogies.

If you are in a technical field such as software development, the scenario is inevitable. At some point, you need to explain an aspect of your work to someone who has no clue what you’re talking about.

Maybe you have to explain to the CFO why your project needs more funding to take advantage of a breakthrough, what was behind a big software failure, or why your development team needs an expensive tool. You may be asked to explain to a non-technical customer how your software works. Or perhaps the CEO asks you to give a “lunch and learn” to bring the manufacturing department up to date on an upcoming industry technology that may impact the company (5G networking, artificial intelligence, quantum computing).

Regardless of the reason, you have to explain very technical details to someone who doesn’t understand the subject – but it’s crucial that they pay attention. So now what?

This article offers tips about how to reach an audience – whether it’s a solo CEO or a board room full of corporate execs – who might space out before you reach the third slide. Yet, you need people to stay awake until the end, and to respond, “Yes, that’s a good idea! Let’s do that!”

I assume that you know the basics of organizing and delivering a presentation, such as limiting the number of PowerPoint slides, or practicing your delivery to stay within the time allotted. You’re already an expert at the topic at hand, or you wouldn’t be in the position to do the presentation. Plus, I assume, you are comfortable with people who share at least some domain knowledge with you, such as other software developers or scientists. You just don’t know how to reach these people.

How technical do you need to be? Are you sure about that?

Start by contemplating what the audience does know; how much they need to understand to meet your objective (say, to allocate the budget you’re requesting); and what level of information you need to impart in order to achieve that goal.

You may not need to be as technical as you think you do. If your goal is to acquire funding, the audience may be far more interested in business benefits (“We’ll save a pile of money!”) than in the techie details that excite you (“a million CPU cycles per second!”). Make sure that you’re really serving your audience, not your own enthusiasm for the topic.

“Executives don’t really care about the bits and bytes. They want to know why they should care,” says Alissa Knight, previously a security analyst specializing in financial sector security. Knight used to fly around the world, explaining to chief security officers how she and her team could penetrate a bank’s security. “What they like to see is the impact to the business.”

“Pay attention to the difference between benefits and features,” agrees Harwell Thrasher, author of Boiling the IT Frog. “Tech people fall in love with features but the actual benefits of the technology are what’s important.”

“Avoid getting too much into the how,” Knight adds. “Leave the how out. They care about the what.”

Keep in mind that the audience doesn’t have to become an expert on the topic. They don’t need to know everything you know; they hired you for that knowledge. Instead, the listeners want to understand the caveats and limitations of the things you’re talking about, the contexts under which it works, where it’s an awkward fit, and what to expect based on interactions with other systems.

That said, sometimes you need to get downright geeky. You can stress the high-level benefits of a medical breakthrough (such as “fewer people will die”), but if your research team found a new route for tackling drug resistance in skin cancer cells, at some point you have to describe what a cytoskeleton is.

You can’t have too many analogies or examples

“I’ve been asked to present to the board of directors for some very large companies,” says Knight. Yet the C-level executives who listened to her presentations don’t know what a buffer overflow is.

The solution? Use analogies. Tell stories. Explain the concept using items familiar to the audience. Use diagrams.

Let’s say that your technical explanation relies on computer networks, data transfer rates, and cables. Comparing network traffic to literal road traffic can help them visualize differences in speeds and advancements in technology.

“My favorite analogy is that a network is very porous,” Knight says, “It’s like a river, I explain, and there are all sorts of inlets to a river.” Then the audience can relate the analogy to something they know. “That’s how a network is and how an adversary gets in,” Knight would tell her non-technical audience.

Omit needless buzzwords

Minimize the jargon. Too many techies assume that everyone speaks the same language that they do, but their language is as specialized and esoteric as is a doctor’s or accountant’s. If you explain what a whatzit and gizmo are, and what they do, and why they need to be connected up, most people can follow along.

Of course, sometimes you’re presenting to a person where some level of technology knowledge is assumed. You can use some jargon, but use less than what you assume the audience knows. Pay close attention to the audience’s response; you don’t want to appear condescending.

When you decide to include technical terms, explain what each term means the first time you use it. If it’s usually spoken as an acronym, introduce both the term and its shortcut (“To communicate with the other system, we use an application programmer interface – it’s called an API”) so that the listeners don’t get lost trying to keep track.

Are you talking about software quality topics? It might be a good idea to come up to speed on the technical terms. Start with a review of our QA glossary.

Instead, show relationships. Show charts and graphs, particularly when they demonstrate relationships between concepts.

Fred Bartlett, a senior analyst at Penguin Random House, makes sure that his graphs look familiar to the people viewing them – which for his organization means a trend line. “We use different colors, and plot on different axes,” he explains. “You have to show what will come out most clearly to someone looking at it for the first time.”

Did they understand you?

Find out if you’re reaching them. Don’t just talk. Ask questions, to find out if you already lost them in the dust… and to give yourself an opportunity to retrieve them from the dust.

When you plan your presentation, include time for questions. If what you’re asking for is important and new, there are sure to be questions. Depending on the subject, it may be wise to solicit questions after each section, rather than wait until the end of the presentation.

Recognize that the audience may be embarrassed about its ignorance, particularly if they are accomplished people who don’t want to look dumb in front of professional colleagues. “Pass out note cards that people can write questions on,” advises telco and antitrust attorney Paul Overbite. Even if they’re embarrassed, he says, “They’ll write down their questions as an anonymous note.”

Don’t forget the takeaway

There’s a reason you’re making this presentation. Make sure it’s clear to the audience what that reason is, and explicitly state the one thing you want them to understand by the end.

Be clear about what you want. Even if you don’t succeed in enlightening the audience about the technology, you might convey your dedication and passion enough to sell them on giving you your heart’s desire. The listener may not end up understanding network topology, but she may conclude that you know – and that your opinion can be trusted.

What facts do you need to tell the story that’s contained in your presentation? If this is a request for additional funding, then you need to describe what you’re accomplished, what you need to do next, how much it will cost to do that, and a timeline.

For example, when Bartlett needed to upgrade some business systems, he ignored any presentation of the underlying algorithm. “We just focused on the solution. We showed a graph, and then another graph on what would happen if we implemented to the solution. Then we had to discuss what it would take and how many people it would take. Because we had the graphs, it was easy to get past it.”

However hard you work to make the technical information easy to digest, acknowledge that the audience might need to study it later, on their own, in order to grasp the message. Handouts and follow-up email messages can help, particularly if they stress the takeaway.

“I email the link of the things I’ve talked about,” says Rob Pegoraro, a business writer for USA Today and Fast Company who does frequent presentations. “I use the main points on a slide and then do handouts.” Give the audience an opportunity to look up the information afterwards, so give them links. “Emailing the presentation is also good,” he adds.

So really, a winning presentation has two goals. The first is to keep your audience engaged enough to listen. The second goal is to provide them the information they need, in a way that makes sense to them, so that they can make the decision you hope they will make. It’s not rocket science, but it does require knowing to whom you’re presenting, and knowing their viewpoint well enough to explain your point in a way they understand.