Eschew Obfuscation (Communicate Clearly)
Many years ago, I worked for a manager who had two signs on his desk. The first was a pencil with the words, “Pencil 2.0” printed above them. The rest of the sign went on to explain how the pencil had undo (the eraser), was renewable (it can be sharpened), etc. The second sign was simpler, just two black words printed across a white background.
Eschew Obfuscation
Being just out of the US Air Force, and not having quite the vocabulary I should have (have I ever told you that reading is the key to having a great vocabulary?), I didn’t really understand the point. Now I do. Okay, to make it more obvious, from the Collins English Dictionary, 8th edition:
eschew: tr to keep clear of or abstain from (something disliked, injurious, etc.); shun; avoid
obfuscation: the act or an instance of making something obscure, dark, or difficult to understand
Now do you see? Avoid using language people can’t understand. Far too often, in the technical world, we use abbreviations, acronyms, and all sorts of cute nonsense to say things. We pepper our language with shorthands and inside jokes (squirrel!). While this sometimes helps communication, sometimes it’s a form of social stenography — a way of keeping “outsiders” from understanding. And sometimes it’s just a way of saying, “I really don’t know what I’m talking about, but you should listen, because I know all the right buzzwords.” As we always used to say —
The modular capabilities support of this system is driven by the dynamic parameters array and functional systems implementation of the integrated performance environment.
Yes, I’ve been around enough to actually own an original Gerry Cohen Dial-A-Buzzword. There’s a digital version here, if you’re so inclined — I used to have a computer specific one up in javascript, but I’ve not updated it in a long time, so I finally took it down.
What is the point of my little rant about buzzword bingo and technical gobbledygook? Is it that we need to stop using buzzwords? That we’ve all been silently assimilated into marketing without realizing it? That we all sound like idiots when we talk? None of the above. Rather, my point is simply this:
If your audience doesn’t understand you, it’s your fault.
Whether we’re writing or speaking, presenting or whiteboarding, it’s far too easy just to call someone clueless when they don’t understand. This is a bad habit we engineers need to break — we need to learn to communicate clearly, no matter what we’re communicating. Whether or not we use engtalk when we’re working with other engineers we’re certain will understand us, we need to learn to take responsibility for being understood.
Specific suggestions?
Slow down. I don’t know about you, but I talk too darn fast. Being born and raised in the southeastern United States doesn’t make it any better — “y’all” really fast is even harder to understand than “youse guys.”
Spell it out. If someone doesn’t know an abbreviation, don’t treat them like an idiot — spell it out. And if you don’t know some abbreviation, don’t be afraid to ask.
Abstract to the right level. Sometimes people just aren’t going to understand at the depth you know how to explain. Learn how to find multiple levels of abstraction, examples, analogs, and illustrations to help them understand.
Use images. Even if you just have words, use those words to paint a picture. Make your drawings clear and understandable. Don’t draw things you don’t need to explain the problem, solution, or technology. If it takes more than five routers to illustrate, then you need to rethink how you’re explaining it.
But finally, mostly, and most importantly — take responsibility for being understood. Trust me, you’ll be a better engineer if you do.
