Late post today, sorry. I was up late diagnosing issues with the site, only to find out (around 4am my time, when Ash got up and helped out) I couldn’t actually do anything. Alas.
Searching for help in resolving a particular error was interesting, and paired with some other conversations I had earlier inspired today’s post. In searching for tips online, I had to filter through multiple pages giving tips like “repair the DB” and “try to resolve localhost”, without any indication whatsoever about what those actually mean. In my extremely-late-night mind fog, I was having trouble remembering how to do those things, and it got me thinking about how the language (and lack of details) was getting in my way.
A professor of mine once described jargon as “a shorthand language used to create haves and have-nots”, and separated it from professional shorthand while noting that the two look very similar. Jargon is useful when time-to-communicate is a valuable factor, but this is surprisingly rare. We’re in love with efficiency of communication, but I’ve commented before that we have a very reductive culture surrounding it, and I think that we often think we’re making communication faster and more efficient when what we’re actually doing is denying access to anyone who isn’t as in-the-loop as we are.
What I find interesting is what happens when two different types of jargon collide. I’ve spent a lot of time around highly technical people, and the idea of impenetrable technical jargon among engineers is pretty well known. What I’ve been discovering lately, as I delve deeper into business, is the jargon that exists in the business world, that’s every bit as complicated and detailed as the technical jargon.
If you’re reading this, you’re probably looking at the above image and alternately laughing or rolling your eyes. What’s really interesting to me is that every single one of these terms is functional, useful business shorthand that often gets used to exclude non-business types, in the exact same way technical jargon is. It’s used and misused in all of the same ways, and from the other side, the use of highly technical jargon gets the same not-always-so-gentle mockery as “business-speak” does.
What I wonder about is how the functionality of the two different types of jargon interact. One is operating on a (mostly) macro level, another is (mostly) operating on a micro level. An engineer can, after several minutes of someone being unable to process the language being used, just push their audience aside and say “look, let me just do it”. The same is not true in business, generally speaking– the jargon is used as shorthand for very large, slow processes and in many cases are more about applied psychology than technical skill– something that many people like to think they’re immune to and will resist as a matter of course if they see it in action.
One of the things I’ve been trying to do in my own communication is to be very precise with my choice of words, avoiding both technical and business jargon unless it’s precisely applicable and I know the person I’m talking to is aware of what I mean. It’s a surprisingly difficult thing to do, because the coded languages we use get very deeply ingrained.
Source: Digital Initiative
Jargon