I was recently on StackExchange and Reddit and came across two interesting posts that really caught my attention. [Highlights mine.]
“How can I become better on explaining the code to other developers?”
Both of these posts speak to a common problem that technical folks, including myself, run into: the ability to explain technical work to non-technical people.
Knowing that you have this problem is one thing. Doing something about it is another.
Today, many of us work in matrix organizations, where you work with people from all across the company. This, in turn, requires you, the data scientist, to quickly understand different problems and work with multidisciplinary teams to solve these problems. On a single project, you may have folks from product, marketing, and legal all on the same team, while a separate problem-solving team consists of warehouse staff, accounting staff, and human resources. If you’re the lead for both of these teams, all of these diverse departments are looking to you for the answer.
The challenge lies in the ability to effectively communicate with all of these folks, especially when you need to discuss technical matters.
And everyone, no matter what their background, has the tendency to talk to others as if they were one of us. When you’re a data scientist, that often means using technical terms and explanations, since that is what we ourselves like to hear.
But communicating in this way is not effective because not everyone’s lens is the same.
Over the years, I’ve become a fan of talking to people in plain English. After being in the corporate world for 10-plus years, I just became tired of having to explain concepts and talking to a room where everyone is looking at their cell phones because most of the terminology had turned them off to listening to me.
In the book Why Business People Speak Like Idiots: A Bullfighter’s Guide, the authors note:
…when people in your audience get lost and no longer need to focus on whatever it was you were talking about, they have time to figure out whose fault it is that they got lost.
It’s yours.
And in a corporate setting, folks in executive management tend to have the attention spans of five-year-olds. (And I say that with all due respect. Honest.) So if you’re working on high-impact projects that may require you to report up to the C-suite every now and then, learning how to communicate technical concepts in plain English may be the ticket up the ladder that you were looking for.
To help you out, I’ve curated five tips that can help you become a better communicator of technical concepts to non-technical people.
1. Learn how to teach your specialty.
I’m always amazed at the responses to the subreddit Explain Like I’m Five (ELI5). I sometimes get jealous at the eloquent simplicity in an explanation — not just because of the poster’s wordsmithery, but because I can tell they’re excellent teachers.
Regardless of the subject, learning how to teach effectively is the best way to become an effective communicator since you’re forced to explain complicated subjects to someone less knowledgeable than you are.
Steve Remington also noted that “[teaching] will not only help improve your depth of understanding of your subject matter but also help build your confidence to speak in front of a group.”
Sarah Nooravi was motivated by her calculus professor to become a tutor.
“If you want to be good at calculus, tutor algebra,” her college calculus professor told her.
“I so badly wanted to be good at calculus,” Nooravi writes, “so hearing these words had a great impact on me — and guess what I did? I researched where and how I could teach, and a week later I got my first job as a math tutor in the math center of my college. This advice and experience has helped me in many aspects of my career!”
2. Focus on the big picture.
As technical professionals, we like to talk about all the nitty-gritty details — the elegance of code, sizes of engines, speed of computers. Details are our joy. But when we’re working with non-technical people, we need to remember that the person on the other side may not care about the details the same way we do. Or perhaps they care about a different set of details altogther. Throughout my career, I’ve learned that when presenting to people on any level, they want the big picture. If they want the details, they’ll ask.
Here’s an interesting response I found on Reddit:
The people you’re problem-solving for don’t care about the elegance of your for-loop or the type of model you used. They just want answers. Now, that’s not to say that you shouldn’t be careful about the details, it just means you shouldn’t mire your audience with them — unless they ask.
3. Sound like your audience.
When you talk to someone in their language level, it’s easy to have empathy for the audience.
World famous copywriter David Ogilvy is noted for saying:
If you’re trying to persuade people to do something, or buy something, it seems to me you should use their language, the language they use every day, the language in which they think. We try to write in the vernacular.
That doesn’t mean you talk down to them. It means you talk like them, using plain English.
At a conference, I once heard someone use the term “heteroskedasticity,” but she immediately followed up by saying, “That’s just a fancy way to say that the data fans out.” She went on to show the “fanning” effect on a chart. The word caught the audience’s attention, but they could have gotten stuck on that word if it hadn’t been explained, both visually and verbally. I walked away from the lecture with a whole lotta new knowledge, including a larger vocabulary.
If you have a tendency to put your audience to sleep with all your 50-cent words and technical jargon, follow this advice from Donna Boyette: “List some of the technical terms you use most often, as well as any terms that always result in blank stares from your listeners. Take your list and log on to Whatis.com. Use the definitions you find the next time you are trying to explain a new process.”
4. Apply the “Third Time’s a Charm” approach when talking to a group.
When I was a graduate student, I was told that the secret to teaching is in these three steps:
- Prepare your audience for what you’re going to tell them.
- Tell them.
- Tell them what you told them.
In essence, you’re telling a story. And in order to make that story compelling, you need to guide your audience through it. Doing this effectively requires you to first sketch out everything you want to say and build supporting elements for each.
The McKinsey Pyramid Principle restates this idea in a similar way:
- Start with the answer first.
- Group and summarize your supporting arguments.
- Logically order your supporting ideas.
It’s pretty much the same idea as learning through repetition, only in each of the above examples, you’re not merely repeating but doing so with additional information to reinforce the concept.
5. Practice makes perfect.
Sure, it’s a cliché, but there’s a reason for that: There’s a lot of truth in it.
In his book, The First 20 Hours: How to Learn Anything Fast, Josh Kaufman makes a case that there are five major steps for rapid skill acquisition (Kaufman’s term for picking up a new skill): deciding, deconstructing, learning, removing, and practicing.
Kaufmann also argues that you can pick up a new skill after only 20 hours of focused practice, not the 10,000 regularly quoted by “them.” I’m a big fan of his book and regularly use his system for self-learning and to pick up new skills.
Other resources that I have found to be useful in this area include:
+Eric Berlow: Simplifying complexity (Video)
+Explaining Technical Things to Not-So-Technical People (Text)
+Seven Tips for Talking With Non-Technical People (Text)
Like What You See?
If this issue of Missing Data has brought you any value, it would mean the world to me if you shared it with one friend using the buttons below. Thanks!
Grant