Asking Why

By Kate Sheehan |

Anyone who has spent time with small children knows that "why?" is one of the best and most vexing questions people can ask. "Why?" probes for motivations, explanations, understanding. It demands reflection and clear communication, and I think it's safe to say that most people have a complex relationship with this tiny word.

Library techies can leverage "why?" to change how their organizations operate by questioning a ibrary procedure. Discussing workflow with coworkers and asking "why?" a lot, while offering ways to automate procedures, can offer value to your colleagues and your organization (and maybe wreak a little havoc). But "why?" is also a question library techs sometimes dread. "Why did it work before but not this time?" "Why is it broken?" "Why am I getting this error message?" Often the answer is straightforward: a setting has been changed, or a network problem is creating the error. But sometimes, getting to why would require an electrical engineering background and a path of inquiry beyond simply fixing the problem. Nothing is quite so frustrating as resolving a persistent error only to have your techjoy smashed to bits by a coworker disappointed because you're not quite sure why the computer stopped recognizing the printer, you only know that they're now friends again.

Before you all send me angry email: yes, most of the time, knowing why something isn't working is the key to fixing it. Computer not connecting to the Internet? Well, that frayed Ethernet cable might be the culprit. This is the third time in a year that's happened? Well, maybe we should move the cable out of the path of the vacuum. Why did your computer's Ethernet port stop working? No idea. It's dead, I installed a network card, now you're online again. If it dies again, that's a different story. A lot of troubleshooting is looking for patterns, waiting until cause and effect can be established reliably. A one-time problem doesn't always merit a full-out investigation into what runtime error number 37 means. Most IT folk seem to have a stock phrase or two: "Let's assume that it's just a hiccup, but call me if it happens again."

We can be, however, a teeny bit hypocritical about this. We get annoyed with the "why" we can't answer, but grouse that our less technical colleagues don't understand why their actions can cause problems or why their ILS doesn't work when the internet is down, or why email that's already downloaded to their computer won't show up in webmail. We want them to take our fixes on faith and also posses a clear understanding of how their network is set up.

The people who ask "why" could be the most likely to end up understanding the library's technology and the most willing to be advocates when everyone's wondering why you haven't yet fixed a big problem.

I am loathe to use a car metaphor, but it is apt. My favorite mechanics have been those who happily explain what was wrong with my car despite my rudimentary understanding of the problem. My most favorite mechanic once handed me the broken down part that was making that noise and showed me the healthy replacement (my car was up on the lift). Honestly, they looked the same to me, but I so appreciated the time he took to show me what he had done. He wasn't trying to prove anything to me, only explaining. He also clearly loved what he did and was excited both to have tracked down the problem and saved me from a horrible car accident. (It was a "you're lucky you didn't go on the highway last week" repair.) Other times when he told me he didn't know the cause of a  problem, I didn't mind because he had explained when he did know.

Most of us have had a mechanic or a doctor or someone with greater technical knowledge make us feel small and stupid and dense for even asking for an explanation. The people we return to are those who draw a quick sketch or use an analogy or simply take the time to tell us what's going on.