This post is sponsored by the new Canon imageCLASS MF800 Series color printers, designed to help you get through IT. With features like a remote user interface (for control) and a 3.5″ color LCD touch screen (for efficiency), imageCLASS printers give your office the type of reliable output and efficiency you demand from your printer — giving SYSADMINS more time to focus on the IT help requests that really matter! For more information visit www.usa.canon.com/getthroughit
As anyone who works with technology knows, levels of expertise vary between people and their understanding of the technology that they use. This holds true across every layer of society, and across every age group. Some people just know more about how things work than others.
This knowledge isn’t intrinsic. We learn as we go along. We watch videos online. We read books. We take classes. We give it the old college try and make mistakes. We ask questions, and sometimes they seem like really stupid questions in hindsight once we understand the nature of a problem and its eventual solution.
If you’re an IT professional, you know that this applies not only to the uninitiated layman, but even your peers — even (whether you care to admit it or not) yourself! You may be the go-to expert at your workplace whenever something that plugs in goes on the fritz, but if you’re lucky, you’re part of a team of experts.
— LockerGnome (@LockerGnome) April 3, 2015
Why? Well, because then you’ve got the advantage of whatever knowledge and experience your team members have that may not necessarily overlap with yours — and you provide the same advantage in return. Could The A-Team have built so many episode-ending juggernauts out of duct tape, wood scraps, and junkyard odds and ends if each member were working on their own? Nope. The A-Team was unstoppable because it worked as a team (that’s even part of the name!); each member pulled his own weight and made up for the shortcomings of the others with his own set of strengths.
It may seem silly for me to bring up a cheesy (but fun!) network television action show from the ’80s to make a point, but I’m hoping it’ll all make sense as we proceed. My ultimate goal is to try and help you know how to keep your users from asking stupid questions. Here are some of my suggestions:
Put yourself in their position.
Unless they’re of the curious and vexing variety of being known in common vernacular as the “troll,” nobody asks a stupid question on purpose. That is: they’re asking because they really want to know the answer or solve a problem; they’re probably not doing it to annoy you.
A communication gap is just one of the problems that arises when someone not versed in the terminology of the technology they’re trying to understand goes to seek help from someone who does. The most helpful information that someone might be able to give you when you’re trying to fix their system remotely may simply be “it doesn’t work.” With a little more prodding, you might be able to further ascertain that “thingie” doesn’t work like it did before “other thingie” was used. This may be beyond frustrating for you, the expert, as you’re just trying to solve the problem as efficiently as possible so that you can get on with your day.
But turn the situation around and look at it from the perspective of the person you’re trying to help. They probably know that they’re not being as descriptive as they could be, and that’s equally frustrating for them. Nobody likes feeling dumb, but it’s easy to feel exactly so when stuck in the vulnerable role of requiring assistance from someone else. Being on the other side of the equation — the one who knows “stuff” — can be empowering. But will you use that power for the good of your charge’s greater understanding, or the comparative evil of making them feel smaller for seeking your help in the first place?
It’s safe to assume there are scenarios that, if reversed, would put you in the position of being the one to ask stupid questions of the very same person. If you’d expect compassion and patience from them under such circumstances, then try and pay it forward with the same. Cultivating rapport by empathizing with someone’s plight goes a long way toward smoothing over the communication gap and turning a stupid question into a smart answer.
Don’t rely on tech that’s older than them.
My Dad knows a lot about classic cars and their inner workings. My grandfather knew a lot about the operation of ham radios. I imagine that my great-great-great grandfather knew a lot about how to mend a faulty steam engine or get water out of the ground on the wild frontier.
I don’t know a whole lot about any of these things, but I have my own set of skills that pertains to the technology and overall culture of my own era. For instance, being an unapologetic child of the ’80s, I might make a reference to something like, say… The A-Team to demonstrate the importance of recognizing that we all have strengths and weaknesses that we bring to the table. I suppose it wouldn’t be fair for me to apply this analogy when trying to explain something to someone who was born in the ’90s. Similarly, hilarious anecdotes about poorly translated Morse code messages that one of my not-so-immediate ancestors might share will probably poorly translate into being anything relatable to me and my experiences.
Build powerful systems with simplified processes.
Or, as Dad would say, “Keep it simple, stupid.” (KISS for short.) Even the most outrageously intricate machinery, at its core, is made up of simpler parts that work together for the greater good. (You know… like The A-Team!) Problems work in the same way: they may be very complex, but their causes can usually be broken down into smaller, more easily understood processes.
So when someone asks you what seems like a powerfully stupid question, try and understand that its foundation is probably rooted in something — or maybe even a series of somethings — that, when analyzed, actually makes a whole lot of sense.
Eliminate complexity whenever and wherever possible.
This is pretty much the heart of what I just said about building powerful systems with simplified processes — the KISS principle — but you’re an IT professional. You know the importance of redundancy as a safety net for when all else fails! When you’re trying to resolve what you may perceive as someone’s stupid question, overexplaining is only going to be perceived by that person as a stupid answer. The bottom line: they’ve got a problem, and you may very well have a solution. You both want the problem solved. What’s the shortest path from point A to point B?
In short, we’ve all been asked what we feel to be pretty stupid questions. But can any of us say that we’ve never been “guilty” of asking a stupid question of someone in the pursuit of greater understanding? The best way to keep your users from asking stupid questions is to realize that all questions, at their core, are reasonable enough. It’s the interpretation that can be a little tricky. When you’re the expert — the keeper of secret knowledge — part of your job is translating these arcane requests, first, into something that makes sense to you. Then, the rest should more easily fall into place. Good luck!