The Technical Explanation Formula
How to Explain Anything Technical to Anyone Non-Technical
The Curse of Knowledge
Here's the problem: you understand your work so deeply that you've forgotten what it's like to not understand it. So when a client asks 'what does your software do?', you start talking about APIs and microservices and scalability... And their eyes glaze over. Not because they're stupid—because you're speaking a language they don't speak. This formula fixes that.
The AWE Formula
A = Analogy First
Start with something they already understand. Connect the unknown to the known before introducing new concepts.
Wrong:
"Our API uses RESTful architecture with JSON payloads to enable seamless data exchange between microservices."
Right:
"Think of our system like a universal translator. When your different software systems need to talk to each other, ours makes sure they all speak the same language."
Why it matters:
Analogies create a mental hook. Technical descriptions create confusion.
Action Item:
Before any technical meeting, prepare one analogy for your core offering.
W = What It Does (Not How)
Executives care about outcomes, not mechanisms. Tell them what it does for them—not how it does it.
Wrong:
"The system uses machine learning algorithms to analyze historical transaction patterns and flag anomalies using statistical deviation thresholds."
Right:
"It catches fraudulent transactions before they clear—automatically. Your team only sees the ones that need human review."
Why it matters:
They're buying the outcome. The 'how' is your job to worry about.
Action Item:
For every feature, complete this sentence: 'This means you can ______.'
E = Evidence
Abstract claims don't convince. Specific numbers and examples do.
Wrong:
"Our solution significantly reduces processing time."
Right:
"Our last client went from 3 days to process invoices to 4 hours. That freed up two full-time staff for higher-value work."
Why it matters:
Numbers are memorable. 'Significant improvement' is forgettable.
Action Item:
Keep a list of 3-5 specific results you can cite in any meeting.
Check for Understanding
Don't wait until the end to see if they're following. Check in regularly—and adjust if they're lost.
Wrong:
"[30-minute monologue] ...and that's how the system works. Any questions?"
Right:
"Before I go deeper—does that make sense so far? Any questions about how this would work in your environment?"
Why it matters:
Small check-ins prevent big misunderstandings. They also make you look confident.
Action Item:
Stop every 2-3 minutes and ask 'Does that make sense?' or 'What questions do you have so far?'
Complete Example: Explaining Cloud Migration
**Without the formula:** 'We'll containerize your applications using Kubernetes, deploy them on AWS infrastructure with auto-scaling capabilities, implement CI/CD pipelines, and establish monitoring through Prometheus and Grafana dashboards.' **With the AWE formula:** 'Think of your current system like owning a house—you're responsible for everything: the plumbing, the electricity, the roof. [ANALOGY] Cloud migration is like moving to a building where someone else handles all of that. You just use the space. [WHAT IT DOES] Our last client reduced their IT infrastructure costs by 40% and their team now focuses on features instead of server maintenance. [EVIDENCE] Does that make sense for your situation?' [CHECK]
Robert Cushman
I help Latin American tech professionals communicate with executive-level confidence so they can close bigger contracts, command premium rates, and advance their international careers.
After coaching 200+ professionals from Smarttie, Grupo Kopar, Terramar Brands, and Sourceability, I know that what separates good from great in high-pressure meetings isn't vocabulary—it's leadership communication.