There's a temptation in technical work to use jargon as a shortcut. And between peers, it is one. Saying "we need to refactor the auth middleware" to another developer is efficient and precise. But the same sentence in a client meeting does one of two things: it confuses them, or it makes them feel like you're showing off. Neither helps.
The tricky thing about jargon is that it's invisible to the person using it. After years in a field, technical terms stop sounding technical. They just sound like words. You forget that "API," "deployment pipeline," and "microservices" aren't common English. The curse of expertise is that you lose the ability to hear your own language the way outsiders hear it.
Why this matters
When a client doesn't understand what you're saying, they usually won't tell you. They'll nod and say "that makes sense" and move on. And then they'll make decisions based on a misunderstanding, or go quiet because they feel out of their depth. I've had clients bring in other people to "help with the technical conversations," which is polite code for "I can't understand you and I need a translator."
Jargon creates distance. Every term the client doesn't understand is a small wall between you. Enough walls and you're no longer collaborating; you're performing for an audience that can't follow the show.
There's also a subtler problem: jargon can feel like a power play. Whether you intend it or not, using language someone doesn't understand puts you in the position of expert and them in the position of outsider. Some clients feel talked down to. Others feel excluded. A few get defensive. None of these reactions help the project.
The goal isn't to avoid technical concepts. It's to talk about technical concepts in language the client can actually engage with.
How I think about this
Your audience determines your vocabulary. This sounds obvious, but most jargon problems come from not adjusting. The explanation you give a developer is different from the one you give a product manager, which is different from the one you give a CEO. Same concept, different words.
If you wouldn't say it to your neighbor, rephrase it. Quick mental check: if you were explaining this to a smart person who doesn't work in tech, would you use this term? If not, find another way. "We're restructuring the code to make it easier to change later" works better than "we're refactoring" in most client conversations.
Jargon is fine when it's shared. If the client uses technical terms comfortably and correctly, match their level. The point isn't to avoid all technical language forever. It's to avoid language the other person doesn't share. Some clients are deeply technical. Dumbing things down for them is its own kind of insult.
Watch for the glaze. When you're talking and someone's eyes go slightly unfocused, or they stop asking questions, or they start saying "sure, sure" to everything, you've probably lost them. That's the moment to pause and check: "Am I making sense, or did I just go too deep into the weeds?"
What this looks like
Translating on the fly
Instead of: "We need to set up a CI/CD pipeline to automate the deployment process."
Try: "We need to set up an automated system so that when we make changes to the code, they get tested and published to your site automatically, instead of someone having to do it manually each time."
Instead of: "The latency is caused by N+1 queries in the ORM layer."
Try: "The page is slow because the system is making hundreds of small database requests when it should be making one big one. It's like going to the grocery store and buying one item at a time instead of filling up a cart."
Instead of: "We should containerize the application and orchestrate with Kubernetes."
Try: "We should package the application so it runs the same way everywhere, and use a system that automatically manages it, starts new copies if traffic increases, restarts things if they crash. Like having an autopilot for the infrastructure."
Why It Works
Same technical concept, accessible language. The client can understand the what and the why without needing a computer science degree.
Checking your level
Early in a new client relationship:
"Before I get into the technical details, it'd help me to know: how deep do you want me to go? Some clients prefer the high-level business impact. Others want to understand the technical specifics. I'm happy either way. Just want to make sure I'm talking at the right level."
Why It Works
Respectful. Gives them agency. Prevents both over-explaining and under-explaining.
Catching yourself
Mid-explanation, you realize you've slipped into jargon:
"So we need to migrate the database schema to, actually, let me back up. We need to reorganize how the data is stored. Think of it like reorganizing a filing cabinet: the files are the same, but we're changing how they're sorted and labeled so the system can find things faster."
Why It Works
Catching yourself and correcting is natural. Everyone does it. It shows self-awareness and respect for the listener. Much better than plowing ahead and hoping they follow.
Creating a shared glossary
For a longer engagement:
"Since we'll be working together for a while, I put together a short list of terms that might come up and what they mean in plain English. Not because I think you need a glossary, but because some of these words get used differently in different contexts, and I want to make sure we're always talking about the same things."
Why It Works
Proactive. Framed as avoiding miscommunication, not as educating them. Becomes a reference both sides can point to.
What to watch out for
Showing off with vocabulary. Using technical terms to demonstrate expertise is tempting, especially when you feel insecure about your position. But expertise that can't be communicated clearly isn't useful to the client. The most impressive thing you can do is make complex things sound simple.
Acronym soup. "We'll use the API to connect the CMS to the CRM via the CDN." Each of those letters means something, but strung together they're meaningless. If you must use acronyms, define them on first use. Or just don't use them.
Insider references. Beyond technical terms, every industry has inside jokes, references, and cultural shortcuts. Mentioning "the Joel Test" or "Conway's Law" in casual conversation assumes a shared context that may not exist.
Overcorrecting into condescension. There's a line between clear language and talking down to someone. "So, a computer has something called a 'database,' which is like a big filing cabinet for information..." If they're a VP who runs a tech company, you've just insulted them. Read the room. Adjust to their actual level, not a caricature.
Using jargon as a shield. Sometimes people use technical language to avoid being questioned. If the client doesn't understand the terms, they can't push back. This is a power move, not a communication strategy, and clients eventually figure it out.
Getting better at this
Practice explaining your work to non-technical people. Friends, family, anyone outside your field. If you can explain what you do and why it matters to your parents, you can explain it to any client.
Record yourself in meetings. Listen for terms you used that might not have been understood. Count the jargon. You'll be surprised. Most of us use far more than we realize.
Develop plain-language alternatives. For the ten technical terms you use most often, write down a plain-English equivalent. Practice using the plain version until it's as natural as the technical one.
Ask clients to reflect back. Instead of "does that make sense?" (which everyone says yes to), try "how would you describe this to your CEO?" Their answer tells you exactly how much they understood.
Notice when you're adapting well. Pay attention to the conversations where clients are engaged, asking good follow-up questions, and using the concepts back to you in their own words. That's what clear communication looks like. Replicate whatever you did in those moments.
How this connects
Avoiding jargon is the practical foundation of explaining complex concepts without condescension. It makes analogies more necessary and more effective, because when you strip away the jargon you naturally reach for comparisons instead. It also quietly improves every email, every demo, and every status update you give.
Things to try
- In your next client email, do a jargon check before sending. Replace every technical term with a plain-English alternative and see if the email is clearer.
- Ask a non-technical friend to read something you've written for a client. Circle everything they don't immediately understand.
- Develop plain-language versions of your five most-used technical terms. Write them down and practice using them.
- Next time you catch yourself using jargon in a meeting, pause and rephrase. It gets easier with practice.
- After a client meeting, ask yourself: was there a moment where I lost them? What term or concept caused the disconnect?
The people I've learned the most from never made me feel stupid for not knowing something. They just explained it in a way that made me wonder why I hadn't seen it before. That's what I'm aiming for in every client conversation. Not dumbing things down, just making them clear enough that the client can actually think with me instead of just nodding along.