You know the signs: glazed eyes during your presentation, people checking phones while you explain a process, or the dreaded interruption - ”Sorry, but why does this matter to me?”

It happens because we lead with how things work instead of what breaks when they don’t. We assume people want to understand the process when they really want to understand the consequences.

The Gap Between Data Professionals and Everyone Else

Here’s what usually happens: you spend time crafting a clear technical explanation that makes perfect sense to you.

The data concepts excite you. You deliver it confidently to stakeholders who don’t work in data.

But what sounds essential to us as data professionals can sound like optional technical jargon to everyone else. We start with solutions that excite us, forgetting that most people need to understand the problem first.

Watch what happens when you flip this approach:

Instead of: “Let’s review API rate limiting strategies.”
Try: “Our system crashes every time marketing runs a big campaign because we’re hitting limits nobody knew existed.”

The technical content stays exactly the same. But now people lean in instead of checking out because you’ve connected your data expertise to something they actually experience.

Why Stakes-First Communication Works

When people understand what’s at risk, their brains shift from passive listening to active problem-solving mode.

When someone says “your reports are wrong,” you immediately want to know why and how to fix it.

When they start with “let’s discuss data quality metrics,” non-data people’s brains treat it as optional technical information they might need someday.

This explains why even smart, engaged stakeholders tune out during technical presentations. It’s not that they don’t care about data - they just don’t have the context to understand why specific data concepts should matter to them.

Consider explaining version control to a team that’s been manually tracking file changes.

You could start with Git commands and branching strategies - concepts that excite us because we understand their power.

Or you could open with: “Three people edited the same analysis file yesterday, and we lost two hours of work figuring out which version was correct.”

Suddenly, version control becomes an urgent business need instead of mysterious technical jargon.

The Universal Translation Pattern

Many explanations lose people when they follow this sequence:

What we usually do: What → How → Why it matters
​What actually works: What’s at stake → Why it happens → How to fix it

This pattern adapts across different audiences:

For executives:
“Your team is spending 15 hours a week on manual tasks that could be automated. Here’s what’s creating that overhead. Here’s how we eliminate it.”

For peers:
“Our query performance is degrading by 10% each month. Here’s what’s causing the slowdown. Here’s how we optimize it.”

Start with the pain point, explain the cause, then teach the solution.
People follow you through complex technical details when they understand what those details are solving.

The Cost of Getting It Wrong

And when we don’t frame our explanations this way, the consequences go beyond just bored audiences.

Projects get delayed because stakeholders don’t understand why technical work matters.

Good ideas get rejected because they sound like unnecessary complexity.

Technical professionals get excluded from strategic discussions because others can’t follow their reasoning.

Often our expertise isn’t less valuable because it’s wrong, but because it feels inaccessible.

Lead with Human Impact First

Your technical knowledge isn’t too complex for general audiences. The problem is leading with solutions instead of stakes.

As data professionals, we get excited about elegant optimizations, clean data models, and efficient processes.

But non-data stakeholders need to understand the human impact first.

• The right database optimizations often prevent real frustration.
• Well-designed APIs save developers significant time.
• Proper data validation rules stop bad decisions from spreading through the organization.

Lead with those human impacts, and people will gladly learn how data works in your world.

What’s the most engaging technical explanation you’ve ever heard? It probably started with a problem you recognized, not a solution you didn’t know you needed.

Hope you found this helpful.
​
Til next time,
Donabel

P.S. The next time someone interrupts your technical explanation with “why does this matter,” acknowledge the question instead of getting defensive. That interruption is actually valuable feedback about where to start your explanation next time.

​

Have you checked out these resources?