There's a specific kind of bad that happens when a smart person explains something poorly. Either they dump jargon and the client drowns, or they oversimplify and the client feels patronized. Both are failures of the same thing: not thinking about the explanation from the other person's perspective.
The best explainers I've worked with share a trait. They make you feel smarter after talking to them, not dumber. They don't show off what they know. They use what they know to help you understand. That distinction matters more than almost any other communication skill.
Why this is so hard to get right
It's not that clients aren't smart. They're usually very smart, just in different domains. Your client who can't follow a conversation about database normalization might be an expert in supply chain logistics or healthcare regulation. The gap isn't intelligence, it's context.
The tricky part is that once you've spent years building expertise, you forget what it was like to not have it. You forget which terms are jargon. You forget which concepts need scaffolding. You take for granted the mental models that took you years to build. This is the "curse of knowledge," and it makes even well-intentioned explanations land badly.
When you get it right, though, something valuable happens. Clients become better collaborators. They ask better questions. They make more informed decisions. They stop nodding along while being secretly confused, which means fewer expensive misunderstandings later.
How I think about this
Respect intelligence, acknowledge context gap. I start from the assumption that the person is smart and capable, they just haven't spent years in my specific corner of technology. That reframe changes everything about how I explain things. It's not "let me dumb this down for you," it's "let me bridge the gap between what you know and what you need to know."
Teach, don't lecture. Teaching is collaborative, responsive, built on what they already know. Lecturing is one-directional and assumes ignorance. When I'm explaining well, I'm checking in, adjusting, building on their responses. When I'm lecturing, I'm performing.
Match depth to need. Not everyone needs the same level of detail. A client making a strategic decision needs enough to understand trade-offs. A client who's curious but not deciding doesn't need a technical deep-dive. Before I explain anything, I ask myself: what level of understanding do they actually need here?
Use their language. Start with concepts they already understand and build bridges to the new ones. If they work in retail, use inventory and point-of-sale analogies. If they work in finance, use portfolio and transaction analogies. Meet them where they are.
What this looks like
Bridging from familiar to unfamiliar
Client asks: "What's an API and why do we need one?"
"An API is basically a way for two software systems to talk to each other. Think of it as a translator between two people who speak different languages. In your case, your website needs data from your inventory system. Instead of someone manually copying that information every day, an API lets the two systems share it directly. Saves time, prevents mistakes, keeps everything in sync.
Does that make sense, or would it help to walk through a specific example?"
Why It Works
Familiar analogy. Connected to their actual need. Explained the value in business terms. Invited questions without assuming confusion.
Layered explanation
Client asks: "Why will the database migration take two weeks?"
First layer: "The database is where all your customer data lives. Names, orders, preferences, everything. We're moving it to a faster, more reliable system. Two weeks accounts for three things: carefully moving everything without losing any data, thorough testing to make sure it all works in the new system, and having a backup plan if something goes wrong. The actual move might take a day, but the preparation and verification take longer because we can't afford to lose customer data."
Then: "Happy to go deeper on any part of that. The testing process, the migration steps, the technical reasons for the upgrade. What would be most useful?"
Why It Works
Complete understanding without jargon. Explains the timeline in terms of risk management, which they care about. Offers depth without pushing it.
Reading confusion and adjusting
You're explaining something and notice glazed eyes:
"I realize I'm throwing a lot at you. What makes sense so far, and where can I add clarity? I want to make sure we're on the same page."
Or: "Let me try this from a different angle." Then offer a simpler explanation or an analogy.
Why It Works
Takes responsibility for the confusion rather than implying it's their fault. Offers to adjust rather than plowing ahead. Makes it safe to say "I'm lost."
The business translation
Client asks: "What's the difference between these two technical approaches?"
"Both accomplish your goal, but the trade-offs are different.
Approach A is faster to build. We'd be done three weeks sooner. But it's harder to modify later. Think of it like a pre-built house: move in quick, but renovations are expensive.
Approach B takes longer upfront but is much more flexible for changes. Like building custom: longer construction, but you can adapt it as needs evolve.
Given that you mentioned expanding features next year, I'd lean toward B. But if getting to market fast matters more than future flexibility, A makes sense. What's more important for your situation?"
Why It Works
No jargon. Clear analogy. Trade-offs framed in business terms. Connected to their stated goals. Asked for their input.
What bad looks like
The jargon dump. "We're implementing a RESTful API architecture with JWT authentication, using OAuth 2.0 flows for authorization..." Client is lost after the first phrase but too embarrassed to say so.
The patronizing oversimplification. "Don't worry about that. It's pretty technical stuff. Just trust me." Dismissive. Creates hierarchy. Insults their intelligence.
The extended metaphor that breaks. "Your data is a castle, and hackers are dragons, and the firewall is a moat..." By the time you get to the secret medallion at the drawbridge, you've lost them worse than if you'd just explained it straight.
The impatient expert. Client asks a follow-up question. Heavy sigh. "Like I said, it's because of the API limitations." This kills questions. Dead questions mean hidden confusion, which means expensive mistakes later.
The wrong-level assumption. "Now, I know computers are confusing, but let me explain in really simple terms..." If they have a CS degree, you've just insulted them. Always check before assuming.
Getting better at this
Start with an understanding check. Before explaining anything, ask: "How familiar are you with [concept]?" or "Have you worked with something like this before?" This prevents both over-explaining and under-explaining in one move.
Build an analogy library. For the concepts you explain regularly, develop two or three different analogies and test them with different people. Know where each analogy breaks down and be upfront about it.
Master the two-level explanation. Prepare a 30-second high-level version and a 3-minute detailed version. Deliver the short one first, then ask: "Would it be helpful to go deeper?" Let them pull the detail they want.
Watch for comprehension signals. Engagement, follow-up questions, rephrasing back to you: they're getting it. Blank stares, false nodding, avoiding eye contact: they're not. Adjust in real time.
Invite questions actively. "What questions do you have?" (assumes questions exist) is much better than "Does that make sense?" (which people always say yes to). Even better: "What part should I clarify?"
Check understanding without quizzing. "Just to make sure I explained that clearly, how does this fit with what you were thinking?" frames it as checking your explanation, not testing their comprehension. Nobody wants to be quizzed.
Remember what it was like to not know. What confused you when you were learning? What explanation finally made things click? What assumptions do you take for granted that beginners don't have? Technical empathy makes you a better explainer.
How this connects
This is closely related to knowing when to dive into technical details (calibrating depth), using analogies and visuals (your primary tools), reading the room (noticing when you've lost someone), and establishing expertise without intimidation (demonstrating competence without making people feel small).
Things to try
- Pick three concepts you frequently explain. Develop a simple analogy for each.
- Record yourself explaining something technical and listen back. Count the jargon.
- Next time you explain something, use the two-level approach: brief overview, then ask if they want more.
- After an explanation, ask the client: "Was that clear? How could I explain it better?"
- Explain a technical concept to a non-technical friend. Notice what works and what doesn't.
Your expertise is most valuable when it's accessible. Every time you explain something clearly without talking down, you're building trust, showing respect, and becoming a better partner. The goal isn't to make clients into experts. It's to give them enough understanding to make good decisions and feel respected in the process.