There’s a Home Improvement episode where Tim tries teaching Jill how to fix a sink. He buries her in technical terminology, she gets frustrated, and eventually he realizes he was using jargon to protect his status as the expert in the room. It’s played for laughs, but I’ve watched that exact scene play out in professional settings more times than I can count.
If the “dumb” question consistently turns out to be the question everyone needed asked, it was never dumb.
Early in my career I started noticing a pattern in meetings. Someone would use a term or reference a concept, and I could see on people’s faces that they didn’t follow. But nobody said anything. Everyone just nodded and moved on. The meeting would continue, decisions would get made, and half the room would leave without actually understanding what they’d agreed to. Then two weeks later the same group would be back in a room trying to figure out why the project was off track.
That pattern is what led me to where I am today, where I’ll sometimes literally say, “I have a possibly dumb question.” The irony is that the response almost always starts with “that’s a great question” or “that’s not actually a dumb question at all.” Which kind of validates the whole point. If the “dumb” question consistently turns out to be the question everyone needed asked, it was never dumb. It was just the one nobody else wanted to be first to say out loud.
What jargon is actually doing
What I noticed over time is that the jargon problem isn’t really about vocabulary. It’s about what the jargon is doing in the conversation. Sometimes technical language is genuine shorthand between people who share context. Two engineers talking about race conditions or two painters talking about value structure, that’s just efficient communication. The language earns its place because both people know what it means.
But a lot of the time, especially in cross-functional settings, jargon is doing something else entirely. It’s a way to sound authoritative without being clear. It’s a way to avoid the vulnerability of simple language, because simple language can be questioned and challenged in ways that jargon can’t. If I say “we need to leverage our synergistic capabilities to optimize the value stream,” nobody knows what to push back on. If I say “we should combine these two teams because they’re doing the same work,” now we’re having a real conversation, and I might be wrong.
I’ve been on both sides of this. I’ve caught myself burying a point in technical language because I wasn’t fully confident in the point itself. The jargon was insulation. If nobody could parse what I was saying, nobody could tell me it didn’t make sense.
The thing that keeps striking me about it is how much time gets wasted. Not just in the meeting itself, but in all the follow-up conversations where people try to figure out what was actually said. Or worse, when they don’t have those conversations and just build on assumptions that were never validated. I’ve seen entire project timelines slip because two groups left the same meeting with completely different understandings of what was decided, and both thought they were right because the language was vague enough to support either interpretation.
Plain, not dumbed down
The older I get, the more I value the people who make things plain. Not dumbed down. Plain. There’s a difference. Dumbing something down strips out the nuance. Making it plain preserves the nuance but uses language that actually communicates it. The best technical communicators I’ve worked with can explain complex systems to non-technical people without losing anything important.
When I first started asking, it felt like I was exposing that I’d missed something everyone else hadn’t. Now when I get that feeling, I just ask.