You're good at the technical part.
It's explaining it that's killing you.
HEARD is a short, practical communication workshop for technical professionals who need their ideas to land.
Make complex ideas clear, concise, and actionable without dumbing them down.
Get early accessSomeone asks:
"Can we ship this Friday?"
You know it's complicated.
There are dependencies. Risks. Edge cases. Something QA found yesterday.
So you start explaining.
Four minutes later, your boss is still waiting for the answer.
They didn't ask for the architecture.
They asked if you can ship Friday.
Answer first. Explain second.
Same expertise.
Completely different communication.
That's what HEARD is about.
Smart technical people do this all the time.
I've spent decades working with and leading technical teams, and I've watched the same communication problems happen over and over again.
They bury the answer.
Ask a yes-or-no question and get five minutes of context before you get the answer.
They save the good part for last.
Everyone came for the demo.
Instead, they get 25 minutes of architecture, technical challenges and lessons learned.
Then: "Okay, let me show you the demo."
Half the room has already stopped listening.
Show me the damn demo.
Then tell me how hard it was.
They assume instead of asking.
Your boss keeps digging into the details.
You decide: They don't trust me.
Your boss isn't hearing enough from you and decides: I need to stay closer to this.
So they ask more questions. You feel more micromanaged. You communicate less. They ask even more questions.
Two intelligent people have created an entire dysfunctional relationship based on assumptions neither one has bothered to test.
Sometimes you need to stop talking about the work and start talking about how you're communicating about the work.
The problem isn't intelligence.
Sometimes it's intelligence itself.
The more deeply you understand something, the harder it can become to remember what it's like not to understand it.
Researchers call this the Curse of Knowledge.
But your audience doesn't need everything that's in your head.
They need the right information, in the right order, at the right level of detail.
That's a skill. And you can learn it.
The HEARD Method
I'm building HEARD around five practical communication moves.
Headline it.
Give them the answer first.
Don't make people search for your point.
Edit it.
Your audience doesn't need everything you know.
Decide what matters. Cut what doesn't.
Anchor it.
Give the idea something people can hold onto.
An example. A comparison. A number. A short story. Make the complicated thing understandable.
Real, not abstract.
Trade abstractions for specifics.
Don't say: "Engagement declined significantly."
Say: "Four out of ten users never came back."
Specific beats abstract.
Deliver it.
Put the message together and use it.
Not on a fake exercise. On something you actually need to communicate.
Built to use, not just consume.
Bring something real: a presentation, recommendation, demo, executive update, or difficult conversation.
HEARD is for technical people whose careers increasingly depend on other people understanding them.
Engineers. Architects. Product people. Technical leaders.
Especially anyone reaching the point where being right isn't enough anymore.
The higher you go, the less you're paid simply for knowing the answer.
You're paid for helping other people understand it, believe it, and act on it.
Why I'm building this
I've spent decades working in and leading technology organizations, and I've coached enough technical professionals and leaders to see the same pattern repeatedly:
Sometimes it produces the opposite.
HEARD combines lessons I've learned from those real situations with established work in cognitive science, information design, persuasion and communication.
Just a practical system you can use before your next important conversation.
Want to be one of the first to try HEARD?
The first version will be deliberately small: about an hour, practical exercises, a HEARD reference guide, and a framework you can use immediately.
I'm opening it to a small early-access group first. Join the list and I'll let you know when it's ready.
No spam. Just HEARD and occasional practical ideas about communication and technical leadership.
Your expertise shouldn't disappear inside your explanation.
Headline it. Edit it. Anchor it. Make it real. Deliver it.
Get to the point. Make it matter.
Get HEARD.
Get early access