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.
Obviously I’m biased, coming from the engineering side (even if it’s only software and not real stuff :P) but I think you’re missing a critical point – lack of ambiguity. I do agree one shouldn’t just throw jargon or technical terms around for fun and to look better, but – at least most of the times – even if it sounds horribly weird, it’s just the correct, unambigous thing to say.
Most of these examples on your image are more like ‘directions’ or ‘strategies’, but not simple, distinct, actionable items – and that’s what I’d call technical jargon. One person says it, other person from another company or part of the world (but working in the sam field) can instantly reproduce the result.
I absolutely agree that specificity can be important, but I also think that’s precisely what causes the have/have-not divide. Being very technically precise is unambiguous, certainly, but while it’s unambiguously accessible and correct if you’re “in the know”, it’s equally unambiguously useless if you aren’t. It’s only unambiguous in a useful way if you’re part of the club, as it were.
I also don’t agree that there’s a fundamental difference between direction/strategy and directly actionable items– it’s just a difference of macro vs micro, and at the macro stage, there’s always a certain amount of complexity that prevents simple actions. I don’t think the concept of, say, “synergy” is actually all that different between companies/parts of the world if you’re in the same field.