The other day I was in a meeting where another engineer attempted to explain how to use a new tool. Granted, we both work in the same engineering space but it was extremely hard to follow the presentation. I found myself getting frustrated because I was nowhere near understanding what was going on. So today’s topic is: explain what you are doing!
Forget I’m an Engineer
Often, we assume that all engineers are on the same wavelength. We assume that other engineers should have no problem following what we’re saying just because we are all smart. Remember that, just because we’re smart, we don’t know everything there is to know. So when you have to explain something make sure you take the time to explain it in such a way that a non-engineer would understand. That’s not dumbing down your presentation, that’s making it more accessible. You never know when you might have to give that presentation to a manager or a shareholder or an investor.
Make The Alphabet Soup Edible
Engineers are notoriously lazy which means we substitute acronyms for long phrases every chance we get. There’s nothing wrong with that when you’re discussing your work with the same people on your team or project. But the moment you go beyond the boundary of your individual group, you can’t assume that other engineers will understand your jargon.
What’s more, sometimes the same acronym can mean different things. If you learned how to program in BASIC, you know that the term REM stands for “remark” (apparently, still used in Visual Basic). If you happen to be someone who studies sleep patterns, you know that REM stands for “rapid eye movement”, a stage of sleep where your brain is more active.
Yet another example is a different presentation I witnessed: the presenter had a slide full of acronyms. He understood what they meant but I’m pretty sure very few of the viewers did. Since this was a virtual presentation, it was easy for everyone to remain quiet but I imagine that if we’d been in the same room lots of people would have been nodding in agreement while silently wondering what those acronyms meant. No one ever wants to be the one to raise their hand and ask what an acronym stands for.
That’s not to say that acronyms are bad and should be avoided. But if you feel the need to use them in your presentation, include at least one bullet point where you explain what the acronym stands for. Remember that not everyone works in your world. Don’t force your audience to Google an acronym in the middle of your speech, it could lead to them giving up on you to follow someone else on their phone.
Don’t Just Hand Me A Map, Give Me Directions
Back to the engineer trying to show me how to use a tool. It was the equivalent of that person pointing to two points on a map and saying, “See this? Here’s your starting point. And this, over here, is your stopping point.” That doesn’t do me any good. I need you to show me how to get from point A to point B.
I find it very frustrating when someone who is supposed to be showing me how to use something just starts clicking buttons and doesn’t explain why. Tell me why it’s important that you clicked on that button. Explain the workflow. Walk me through a scenario. Show me a use case.
Imagine you’ve never been to New York City. Now imagine someone drops you off in Times Square and tells you to find your way to Central Park. You could probably wander around and eventually find it even though they are just a few blocks away. You might even ask someone for directions and that would cut your time down considerably. But without any indication of where the two places are in relation to each other, you’re going to waste a lot of time figuring out how to get where you need to be.
When you don’t explain to me what you are doing, it’s like you assuming that, just because I live in a city with a downtown area, that I should know how to navigate around New York on my own.
Explaining Is Not Dumbing Down
I think that we engineers sometimes get defensive when someone asks us to explain what we do because we assume that our intelligence is being challenged. It’s not about intelligence, it’s about familiarity. When you go see a doctor, don’t you ask questions? Of course you do. Asking a doctor to explain why you need to take a certain medication does not imply a distrust in his ability to prescribe. Because you don’t study medicine, you just want to understand more about the substance you are about to put in your body. That’s fair.
Some engineers may think it’s beneath them to have to explain their actions. They feel as though they don’t have the time to explain things to someone who just “doesn’t get it.” Again, it’s not a crime to help others understand. On the contrary, it makes you more valuable.
Remember Einstein’s quote:
Everything should be made as simple as possible, but no simpler.
If someone asks you to explain what Mbps means, you don’t have to launch into a treatise about telecommunications. You could simply explain that bits-per-second is a rate of data transfer and the larger the number, the more data is being transferred. In this case, the M stands for one million bits of information being transferred in a second.
See? That wasn’t so bad. You didn’t lose any credibility by explaining that. Quite the opposite. The next time anyone has any questions they know you will be the answer guy/gal.
Knowledge Isn’t Power; Sharing It Is
Can you imagine what would have happened if Einstein would have just kept his notes to himself? What if he decided that he just didn’t want the world to know what he was working on? What good does it do us if we just hoard our knowledge? That certainly wouldn’t do the rest of the world any good. That’s why I’m so adamant about engineers getting better at communicating. There is so much information in the world right now that it’s overwhelming. The rest of the world (i.e. non-engineering types) needs people like us to help them understand.
Let us be the bridge between the world and all the information that’s out there. Let us not be afraid to explain so others will understand.