Less noise, more data. Get the biggest data report on software developer careers in South Africa.

Dev Report mobile

4 Tips For Communicating Technical Ideas to a Non-tech Audience

11 July 2019 , by Jason Webster

Communicating your ideas to a non-technical audience can be really tricky. Whether it’s presenting to your non-tech team lead, or communicating with text in an email or blog post, a confused audience is never ideal! In this article, I will share some tips that I use to communicate technical ideas in an understandable way when giving a presentation or writing blog posts, no matter the audience.

How to communicate technical ideas to a non-tech audience.

Over the past four or five years, I have presented my technical ideas to a variety of both technical and non-technical people. Along the way, I realised two important things about doing so:

  1. It is very easy for a presenter to lose an audience, and
  2. This is more often than not due to a lack of skill in the presenter - for example, not making it easy for an audience to understand what the talk is about.

When it comes to communicating ideas effectively, it’s your job as a presenter to make your talk enjoyable, to wow the crowd, and to help get across what you want to say in a clear and easy-to-follow way.

During this time, I’ve grown-out of shying away of giving presentations, and learned what it takes to give a successful presentation. Now, I actually enjoy public speaking.

Here, I give some of the tips and tricks I’ve picked up along the way, with separate hacks for giving a talk or writing a blog post.

  • Tailoring your technical talk so that non-technical people can understand you.
  • Grabbing your audience's attention from the start: Technical content can be quite difficult to digest. Ensuring your audience follows along from the beginning almost guarantees a successful delivery of highly technical ideas.
  • Telling a story to make your content as coherent as possible. I find that having an incoherent talk or article will lead to a lower audience.
  • Making your technical ideas relatable to ‘the everyday’: I like to highlight the “cool” factor of my work, and not worry too much about trying to prove I’m smart. Focus on understanding, rather than losing your audience to a cloud of technical jargon.

Tip 1: Tailor your talk

How do we tailor our talk around our audience? I’ve found that an effective way to present technical media is to tone down the technical content to an absolute minimum, and to not presume that my audience knows anything about the topic I am presenting. Surprisingly, I’ve found this works for technical audiences too, as it brings everyone up to speed without sacrificing your audience’s attention. It never hurts to slow down the talk, or blog post, with brief explanations of the deep technical points.

Giving a presentation

Giving a talk provides a unique opportunity to you when it comes to tailoring your talk. You’ll usually know who your audience is well ahead of time - you’ll be invited to a meetup, for example, and you’ll be able to ask the organizer what the ‘technical scope’ of your audience is - in other words, how technically minded they are.

Knowing the technical scope of my audience allows me to edit my slides and focus my talk in a direction that I feel the audience would be most comfortable with.

For example, I’ll remove as much technical jargon when talking to an average listener, and keep some of it in when my audience is more technical. Similarly, I’ll try to present some of the code and methodology involved in a talk when presenting to, say, software engineers. However, when talking to the public, I’ll instead focus more on what makes the talk “cool” - in other words, why they should care.

My advice here would be to:

  1. Get an idea of who you’re presenting to ahead of time.
  2. Use this information to make your talk as relatable as possible.
  3. Be safe rather than sorry: Don’t assume your audience knows too much. Try to make sure that everyone can follow along.

Writing a blog article

In the case of a blog post, I would think of my audience as being defined by the people that would want to know more from the title of my article. After all, that is typically the hook that most reading audiences see when scrolling through their favourite blogging website.

Knowing this, I’ve found that it really helps me to tailor the title around the contents of my article or blog post. An easy hack I’ve learned is to get whoever fits “my audience” to read the title and guess what the article is about, or what they expect to get out of it. That gives me a good idea of whether my framing is too complex, or whether they’d actually click on it and read it.

As an example, here are three article titles:

  • “Technical talks for non-technical people”
  • “How I built a self driving car in under a week”, and
  • “Quick dive into centralising your data in Angular with ngrx/router-store.”

The first article is likely not going to deal with anything technical. The second probably has some technical content, and you’d probably want to know a bit of math in order to fully grasp what the article is talking about. The third, on the other hand, seems fairly technical, and will probably require an understanding of data structures and Angular before one is able to grasp the details of the content.

Where-as the first article has a pretty broad appeal, if you don’t know anything about Angular, would you even consider following the link to that last article? Probably not. Even if you wanted to learn about Angular as a beginner, you’d probably not start there either.

My advice here would be to:

  1. Be consistent in your article. Write according to the audience that you think would be most interested in your article.
  2. Following this, structure your blog title around your article. Get a friend to sanity check the title, and see if they’d be able to guess the contents of your blog post.

Tip 2: Grab your audience's attention from the start

Technical content can often be very in-depth. This can provide a lot of opportunities for your audience to get lost if you aren’t careful. It’s important to make sure that your audience is paying attention from the very beginning, as this is often the part where you are explaining technical terms that may appear later on.

Giving a presentation

I’ve noticed that there tends to be a common theme in technical talks: The perception is often that, If the work you’ve done is technical, it should be presented in a very technical manner. However, I disagree.

I believe you should always present a technical talk with the primary intention to entertain your audience, while at the same time educating them - something that is now becoming known as ‘edutainment’.

One common pitfall here is including a table of contents. This often comes before the technical communication stuff (such as reports, analysis, etc), but I have stopped using them altogether.

If your table of contents is anything like how everyone does them, it’s in bullet point form and lays out the structure of your talk. Personally, I always found myself talking about what my talk would be about (meta-talking!).

So, on the first or second slide, I would have already presented a wall of pretty uninteresting text that served little purpose, and I would have quickly lost my audience to their cellphones! At the early stages of my talk, where I would slowly introduce all the technical concepts of my topic, losing an audience meant they were lost for the remainder of the talk.

From this, I learned that every aspect of my talk should be engaging and visually interesting to my audience, while still making sure that my voice is the focus. My slides be visual aids in my story, and should be easily read at a glance. I converted any slide that had a lot of text into a pictorial story.

Another tactic that helped me was to beat my stage fright and excite myself about the talk. This helped me speak louder and more clearly, and being as energetic as possible helped keep people engaged and focused. I’d also use as much body language as possible to help keep even the more boring bits of the talk exciting to listen to.

To summarise, my advice here would be to:

  1. Avoid losing your audience in the early stages of your talk, as this will likely mean that you’ve lost your audience for the entire talk.
  2. Be as energetic as possible. This helps maintain my audience’s interest throughout the talk, and allows me to be more myself on stage.

Writing a blog article

When writing on a blog post, on the other hand, a “table of contents” approach is actually very useful. It helps me keep my readers engaged if I orient them at the start around what’s to come further down, and allows them to skip certain sections if they need to - a win for your readers!

Beyond that, it’s good to start your article with a good punch. I think of it like this: technical articles can get quite complex, so if my article has a slow start, it’s unlikely my readers will be invested until the end.

Part of OfferZen’s process, in fact, in writing an article, is to write the “sanity check” (the intro paragraph that defines the article), and make that the first thing your audience reads. It gives them an idea of what I’m going to tell them and why they should care, and acts as the second ‘hook’ for their attention (where my title would be the first).

But don’t get too caught up in the technicalities of what you are trying to write about. If I’m going to write about something technical, I would explain it with a concrete anecdote.

If for some reason my audience already knows the explanation behind a technical point, they can skim through the explanation. If they don’t know the details, the concrete anecdote usually allows my audience to stay grounded without getting too lost in the generality of the technical claim being made.

My hacks here are:

  1. Get your readers excited about your article with a good punch in the beginning. Not doing so could lead to them losing interest in the article due to its techy nature.
  2. Explain technical points with concrete anecdotes. This helps to ground your reader and gives them a functional understanding of your point without getting too general.

Tip 3: Tell a story

An important first step when first approaching any piece of media is to ask: What story am I trying to tell? How am I going to structure my media so that it leaves my audience with the message I was trying to convey? This is where coherency comes in. It asks you to create a story that flows easily from one page (or slide) to the next.

Giving a presentation

I like to tell a story to my audience. I’ve found that a good story keeps people listening. In my experience, the best way to make a good story is to stretch it from your first word to your last. This feeds in to the ‘edutainment’ factor of your technical talk. Try to come up with an interesting story, and your audience will easily follow whatever technical things you include.

In my talks, I usually set the story of my talk around the visuals of my slide deck, and then around the content of my speech. It’s easier to start with the visuals, as these give the most visceral feel for how your presentation flows and feels.

To do this, I construct a slide deck with the overall story (this usually flows quite naturally) and follow this up with a round of reviews that focus on making my slide deck more impactful. This involves:

  • Finding the slides that have the most impact or most important information
  • Focusing on those first
  • Breaking-down any highly technical slide into two or three simpler slides, that help explain the concept

What I end up saying follows naturally from the slide deck, since at each point all you have to do is essentially explain what you’ve put on your slide!

Writing a blog article

Here, the importance of coherency in a blog post is much the same as it is in a talk. You’re trying to tell a story to you audience, and that story needs a structure. I find it difficult to read an article if it loses its coherency, and I quickly turn away from it if I feel like I’ve lost track.

This is especially true in technical articles, where at times it often feels inconsistently paced by suddenly jumping into technical content without any warning.

I’ve personally struggled with getting this right a lot in my writing. In talks, it’s easy to ask my audience where they’re feeling lost, and establish what I need to do to get them back up to speed. I don’t get that luxury in a blog post.

What really helped me was to define a clear set of guidelines for my blog posts on what I want to achieve.

Before starting, I ask myself:

  • How should structure my article?
  • What context do I need before diving into the technical aspects of my article?

I like to structure my articles to have a “hook” paragraph, and then use the next two or three paragraphs to give some context to the technical aspects I want to talk about. More complex structures may emerge naturally from this process - such as specific sections or topics - but those end up helping add a smoother ‘flow’ to the article.

Tip 4: Make your information relatable

Giving a presentation

When presenting, it’s important to relate to your audience. If you want to deliver an effective presentation, you need to use language that they understand. When presenting a topic that your audience does not know much about, but that they are interested in, ask yourself: How can I bring my audience from a state of knowing very little about my topic, to (at the very least) being conversational on it?

I recently gave a talk about my self-driving car at the DevelopersUserGroup meetup. Seeing as this was a software developer group, I tried to incorporate some of the code I used in order to develop my self-driving car. I expected my audience to have some mathematical background, and be able to follow through some of the more technical points of my talk - as expected, they did.

In another talk on the same topic, this time to the public, I removed all slides that contained a hint of technicality or code, and instead tried to focus on the “cool” aspect of the self-driving car, and why they should find this piece of tech theory so interesting.

Had I given these talks the other way around, the developers would have been bored, and the public would have found it too difficult - and I’d end up losing both!

A good tip here is to use a concrete, everyday example to explain a complicated topic. In the case of my self-driving car, I first posed the question to my audience: How do we drive cars? The audience is welcome to answer, but then I ask another question: Can we drive blindfolded, or without access to the steering wheel? This introduced the crux of my article, that ‘driving’ needs a feedback loop in order to get visual information and act upon it (if you’re intrigued, you can read the full article here!)

My audience was able to engage with the questions I had to ask myself, and came to this conclusion on their own - meaning they’re now an active part of the presentation!

Writing a blog article

Similarly, when writing a blog post, you need to write in the language of your target audience.

As with giving talks, I like to explain complex technical topics using concrete anecdotes. In blogs, I try to make this as visual as possible - for example, I’ll explain neural networks by getting my readers to think about the complex structures of the brain, and then try to explain each aspect in so far as the anecdote can go, before returning to the more technical aspects of a neural network.

This can give my readers a way to ground themselves in reality, while also giving them a way to visualise what might be going on in a neural network.

If you follow these four tips, and try put yourself in your audience's shoes, you'll become a communcation expert. These may seem simple, but the pay-out of sticking to them has been immense for me - so I'm sure it'll do the same for you!

Jason Webster loves exploring the way the universe works. He’s recently graduated with an MSc in Physics, and enjoys spending his time exploring the world of science, software, and tech. He is currently employed as a Junior Data Scientist at Explore-AI. You can find his recent developments on GitHub, LinkedIn, and Google Scholar.


Recent posts

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.