Someone recently posted an interesting question and answer over at TechWR-L that I wanted to touch on briefly as it is a topic on my (obviously) neglected list of things to blog about. The question was about how much jargon is okay to use in documentation. The answer posted in a comment was:
You only have too much jargon if the jargon interferes with the ability of the audience to understand what you’re trying to communicate. If the audience speaks that jargon on a daily basis, you’re doing them a disservice by trying to eliminate their jargon.
The word jargon comes loaded with a lot of negative connotations. Think corporate jargon: “leveraging synergistic best practices going forward.” And obviously, that sort of nonsense just attempts to obfuscate the fact that the person using the phrase has no idea what they’re talking about.
But when you’re talking about industry-specific terminology, jargon plays an important role. It increases the efficiency of communication between members of the community by cramming a whole lot of meaning into a small linguistic space. You can say SOA to software developers and activate a whole slew of concepts in their mind with three letters. It would take paragraphs or pages to give a layperson even the highest-level understanding of the same.
And isn’t efficiency of communication a best practice that technical communicators should be leveraging?
Ultimately, the issue boils down to one of knowing your audience. Can you be sure that your audience is familiar with the terminology? It can be a difficult issue, especially when you’re writing about a topic with which you don’t have a lot of familiarity. Remember that just because you don’t know what industry terms mean does not mean your audience doesn’t.
This is something that technical writers have to work with their subject matter experts (SME) to determine. “Does the audience know what this term mean,” is a good question. I’ve found that often SMEs haven’t given the question a lot of thought, and asking them provides a good starting point for a discussion about what the audience knows.
One point to keep in mind here is that your primary audience isn’t always your only audience.
That said, if you can be sure your audience is familiar with the terminology, you won’t be doing them any favors by cutting out jargon for the sake of cutting out jargon.
2 replies on “In Defense of Jargon”
I’m in full agreement . . . almost.
Your main points are exactly right. But even a phrase like “leveraging synergistic best practices going forward” can have a specific meaning to a specific audience.
For example, I write corpcom (now that’s jargon!) for a Fortune 500 company recently acquired by a Global 500 company. When the giants speak between themselves, they often use a little jargon.
To simplify a complex business model, what the acquirer bought was synergies. One example is the acquired company’s metalcasting expertise and capabilities, which fill a strategic gap in the acquirer’s global chain.
Some of the acquired company’s best practices relate to those synergies. And those will be leveraged going forward, or a few billion bucks will have been wasted.
Of course any idiot can string the words together — Dilbert used to run a great “mission statement generator” that would do it for you — and rampant overuse compounds the problem.
But I can see such a phrase in a C-level communication, and not just to obfuscate the writer’s ignorance.
But otherwise — well said.
Steve, thanks for the great comment. You’re right that my example phrase could actually be meaningful to some people, but that doesn’t make it more valuable. “Leveraging synergistic best practices” doesn’t pack any extra meaning into the phrases because it doesn’t pack in any specifics. You could rephrase it in plain English to a much stronger effect without bumping up your word count much. In fact, your plain English example was far more powerful. The whole purpose of using a phrase like that is at best to be isolating, at worst to obfuscate the writer’s ignorance.
On the other hand, if we build on my technical jargon example a little bit, I could say that “We’re going to convert our backend to an SOA based on RESTful APIs.” And while that is also isolating to the layperson who has no clue what it means, it serves a purpose because it packs in a ton of specifics to the intended audience. The intent here is not isolate or obfuscate; the intent is efficiency of communications.
I think you hit the nail on the head when you said that rampant overuse compounds the problem. I know I turn off immediately when I hear someone say we’re going to leverage anything. So, while “leveraging synergistic best practices” certainly can mean something, my question is what benefit do you get when you could easily say the same thing in plain English to better effect? I’d still contend that corporate jargon of that sort serves no real benefit except to identify the speaker as a member of the club. As you say, “When the giants speak among themselves, they often use a little jargon.”