I asked one of my tech leads to demo the latest work to a cross-functional group. Business stakeholders. UX. Product. Engineering.
The work deserved the room's attention. His team had built out a component library using Storybook to streamline the design-to-development workflow. Designers could see exactly what engineers had built. Engineers could build exactly what designers intended. Handoff time dropped. Misinterpretations between the two disciplines that used to create entire cycles of rework were gone.
But he told the story in engineering. He kept referencing technical implementation details that sounded impressive from a developer's perspective but meant nothing to half the room. Contracts. CI/CD pipelines. Caching layers. Things that mattered deeply to how the work was built. Things that had zero relevance to why it was built or what it meant for the business.
The business side nodded politely. UX checked out. Product was trying to translate in real time. And the actual impact of the work got buried under terminology that only a third of the audience could parse.
If he'd stripped the jargon out, the demo would have landed. The work spoke for itself. The technical details were getting in the way of the story, not supporting it.
The Reddit Post Nobody Could Help With
I saw a post on Reddit where a dev was venting about their manager's manager going through every PR and demanding more productivity while adding more meetings. Used terms like "o3" for one-on-one, "N+1" for their manager, and "N+2" for the skip-level. The top comment with 44 upvotes was "Speak English brother."
Almost nobody addressed the actual problem.
Because nobody could understand the post.
Not because the problem was complex. Because the language was. The person asking for help had accidentally built a wall between themselves and the people who could help them. The jargon that made them feel precise was the thing that made them invisible.
This happens in engineering orgs every day. And it's not limited to Reddit.
Where Jargon Hides
The obvious version is the one everyone jokes about. Leaders who say "let's leverage our synergies to optimize velocity" when they mean "let's work together to ship faster." That's easy to spot and easy to mock.
The harder version is the one my tech lead did in that demo. The jargon wasn't corporate fluff. It was technically accurate. He wasn't wrong about anything he said. He was just saying it to the wrong audience. And the gap between technically accurate and actually understood is where communication goes to die.
The gap between technically accurate and actually understood is where communication goes to die.
I see it in docs that only the author can parse. In Slack messages that require three follow-up questions before anyone knows what's being asked. In meeting agendas written in shorthand that assumes everyone in the room has the same context. In architecture reviews where the presenter uses acronyms they invented for their own team and never defines them.
None of this is malicious. Most of it isn't even conscious. Engineers optimize for precision. Precision in language means using the most specific term available. The problem is that the most specific term is often the least accessible one. And accessibility is the whole point of communication.
Why It's Hard to Stop
Early in my career I used jargon because I thought it proved I belonged. I'd walk into a meeting with stakeholders and talk about "decoupled architectures" and "event-driven patterns" when what I meant was "we built it so changes in one place don't break everything else." I thought precision made me credible. What it actually did was make me forgettable. The stakeholders remembered the engineer who said the clear thing. Not the one who said the technically correct thing.
Jargon feels like competence. When you use the precise technical term, you signal depth. You signal that you've been in the room long enough to speak the language. That's not a small thing in an industry that respects technical credibility above almost everything else.
Stripping the jargon out feels like dumbing it down. And nobody wants to feel like they're dumbing things down. Especially not in front of stakeholders they're trying to impress.
But the most respected engineers I've worked with communicate like they're explaining to a smart friend.
The most respected engineers communicate like they're explaining to a smart friend. Not dumbing it down. Stripping it clean.
Not dumbing it down. Stripping it clean. They assume intelligence in the listener and take responsibility for making the complex thing simple.
The Distributed Problem
This gets worse when your team spans continents.
I lead engineering across North America, Europe, and Asia. English is the working language but it's not everyone's first language. And jargon that's already confusing to a native English speaker becomes completely opaque to someone parsing it in their second or third language.
An engineer in Serbia doesn't need you to dumb things down. They need you to say what you mean in words that translate cleanly. "We need to decouple the service mesh from the deployment pipeline" means something very specific to the person who wrote it. To someone reading it across eight time zones in a language they learned in school, every word in that sentence is doing double duty and half of them might not land.
I've watched async communication break down entirely because a Slack message used four acronyms that only one team understood. The follow-up questions took longer than the original conversation would have taken if it had been written in plain language from the start. And by the time the clarification arrived, the engineer in the other time zone had already moved on to something else. The window for collaboration closed because the message wasn't clear enough to act on. Multiply that across a distributed org and jargon isn't just a communication problem. It's a productivity tax.
What I Told My Tech Lead
After that demo, we had a conversation. Not a correction. A reframe.
The work was excellent. The delivery obscured it. And that's the worst outcome for an engineer. Not that the work was bad. That the work was good and nobody in the room could see it because the language got in the way.
I asked him one question. "If you were explaining this to your wife, what would you say?"
He laughed. Then he said it in two sentences. Clear. Specific. No jargon. The impact was obvious. The value was immediate.
That's the version the room needed. And it was already in his head. He just needed permission to use plain language in a professional setting. Because somewhere along the way, engineering culture taught him that simple language means simple thinking. It doesn't. Simple language means you've done the hard work of understanding something well enough to explain it without the crutch of terminology.
The conversation wasn't about his technical skill. That was never in question. It was about reading the room. A demo to engineers should sound like engineering. A demo to a cross-functional group should sound like a story about what changed for the customer, the business, or the product. The technical depth lives underneath. It comes out when someone asks a question. Not before.
I've watched this pattern play out across every org I've been part of. The engineers who get promoted fastest aren't always the strongest technically. They're the ones who can walk into any room and adjust. They give the CTO the architecture. They give the VP of Product the customer impact. They give the designer the user experience implications. Same work. Different lens. The substance doesn't change. The translation does.
That's the skill most engineers never get coached on. Not what to say. Who they're saying it to. And adjusting the message without losing the substance.
Not what to say. Who they're saying it to.
The Real Test
If your message needs a glossary, rewrite it. If a new hire couldn't understand your meeting agenda, simplify it. If someone outside your team couldn't follow your Slack message, it's not clear enough.
That's not about lowering the bar. That's about raising your ability to communicate across the bar. The engineer who can explain a complex system to a product manager in plain language understands that system better than the engineer who can only explain it in technical terms. Because they've done the extra work of translation. And translation requires deeper understanding, not shallower.
My tech lead got this. The next demo he gave was the same level of technical depth underneath but the presentation was stripped clean. Business stakeholders asked questions. UX engaged. Product connected the work to the roadmap. The room was alive instead of politely confused.
Same engineer. Same quality of work. Different level of communication. And suddenly the work got the recognition it deserved.
Jargon doesn't make you senior. Clarity does.
I write daily about engineering leadership at jonoherrington.com.
Top comments (21)
the Storybook story lands because it is the exact moment where technical fluency stops being enough. the work was real but the room missed it. I see this most with PMs and engineers cross-communicating - same outcome, completely different story depending on who is telling it. jargon is often just speaking to yourself out loud
Exactly ... technical fluency can build the thing, but it cannot carry the room by itself.
That is where a lot of good work dies. Not because the work was weak, but because the translation was. PMs, engineers, designers, stakeholders ... they can all be looking at the same outcome and still walk away with different stories about what happened.
“Jargon is often just speaking to yourself out loud” is dead on. At that point communication stops being shared understanding and turns into self expression.
the translation layer is where seniority actually shows up. anyone can build the thing. fewer people can tell the story of what the thing does for the people in the room who don't care about how it was built
Been on both sides of this. I've given demos where I went too deep into the technical weeds, and I've sat through demos where I had zero idea what the presenter was talking about because they assumed everyone knew what a CI/CD pipeline was.
The trick I've started using: before any presentation, I ask myself "if my mom was in the room, would she get the point?" Obviously she doesn't need to understand the implementation, but she should understand the IMPACT.
Also worth noting - this isn't just a presentation skill. It shows up in PRs, Slack messages, and even standup updates. The devs I respect most are the ones who can explain a complex migration in two sentences that anyone on the team can follow.
That is a strong test.
A lot of engineers think clarity means losing substance, but it usually means they finally got to the substance. The part you called out about PRs, Slack, and standups matters too ... unclear language does not just hurt presentations, it slows the whole operating system.
If you’re trying to sound smart, you’re compensating. Just talk like a person lol we’re all smart here we know. Overused jargon is sooooo cringe.
Agreed ... overexplaining with words usually reads like insecurity, not depth.
The people who actually know their stuff can usually switch registers fast and say the same thing in clean language without losing the point. That is the real signal.
This is important for communication in general. I wasn't sure why this happens and thought it was because that's how it is. Glad I wasn't the only one noticing this.
You mentioned "Leaders who say "let's leverage our synergies to optimize velocity" when they mean "let's work together to ship faster." That's easy to spot and easy to mock." stood out to me. I feel like the Jargon is only used to make it sound "smart" in some way. In actuality, it makes it more confusing than it is. When I am explaining to my non-technical friends, I tend to be very straightforward about what I am building. If I get technical in some way, they lose interest almost immediately.
Great take @jonoherrington! Keep it up and hope your journey goes well :D
Most people assume jargon is about sounding smart. It is usually about avoiding accountability.
Plain language forces clarity on what is actually being done and who owns it. Once you say it simply, gaps show up fast. Scope is fuzzy. Ownership is unclear. Risk becomes visible. Jargon lets all of that stay hidden behind noise. That is why it shows up more as people move up. The stakes get higher and so does the incentive to blur the edges.
When you explain things to your non technical friends and they stay engaged, that is signal. You actually understand what you are building. Most teams skip that test entirely.
That is quite interesting. I never really thought about using Jargon to avoid accountability. I tend to think it as "oh, this person is smart or something". It does make sense now why it is currently existing. Thought I was the one who didn't understand since my Vocabulary is not really good.
That’s the honest part most people don’t say ... but let's be honest, even people with strong vocabularies get lost in it.
It’s not about how good your vocabulary is. It’s about whether the language is doing work or hiding it.
As a CTO, I catch myself doing this sometimes — dropping acronyms in standups that half the team doesn't need to know. The real test isn't whether you know the jargon, it's whether you can explain a distributed system to a product manager in terms they can act on.
One of our best engineers writes the most straightforward PRs I've ever reviewed. No clever abstractions, no "elegant" patterns — just code that reads like documentation. Our PMs can now run all 15 of our microservices locally and test features themselves. That only happened because someone made it simple enough that jargon wasn't required. That's senior.
That is exactly it ... the test is not whether we know the language. It is whether other people can actually move because of how we explained it.
I love that example of your engineer too. Simple code, clear PRs, PMs able to run services locally and test for themselves ... that is real leverage. A lot of people call that “less sophisticated” when it is actually more senior because it expands who can participate.
That is the part people miss. Simplicity is not a lack of depth. It is depth translated well.
"Simplicity is not a lack of depth. It is depth translated well." — stealing this for every code review I give from now on. This is exactly the bar we set. When a PM can read your PR description and understand what changed without asking you to translate, that's senior engineering. The jargon-heavy version isn't more precise — it's just less accessible. And inaccessible code is unmaintainable code, no matter how clever it looks.
I hate it when people abbreviate to acronyms. I think is worse that just shorting words. But it is not a developer only trait, I feel the larger a company gets the more acronyms are used.
A little while ago someone mentioned in a conversation c-level managers. It was only after the conversation I understood it was CEO, COO, ... . It didn't register because we were speaking Dutch and there is a native term to address that level of management.
Analogies are a good tool to explain technical concepts to a broader public. They don't have to 100% correct, it is more to show the intend of the concept.
Acronyms are one of those things that feel efficient … until you’re not in the room where they were defined.
They compress language for insiders and create friction for everyone else. What reads like speed to one group reads like translation work to another.
The part that stood out is your point about scale. The bigger the company gets, the more language turns into shorthand for alignment … but it also becomes a gate. If you don’t speak it, you’re already behind.
Analogies do the opposite. They expand understanding instead of compressing it.
Curious how you’ve seen teams balance that … when does shorthand actually help, and when does it start slowing people down?
Within divisions it works because then it is the same "language".
It gets messy once acronyms are used over two or more divisions or management levels.
My game was to make up the most ridiculous string of words when I encountered an acronym I didn't know.
That’s exactly where it flips ... inside a team it feels like speed, across teams it turns into translation work.
The part most people miss is that it scales invisibly. Each group optimizes locally, and suddenly nobody shares the same language at the edges.
I like your approach though ... humor surfaces the gap without turning it into a fight.
Being able to understand something complex at a technical level, to the degree where you can explain it to someone else without the technical jargon, to me is what demonstrates a superior level of understanding. This is why there's even a whole subreddit dedicated to this very concept called Explain Like I'm Five.
In my opinion: anybody who has a true and fundamental understanding of a complex topic should be able to explain that topic not only without the jargon, but perhaps even simple enough where a five year old could understand it.
There’s truth in that ... but it can get taken too far. Not everything should be explainable to a five year old. Some complexity is real, and stripping it too far can lose the tradeoffs that actually matter. The skill isn’t making everything simple ... it’s knowing what level of detail the room actually needs.
How do you decide where that line is?
IMO, there's no across-the-board answer here.
An effective communicator modules to their audience. That's your line, and its contextual.