You walked into the meeting with something good. A clean data model. A dashboard that finally answered the question they had been asking for months. The kind of thing where two clicks gets you to the answer they had been waiting on.
You demoed it. You talked through the relationships. You pointed at the calculation logic. What you got back was the blank look. Not hostility, not even disinterest. Just a quiet, polite incomprehension that you tried to fill with more explanations, which made things worse.
You left the meeting wondering whether you had built the wrong thing. You hadn't. You had built the right thing. You just hadn't realised that delivering it was a separate skill, and one nobody had bothered to tell you was on the job description. That problem in the broader sense: nobody knows what you do.
Why this is harder than it sounds
There's a tempting frame here that says it's a presentation problem. Add slides. Use simpler words. Find a metaphor. That framing isn't entirely wrong, but it's the one that gets you writing "in plain English" at the top of a deck and then watching the room disengage anyway.
The actual issue is that you and your manager are not having the same conversation. You're trying to show them how something works. They're trying to decide whether they can trust it.
Those are different questions, and the answer to the second one almost never lives inside the answer to the first. They don't need to understand how the model is structured. They need to know whether the number is right, what would make it wrong, and what they're supposed to do with it.
That is a translation problem, not a simplification problem. Simplification is taking the same thing and saying it with smaller words. Translation is converting a technical artifact into a decision-shaped thing - something with stakes, trade-offs, and a recommendation attached.
The other thing nobody mentions is the curse of knowledge. The mental model you built while doing the work is now invisible to you. You can no longer tell which parts are obvious and which aren't, because all of it feels obvious from where you're standing. So you skip exactly the steps that would have made the explanation land, because you literally cannot see where the gap is.
What actually helps
Lead with the answer, not the architecture.
The first sentence out of your mouth should be the thing they need to make a decision, in their language, with no acronyms. "Sales in the south region are down 12% versus last quarter, driven by two large accounts that haven't reordered." That sentence does what they came for. The model behind it can come second, if it comes at all.
Most of us do the opposite. We open with the data source, walk through the transformations, and arrive at the answer at minute eight. By then your manager has spent eight minutes trying to work out whether they should trust this and getting no signal either way. Frontload the conclusion. Earn the right to explain it afterwards.
Tell them what changed, not what's clever.
The instinct is to show off the elegant part. The calculation that handles the edge case. The relationship that makes the filter work properly. None of that means anything to them. What does mean something is the delta: what can you do now that you couldn't do before. "We can answer this in real time instead of waiting two weeks for the analyst team." That's the line that gets remembered.
If you can't articulate what changed for the person sitting across the table, you haven't finished the work. Building the thing is one half of the job. The case for why anyone should care is the other half, and it doesn't write itself.
Give them something they can repeat.
Your manager will need to describe what you built to someone else - their boss, a stakeholder, someone in finance. If you don't hand them a sentence, they'll improvise one, and the improvised version is almost always worse than what you would have written for them. The version that travels through the organisation is the version they can repeat from memory under mild pressure, not the version you delivered in the meeting.
Write the sentence yourself. "The new dashboard pulls live data from the order system and shows regional performance against target, with drill-down by account." Hand it over explicitly. "If you need to brief someone on this, here's how I'd describe it." That isn't over-explaining. That's giving them the piece they need to advocate for the work, which they can't do from a blank look.
This week
Pick one thing you've delivered in the last month that didn't land the way it should have. Write three sentences about it: what changed, why it matters, what someone non-technical would say about it to their own boss. Three sentences. No acronyms. No architecture. Send the third one to the person who needs to know.
The work doesn't get more visible by building more of it. It gets more visible by getting translated.
Frequently Asked Questions
Why doesn't my manager understand what I built?
Usually because you're answering a different question than they're asking. You're explaining how the work was done. They're trying to decide whether to trust it and what to do with it. Those need different framings - lead with the conclusion and what it changes, not with the architecture.
How do I demo technical work to non-technical stakeholders?
Start with the answer in their language, then show only the parts of the build that affect their decision. They don't need the schema or the formula. They need to know whether the number is reliable, what assumptions sit behind it, and what action it implies. Anything that doesn't move that conversation forward should come out of the demo.
What is the curse of knowledge in technical communication?
It's the cognitive bias that makes it hard to imagine not knowing something once you do know it. In stakeholder communication, it shows up as skipping steps that feel obvious to you but are missing context for everyone else. The fix is to assume nothing is obvious and have someone outside the work read or hear your explanation before you deliver it for real.
Should I focus on better communication or just delivering better work?
Both, but if you've delivered work that should have landed and didn't, the bottleneck is the communication, not the work. More good work doesn't fix invisible work. The skill of making technical work legible is separate from the skill of doing it, and it improves with the same kind of deliberate practice.