Anatomy of a Great Technical Story

One of my favorite science talks in the world is this TED talk by the CEO of Duolingo (who also happens to be a Professor).

On the surface, it’s not a science talk. It feels like funny conversation, sprinkled with a few clever insights about learning a language. You laugh and nod along, only later to realize he’s been teaching you behavioral science the whole time.

That’s the mark of a great technical talk.

It sneaks past your defenses. You don’t even realize what's happening until you’re already hooked.

Earlier this year, I ran a storytelling workshop for 40+ scientists and researchers. The first section of the training featured insights from this talk so I'm sharing some of the lessons with you.

Every good story can be broken into 2 sections:

• back end = technical rigor

• front end = emotional and cognitive accessibility.

Put another way:

• Back end = what happened, in technical terms.

• Front end = why it matters, and to whom.

I'm a firm believer that the audience should interact with the backend as little as possible. Let the front end do the heavy lifting.

If you had to type code or DOS commands every time you wanted to send an email, you would hate it because it would be cumbersome. That’s how most technical talks feel - too much code, not enough design.

So you can see why it’s better to keep the backend of your story partly hidden from the audience.

Analyzing Prof Luis Von Ahn's talk with my framework, it becomes obvious why it's so good.

Every great technical talk has a frontend and a backend. Especially if you're speaking to superiors, non-technical people, or the public, it helps to think of your story this way.

And this does several things for you.

Researchers, analysts, technical people often show up with a polished back end. The experiment is done, the data analyzed, the theory solid. But the front end doesn’t exist yet.

Your job is to create it.

Attention is scarce. Whenever you're engaging an audience whether through a talk or your writing, you have 60 seconds, maybe less, to get them interested. Why? Because you're competing with WhatsApp notifications, emails, YouTube, and SMSes.

Do NOT start with your data (unless it's shocking data). Start with something that connects emotionally: humor, a surprising fact, or a personal story.

Prof. Luis Von Ahn did this very well - he opened with a good joke and he kept engaging the audience. If you were in the audience, you'd be almost scared to peek at your phone so as not to miss anything.

People like big ideas. They make the world feel both simpler and bigger at the same time.

Instead of juggling a hundred details, you get one clear concept that organizes everything else. It gives people a handle to carry your ideas home with them. Big ideas also lift us out of the ordinary. They give us a sense of scale, possibility, or meaning that makes the details feel part of something grand and inspire that sense of wonder we had as kids.

It's also robust enough to let you get creative with the storytelling.

The hard work is knowing what to leave in the back end. Technical people fear oversimplification. The common pushback I hear is some variation of, “But it’s more complex than that.”

Of course it is. Isn't everything in life complex? Love, mastering a skill, winning grants.

So it helps to think of this as translating technical parts of your work for the audience.

How do we do this without dumbing down? Replace jargon with metaphors, analogies, or visuals.

For instance, instead of saying “high-resolution downscaling models,” say:“It’s like zooming in on the weather forecast until you can see your own street.”

A lot of analogies and metaphors come intuitively. Like this brilliant one by Lawrence Haddad, Executive Director of GAIN.

But if you're stuck or struggle to come up with metaphors and analogies, Vincent Pierri gives a very simple framework that works.

Authors I love to read who are geniuses at analogies and metaphors - David Foster Wallace, Zadie Smith, Morgan Housel and Malcolm Gladwell.

To get a little meta, you'll notice I did the exact same thing with this newsletter. I could have given you a bullet-point checklist on “How to Tell a Technical Story.”

Instead I began with something personal to me - my favorite TED talk. I used analogies (websites, DOS, containers). I titled this post "Anatomy of a Great Technical Story", (framing it as a big idea). That's the front end at work.

And it must be working. I’ve delivered multiple talks this year using this framework, and each time they tell me they want me back.

The lesson remains - always lead with the story. The science serves the story, not the other way around.

Trust me it works.

A summary of the most effective learning techniques based on research study findings.

If you enjoyed reading this newsletter, please like the post and share with your network. Inclusion Notes keeps growing every week and it’s due to people sharing it with their friends and colleagues.