Explain It Like I’m Management
Jargon is for suckers — easily walk a layman through your technical process with an inverse explanation.
One of the first exercises I do with a new group of engineers is also my favorite way of introducing the concept of concision.
Not only is it extremely effective: it’s usually hilarious, and serves as an amazing icebreaker when getting to know a group of new “students”.
Here’s how it works:
Every engineer writes me a 4–6 sentence description of their job…
…they have to explain it to me like I’m 5 years old.
It’s actually a lot of fun (but not as easy as you might think!), and the idea was inspired by the r/eli5 subreddit.
Suddenly, photoacoustic spectroscopy becomes “shoot things with lasers and listen to the sound it makes with a microphone”.
While project management becomes “make sure the right people do the all the right stuff at the right time but make sure those things don’t cost too much money and that everyone plays together nicely”.
But by far, my absolute favorite is when an engineer explains using metaphors, because P&IDs, for example, magically turn into fairy-tale pirate treasure maps…
This exercise it so effective at clarifying the concept of concision because it demonstrates the exact opposite of what concision in technical English really is.
Five-year-olds don’t understand big, scary technical words; so, you’re forced to use drawn-out descriptions instead of single words, with exaggerated examples to clarify them.
In other words, you have to be very unconcise.
Nevertheless, after only 15 minutes of practicing exactly what this foundation of technical communication isn’t, the idea of concision takes root, and my new group of engineers hits the ground running.
Getting Past the Jargon
Very often, our roles as engineers require us to explain technical processes to people lacking any technical background; they’re usually the ones who can who sign checks with the most zeros, after all.
You might need a commercial manager to approve funding for a project you’ve proposed.
Or, you might need to explain to a controller why, on a technical level, the more expensive model of a new machine is worth the extra cost for your factory.
It took us years of engineering study in order to understand these technical processes… so how can we explain them clearly enough to get that layman’s million-dollar signature?
First, let me be very clear:
Explaining like they’re five years old is a very bad idea.
But by using the same principle as my ELI5 exercise above, you can explain a technical process in a way that’ll leave decision makers smiling and nodding out of actual, genuine agreement instead of the usual utter confusion.
In other words, if you need that grown-up to sign your permission slip before you can go outside and play with big expensive toys, then pay attention -
Because you’re about to learn how to explain a technical process to non-technical people by doing the opposite of what they’re expecting.
Everything has an End (only a sausage has 2)
Take a look at the first 90 seconds or so of this Learn Engineering video which explains the basics of the Rankine Cycle (i.e. how we generate electricity by burning dinosaur corpses).
Notice anything peculiar about HOW the process is explained?
Let me break it down for you (and then watch it again to see what I mean):
If you need to explain the process of making a pizza, for example, your instinct will tell you to start with the dough, and then sequentially work your way through the sauce, cheese etc., until finally, that gooey, cheesy goodness comes out of the oven.
In this case, explaining the process in a step-by-step, beginning-to-end manner makes perfect sense for two reasons:
First, it’s standard practice to explain a cooking process i.e. a recipe in sequential order. More important than precedent, though, is that we can safely assume that everyone already understands the process of making a pizza.
What we cannot safely assume, is that everyone already understands the process of incinerating dinosaurs.
So, because the video above isn’t intended for people who already understand the Rankine Cycle, the creators cleverly defy their instincts and turn the entire explanation on its head.
Their explanation begins with the final result of the process, and then works backwards through the steps required to get there.
This technique is incredibly effective for explaining technical processes to the otherwise unfamiliar. And although it may seem counter-intuitive, it actually makes a lot of sense. Here’s why:
The End of the Tunnel
Think back to your days in university. Ever have a professor start solving an equation on the blackboard without first telling you what it actually was?
As you scribbled furiously in your notebook and tried to make sense of it all, two thoughts were likely in the back of your mind:
- What the hell is he getting at?
- When will this finally end?
By explaining an unfamiliar process from beginning to end, there’s a good chance your explanation will elicit the same frustrations in your audience that you experienced (and still remember) from dear old Professor .
Simply put yourself in their shoes for a minute, but instead of some cool engineering project, you’re forced to follow an explanation of German tax legislation. Sound exciting?
(to be clear, German tax legislation is very not-exciting)
So imagine how much worse it’ll be when they have no idea what your actual point is, OR how long it’ll take you to finally get there.
Make this mistake, and the highlight of your explanation is no longer the benefit created by your process; instead, the highlight for them is simply the point at which your mouth stops moving.
In 5-year-old spirit, let’s put on our imagination hats for a moment…
Imagine your explanation as a mountain of information, with the summit being the final result of your process.
If you force someone to start at the bottom of your mountain and climb up, the stress of the climb will ultimately subtract from their enjoyment of the panoramic peak (assuming they make it there in the first place).
No matter how great the view is, your end result just won’t be as enjoyable, as their brain will be tired from processing the ‘climb’.
So try it this way instead:
Start by taking them up to the peak in a helicopter, and beginning your adventure at the top of the mountain…
Let them take in the spectacular view, breathe that crisp mountain air and snap a few selfies FIRST — while they still have all of their energy.
Then (keep that imagination hat on…), as your explanation proceeds downwards, you’re able to provide a more effective explanation for these reasons:
- Because the end result is something they’re familiar with, it becomes the anchor point they’ll use to repel down the unfamiliar mountain. In other words, they’ll remain safely connected to what they do understand as you guide them down through all that they don’t.
- Now that they’ve already seen how amazing things look from the top, they’ll have more appreciation for the mountain itself — and hopefully for their humble Sherpa as well (that’s you).
If the mountain were made of tax legislation, which tour would you choose?
Shock and Awe and Budget Surplus
Regardless of what your technical process is, the reason why you’re even explaining it in the first place is that you (hopefully) intend to do something beneficial — make a new product, increase productivity or expand production capacity, for example.
But to e.g. a manager or a client, at the end of the day, anything beneficial is almost guaranteed to mean only one thing: having more money — either by earning more of it, or spending less of it.
Either way, ‘having more money’ is a concept that every decision maker understands well, and it’s been confirmed by science to make them happy.
Use this to your advantage (and get a nod of approval from the salespeople):
Grab their full attention at the very beginning by starting your explanation with the moneymaker. Once they have that warm, fuzzy have-more-money feeling, anything you tell them afterwards will now be LOT more interesting…
Unfortunately for us engineers, effective communication (technical or otherwise) can never be defined with a formula. There’s not a single one-size-fits-all communication method for any situation, because the context will always be different.
So pay attention:
An inverse process explanation is extremely effective in the situations and contexts I’ve described, but it’s guaranteed to work in none of them.
In the end, it’s up to you and your best judgement to decide if this method is appropriate for your process, your audience, and your ultimate objective.
There are more than a few traps in this method which you should definitely watch out for… as in, if you get caught in one, and you can easily derail your entire explanation leave nothing but chaos and confusion in your wake…
I’ve got you covered, though — stay tuned.
What you just read is the English version of an article that I wrote for my German-language blog, Vorsprung durch Sprache.
My job to help German-speaking engineers and technical personnel learn technical English as a foreign language as well as technical and group communication in the context of international projects.
All of my articles are originally written in English and then translated into German before posting. So, I’ve got a big digital stack of English language articles that’s collecting binary dust on my hard drive.
Long story short: I’ll be posting occassional articles on Medium in English with the intent of helping engineers of any language improve their technical communication skills, as well as allow my German readers and subscribers the opportunity to learn, practice and improve by reading my articles in English.
If you speak German, you can learn more about me and my company, Detroit Technical English, at https://www.detroit-english.de