I asked one of my tech leads to demo the latest work to a cross-functional group. Business stakeholders. UX. Product. Engineering.
The work deserv...
For further actions, you may consider blocking this person and/or reporting abuse
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.