Actively Seek Inaction

October 27, 2006

proud and unbroken
actively seek inaction
get to the point please

The diagnostic mindset can be a detriment. You can come off seeming rude, obnoxious, worse than a CIA interrogator with no leash.

“Did you install any software recently? Did you or did you not?”
“Have you changed any settings on your computer? Are you sure?”
“When did this start happening? Be precise.”
“Okay, but you said XYZ, which means it didn’t start until two days ago.”

You justifiably want to find out WTF happened. But users seeking help always provide a song and dance as preface to the statement of the problem. The preface is different every time, but you’ve probably noticed patterns. Some individuals need to vent before, during, and after statement of a problem. Others feel the need to explain the importance of the issue, as if they need to convince you it’s worth your time. Still others feel the need to prove that they’ve considered the problem in an intelligent manner before bringing it to your attention.

Actually, all of these are legitimate greetings in the office realm, and they reflect the given user’s relationship with the issue and with you. So here are some suggestions for getting people to get to the point.

Don’t be in a hurry. Sit tight and hear them out. If they are spinning their wheels, take it as an opportunity to ponder their relationship to the computer. You will demonstrate that you care about what they have to say, and give their momentum a chance to slow down.

Do not respond to accusatory language unless you plan to apologize for something. Occasionally users come off sounding like they’re blaming you, because in some sort of logic akin to the doctrine of original sin, you are guilty of everything technology throws their way, even self-inflicted disasters. Rise above this tone and move past it. It’s not your problem.

Do not respond immediately to incorrect statements. Ultimately, if the user does not understand how email really works, does it matter? Are you such a great teacher that you can convey the necessary concepts in a few minutes? If you must correct a user’s statement, do so after fixing the problem. Your correction will have more authority at that point.

Answer only questions that need to be answered. Some users can produce more ‘why’ questions than a four year old. Some can be answered with a smile, a shrug, or a roll of the eyes, or nothing.

Do not answer stupid questions with intelligent answers. If the question is stupid, it’s ill-informed. If you are cornered and must answer, then inform the user so that they can frame a better question.

Refuse to multitask. If someone speaks to you, or you speak to them, face them with full attention. I find that if I continue to work on a computer while having a conversation with the user, they tend to slip into a stream of consciousness that is mostly irrelevant to the problem at hand.

Learn to politely interrupt.
This requires experience, empathy, and timing. The general principle is to let them spin their wheels until a natural pause comes, then somehow acknowledge the general trajectory of their spiel as valid and indicate that you understand where they’re going. Then, in the same breath, provide a new direction for the conversation.

Do not make it a secret that you would prefer to do nothing. The Tao says to do only what needs be done. Laziness is a programmer’s virtue. Just don’t come right out and say you are a lazy Taoist. Perhaps you can teach the user to fix the problem. Perhaps it’s operator error? Perhaps it’s not plugged in?

Do not blame the user, even implicitly. This will start a whole new stream of self-justification. Instruct, if you must, but not much.

Get to the point.
I’ve never met a user who wanted an extended explanation. Ever.


Shiny Competence

October 18, 2006

always make progress
never admitting defeat
shiny competence

This one has always irritated me because a) it’s fake and condescending to put up a facade that plays to people’s weaknesses in perception, and b) it works every freakin’ time.

Why should it work? Why am I not allowed to utter the following while helping someone with a technical issue?

  • I don’t know.
  • I have no idea.
  • I’ll try.
  • I’m not sure.
  • Let me think about it.

If you say any of these things, the person who has asked for your help will doubt your competence. You can often visibly see them cringe. They think, “Damn, I should have asked someone who knows what they’re doing.” It doesn’t matter who they are, how smart they are, etc. The moment you pause to visibly think, they think the worst.

So what do you do? You provide filler and busy work. You give immediate answers and start seemingly prudent diagnostic actions. You immediately set to work. You admit no uncertainty.

The funny thing is, you can choose not to answer questions that have answers like “I don’t know” and fill in answers to implied questions. For example, “What do you think is wrong with my computer?”

Real Answer: “I have no idea, but I can find out if you let me try a few things.”
Competent Answer: “Let’s see, do mind if I drive?”

The real answer gets a Pavlovian negative response. The competent answer does not. There is no real difference between the two answers except in tone. Yet because in the second one you do not come out and use words like “don’t know” and “try”, you’re okay.
I know this sounds bizarre, but it’s ironclad. I think it also explains how the current administration has gotten so much political traction with their arrogance, but that’s another topic.


Plug the Damn Thing In

October 9, 2006

infinite paths cross
mystery system failure
plug the damn thing in
plugitin

Example 1

A friend was having mystery trouble with a php script the other day after performing an upgrade to another application that interacted with it. He had already done quite a bit of troubleshooting before asking me if I had any ideas. Although I did have a few suggestions he hadn’t tried, none of them revealed the culprit. We were starting to get frustrated. I took a deep breath.

“It’s probably something stupid,” I said. “Go back through all the most basic things you can think of, even if you think they couldn’t have changed.”

Sure enough, it was directory permissions. The new php script wasn’t set to 755.

Example 2

User asks me to make sure her new office is ready in terms of internet connectivity. I’m very careful, have made sure the jack is active, that her current machine will pick up an address when on that subnet, etc. A week or so goes by. She hasn’t moved in yet because they haven’t transferred the phone. She calls me and tells me her email stopped working a few hours ago.

Well, you know the drill, “email” means all network connectivity. The user just hasn’t realized it. I try some basic network stuff, and the machine can’t even ping the gateway. But the ethernet cable is plugged in. There are two jacks, and it’s in the right-hand jack, which I consider for a moment as odd, because I use the left-hand jack on my subnet (we have more jacks than switch ports). But this isn’t my subnet, and this user wouldn’t have touched the cable, right? I ask her. “Oh no, I didn’t touch the cables,” she says.

So from there I assume something has gone wrong with the network settings on the computer. Fifteen minutes later I’m pretty sure the jack is dead. You probably figured out where this was going already.

“Did they transfer your phone today?” I ask.

“Oh yes, thank god. I was wondering when they would get around to it. I’m moving into the new office tomorrow.”

I get down on my knees and put the cable in the left-hand jack. I pull up a browser, which works fine.

“You’re good to go now.” I say.

She stares at me and then the lights come on. “Oh dammit. Did the phone guy do something? Is my phone an internet phone?”

“No, you don’t have an IP phone. He mistakenly unplugged the ethernet cable and then put it back in the wrong jack,” I tell her, but in a friendly way. To users, what we do, or what “phone guys” do is voodoo. That our actions might somehow overlap in the world of jacks and cables never occurs to them.

Anyway, here’s hoping that the next time you’re in a “plug the damn thing in” scenario, you realize it sooner rather than later.


Explanations

September 30, 2006

you mispelled haiku
no I meant to write hacku
just think about it


I talk slowly when I have something to say. It’s just the way I am. I’m thinking through what I want to communicate, whom I’m talking to, how best to phrase things, etc. Maybe I had too many patient interlocutors as a child. Users are not patient interlocutors.

So I’ve had a steep learning curve. I’ve tried explaining things in terms non-techies should understand, with lots of mundane analogies and gestural metaphors. Most people find analogies to be either obtuse or condescending, so that has succeeded abysmally. I’ve tried using exactly the terms I use in my head. Most people don’t think like I do. So they follow what I’m saying for maybe two words.

What to do? If you need a boilerplate, here’s what I recommend: Executive summaries for everyone. Everything you say by way of explanation should be a summary. If the user tries to go for details, give them just enough to answer their question. And when you’re done, walk away. Ultimately you compliment their intelligence and save everyone some time.

This approach automatically scales to anyone you speak with, techies or non. If they ask informed questions, then your “minimal” answers, if they are correct, will come across as well-spoken.