Photo by Gabriel Crismariu on Unsplash

A Guide to Improving Your Technical Communication

Technical communication is hard. It’s also the most important thing you can do for your career.

Whether it’s a simple explanation to a colleague or a full-blown presentation with a slide deck, technical communication is something we’ve all seen people struggle with. I’ve seen it and I’ve struggled with it myself.

This is a problem, because technical communication is the foundation of all science and engineering. No matter how brilliant an individual is, their contribution is meaningless unless it is shared with the rest of the world.

This is what makes technical communication such a critical skill. Not only does it produce huge value, it’s also rare and difficult. Improving your own technical communication is one of the valuable time investments you can make.

How rare is good technical communication?

The first time I realised the world has a shortage in quality technical communication, I was 20 years old and more than a little naive.

I had a dream of being a researcher at a university. What could be better than sticking your nose in some books, coming up with some bit of information that nobody else in the world knows but you, and then jet-setting around the world to share it with others?

With that ideal fresh in my mind, I got myself a supervisor, shut myself away, and wrote a paper. The contents weren’t groundbreaking and the topic wasn’t interesting or at all fashionable (and indeed, nobody ended up caring that much about it). That didn’t matter to me. I was elated. It was time to live out the dream — I could go attend my first engineering conference.

Eager and earnest, I rocked up on the first day ready to hear about all the new discoveries from the professional researchers who had travelled far and wide to be there. Halfway through the day, I felt something was off. I couldn’t quite put my finger on it, but my enthusiasm was beginning to wane.

It wasn’t until mid-afternoon that I realised why — for so many of the talks, I could barely understand what the presenters were going on about. Now, it’s true I was a novice to that world, and I’m sure that experience would have helped with comprehension. Yet it seemed I wasn’t alone in my confusion, given half of the audience were typing lethargically away on laptops and the other half were staring vacantly.

Deconstructing a bad technical lecture slide

This was the typical slide presented at that conference. You may recall seeing similar ones in the past, perhaps in that second-year university course where the lecturer clearly did not give a damn.

For sure, some of the talks were good quality. But far too many were not. Despite some of the technical domains being incredibly niche, a lot of speakers gave little context or introduction. They spoke really fast or mumbled over a slide deck filled with walls of text and out-of-context equations.

Years later, working as a software engineer, I often think back to those days as a series of lessons of what not to do. Although I find many professional engineers to be proficient communicators, I’ve seen others consistently struggle in four important areas. I’ve listed these below.

1. It’s not enough to be correct

It’s easy to think your role as a communicator is to provide as much accurate and important information as possible. From my experience, a lot of people get stuck here. I’ve definitely fallen victim to this habit myself: bombarding a listener with as many facts, figures and conclusions as I can come up with, then sitting back smugly thinking myself clever.

Unfortunately, communication is not a single-player game. We can’t get better at it by being smarter, faster or louder.

To figure out how we can get better, we need to take a step back to the basics. When we have a conversation, what is actually going on?

As we know, there are two roles in a conversation: speaking and listening. The speaker’s job is to present facts into a shared pool of meaning and the listener’s job is to digest them. When your talkative colleague swings by and says “The weather is so warm today, I love it!”, they’re presenting two facts:

1. The weather is warm.
2. They like warm weather.

You actively listen, understand those facts, store them (or more likely, completely throw them out of your head), and prepare your own facts to add to the pool of meaning.

This flow can break down when either the speaker has trouble placing their facts into the pool in an effective way, or the listener has trouble digesting them. When it comes to poor technical communication, the breakdown is often on the speaker’s side. Which is lucky for us, because speaking is a much easier skill to master.

It’s not enough to say correct things. You need to say them in a way that makes sense to your audience.

You can tell the mark of a great speaker when you don’t have to put much effort into understanding them. While the speaker and listener should ideally be both contributing, a poor speaker pushes too much of the effort onto the listener.

A great example of this is the bored lecturer you had in second-year that droned on and on reading from a poorly formatted powerpoint. Although they technically did communicate the course content, you had to sit there intently, mind fully-focused, to actually grasp what they were going on about. A single lapse of attention could leave you lost for half the lecture.

It’s easy to fall into this habit when communicating technical information. Why? Because technical stuff is hard. It’s difficult enough to summon the correct information out of your own head, let alone think about the best way to put it in someone else’s.

This is exactly what is going on with people that do this — they’re stuck explaining the information to themselves. To them, their job is to figure out the hard stuff and then place the facts into the shared pool of meaning in any shape that is technically accurate. Whether the listener will struggle to digest them is not a consideration — the information is there for those willing to work hard for it.

This is the hallmark of poor technical communication — a bunch of completely correct, important facts that nobody can understand.

So how do we fix this? How do we stop shoving indigestible facts in the pool of meaning and become good speakers?

The key is simple — always think about your audience.

2. Think about your audience

To be an effective speaker, you must always consider who your audience is and tailor your content and presentation style to them.

Thankfully, it’s fairly simple to figure that out for any given audience. Every time you explain something technical, there are two questions to ask yourself:

1. What does my listener know?
2. What does my listener need to know?

What does my listener know?

This question is an absolute killer. So many technical conversations and talks have gone south purely because the speaker makes the assumption that the listener knows more than they actually do. If they’re wrong, and the listener fundamentally does not understand a piece of assumed base knowledge, they’ve got an immediate fail.

The only way this conversation is going to salvage itself is if the listener actively asks the speaker to clarify and explain. Unfortunately, this is a rare occurrence. It takes a brave person to admit they don’t know something. Do not underestimate how many people will sit there listening to you, completely perplexed but too insecure or nervous to ask for an explanation. I’m not proud of it, but I’ve been there myself.

As a rule, always start simpler than you think you need to. Whether you’re explaining something to your mum or the leading expert in your field, it’s best to have a stab at what you think they’d know and then assume they know a little less.

Of course, this isn’t a free pass to be pretentious and start lecturing people on things they may know better than you do. It’s best to start laying out the basics as common ground for both you and the listener, but constantly test the waters to see if they’re either following, not following, or two steps ahead of you.

What does my listener want to know?

In our jobs, many of us often find ourselves sharing the same piece of information to different groups of people. In order to communicate effectively to each group, the way you choose to explain the content should change fairly dramatically.

For example, say you are a developer tasked with investigating roughly how long it will take to develop a new feature. There might be three groups of people you need to explain this to:

1. The technical members of your team
2. The non-technical members of your team
3. Your business decision-makers

Each of these groups has two big differences: 1) their level of technical understanding and 2) what they actually want to hear.

Your technical colleagues, for example, will want to know the juicy technical information, down to the smallest detail. Your non-technical colleagues will want to know which parts of the new product, from a user experience, take the most technical effort and a rough appreciation for why. When you’re dragged into a meeting to explain it to the business, they likely just want to know: will it work, how long will it take and how many resources do we need?

Talking about resource allocation to your technical colleagues or database migrations to management is a good way to get glazed eyeballs and not achieve what you want.

3. Start from the top. Then start from the beginning

Always start by answering: why am I here and what am I trying to say?

Has someone ever started to tell you something by launching into a long-winded story? Have they dropped by your desk and said “Hi, Stacey in finance said her sister called her but she …”, and a minute later they’re still talking and you’re wondering what the hell they actually want? Only to eventually find out they just want to borrow your stapler.

We all see plenty of technical presentations that go this way. Perhaps the speaker realises the audience is technical, so they decide to skip all the wishy-washy abstractions and get right to the meat of the details. Which leads to the audience thinking: I know the words you’re saying. I know what they mean. I just don’t know what the hell the point is.

As a rule, no matter how technical your audience is or familiar they are with your domain, you should always begin by answering the questions: Why am I here and what am I trying to say?

That’s not to say you can’t begin with a punchy anecdote, joke or question (in fact, those are great openings). But they should devolve into answering those questions before proceeding into the details.

If you think back to your time in high school when we were all forced to write essays, you can probably remember your teacher getting antsy that you always had to start off with a block of writing called an introduction and finish on one called a conclusion. I remember all the kids, myself included, being frustrated by that.

Why did we have to repeat what we’ve already said in the middle of the essay, but in less detail? It sounded like tedious busywork, a kind of English class bureaucratic hoop you had to jump through to get a good mark.

If you want to quickly realise why your high school teacher forced you to add an introduction, try reading a high-schooler’s essay without one. You can understand the words. You can understand they’re talking about a book they were forced to read. You just have absolutely no clue what they’re going on about. What’s the overall gist of this page-long dump of words? What are you actually trying to say? Why am I sitting here reading this?

This is exactly how a lot of technical explanations go. A bunch of technical terms that you understand, strung together in a way you understand, but with a complete lack of context.

In fact, due to a combination of human psychology and short attention spans, the introduction to any kind of communication, whether it’s a presentation, article or quick explanation, will be the most memorable and important thing you say for the majority of your audience. Give your introduction the attention it deserves.

4. Go slowly. And then go even slower. Seriously.

Of all the advice to communicate technical information better, this is probably the simplest and most important. If you take nothing else away from this article, you’re probably already a better communicator.

Talking slowly is timeless advice for any kind of presentation, but it counts double for technical presentations. If the content you’re trying to communicate is conceptually difficult, you need to give your audience time to process what you’re saying. In fact, you should give them longer than you think they need.

Missing a single step in your explanation can leave your audience lost

This is especially important if, like a lot of technical points:

1. Your content has the structure of a pyramid, where the audience needs a lot of base information to understand the point
2. Your information is a series of logical deductions to an eventual conclusion.

In these scenarios, a single piece of unheard or misunderstood information can completely derail your audience from following your point. Ever gone to a lecture where you zoned out for 10 minutes near the start and couldn’t ever pick it back up? The faster you talk, the more likely this will happen to your audience.

A lot of people either aren’t aware of how fast they talk, or struggle to slow it down. As a habitual fast talker myself, I know this struggle. If you ask a friend to watch you practise and keep telling you to slow down until you get to a good pace, it may feel like you’re speaking exaggeratedly slowly. In reality, that pace will usually sound pretty natural.

Wrapping it up

Technical communication is hard. There are many technical people who are brilliant in their domain, but struggle to explain difficult concepts clearly. So if you find technical communication difficult, you’re not alone.

The four tips in this article are self-evident and intuitive once you embrace a simple idea: empathy. When in doubt, put yourself in the shoes of your audience. If you were listening to a complicated technical explanation outside of your domain of expertise, what would you like to hear?

Personally:

1. I’d like the speaker to put effort into making the explanation easy to digest.
2. I’d want them to make the explanation relevant to my current knowledge level and cater to what I want to know.
3. I’d want them to start off by giving context, so I know the purpose and the direction of their explanation.
4. And I’d want them to go slowly, so I can fully appreciate the content without missing anything.

If you have a preference as a listener, it’s likely your audience will too. If you focus on empathy, your technical communication will shine.