Section 2.5. You Can Say

2.5. You Can Say "Go Away" Without Being a Jerk

When someone interrupts us, how do we tell him to go away without sounding like a jerk? The key is to acknowledge their request respectfully.

As discussed in the previous chapter, there are times when our job is to be the interrupt catcher, the person fielding interruptions so that other SAs can focus on projects. However, there are times when we are in designated "project time" and need to stay focused. What do we do when interrupted during those times?

First, it's important to understand what customers expect of us. Fundamentally, customers will be satisfied if they feel they have been acknowledged. You don't have to fix their problem for them to be acknowledged. They just need to feel that they've been heard and get confirmation that their request will be completed.

When someone stops by my office and asks me to do something that I'm going to put off until later, I make sure he feels acknowledged both verbally and visually. First, I say, "I understand your issue. Let me write it down so I don't forget it." Then I write down his request as he watches. I say what I write as I'm writing it. It usually sounds like, "[Person] needs [such and such] by [date]." Then I turn to him and ask, "Did I capture that right?" When he says "yes," it gives closure to the issue. Having achieved closure, he usually leaves on his own, if I don't ruin it by saying something to continue the conversation. I've found it best to say "Thank you," while giving a nod. Anything else just reopens the dialog. Closure makes it difficult for them to start to push for immediate action. If he does push for immediate action, then I know I have misunderstood the urgency of his request, and we can discuss the time requirements. But now, I'm driving the conversation, which means I'm in the position of power during negotiations.

Automated systems need to acknowledge people, too. When customers send email to a request-tracking system, they should receive an autoreply with the issue's ID number. If they submit an issue through a web-based system, they should immediately be able to view the issue status so they can be confident that it actually is in the database. People hate to feel they are submitting a request to a black hole. A personal response is wonderful but unrealistic. An automated response acknowledging the receipt of the request is sufficient. No response keeps customers in suspense and is unfair. Lack of response is one reason why I don't like to submit bug reports to certain vendors. It's very trendy to have software automatically submit a bug report when it crashes. Netscape has FullCircle, Microsoft has their feedback agent, and Apple Mac OS X has something similar. They all leave me dissatisfied because I never receive any kind of acknowledgment. I have no way of knowing that it's not just some kind of feel-good hoax set up to make customers think the vendor cares while they actually discard the submissions. I don't expect to receive a phone call from a product manager saying, "Hey, remember that crash you had last week? Thanks for submitting the report! We've fixed it and named you Customer of the Month!" However, it would be nice to receive email to acknowledge the submission. (I should note that when Tom Reingold was at Bell Labs, he not only called and congratulated the submitter of every 1,000th request, he took them to lunch and used it as an opportunity to ask them how they would like to see service improved. So there!)

Sure, all customers want their requests completed, but you can't always get what you want, and everyone knows it. However, if people don't feel acknowledged, they won't be happy. At worst they will feel ignored; at best they will assume you aren't doing something when you are.

Don't customers want everything right now? No. I believe that customers know, deep down, that they can't always get that. If they ask you to order a new PC, they expect the request to be acknowledged, but they know that even with overnight shipping, they're not going to be able to stand in your office waiting for it to arrive. They will be satisfied with an acknowledgment and a date on which they can expect the order to arrive.

Customers Want to See Action More Than They Want to Receive Action

Once I was in my office and a customer rushed in.

"Server XYZ is down!" he said, in a panic.

"I'm on it!" I replied.

I turned to my workstation, typing occasionally. From what the customer could see, it seemed like I had simply returned to my work and was completely ignoring his panicked request.

This was in the early days of remote serial console or long-haul KVM switches. I was actually hard at work fixing the problem, but visually the customer wasn't seeing me do anything different than when he arrived.

He became upset. The customer's expectation for "fixing a down server" involved me jumping up, running down the hall, fiddling with the funny combination lock on the machine room, then laying hands on the server. Because I wasn't meeting his expectations, he expressed his dissatisfaction in rather colorful language. He thought I was just going to sit there and do nothing to see if the server came up on its own. I was able to clear up the confusion by showing him what was on my screen.

When this happens now, I assume that the customer does not know about console servers and long-haul KVM switches. First, I verify that the server is down while I announce what test I'm doing. "Let's try pinging it!" I announce. "I can't reach it." But then instead of dashing off to the data center, I say something like, "Hey, have you seen this? I can access the console remotely as if I'm in the computer room!" I turn the monitor so the customer can see what I'm doing, show off the technology a little, and then go to work fixing the problem.

Soon they get bored and go away, satisfied that I'm working on the problem.

My little demo slows me down a bit, but it is still faster than actually walking to the computer room, and the customer is much more satisfied because she receives visual proof that I'm attending to his request.

"Bored but satisfied" is so much better than "panicked and impatiently waiting."

Conversely, customers will be the least satisfied if they feel ignored. This has nothing to do with whether they really are being ignored. If you start working on their request but they don't know you have, they will assume you haven't. That sucks, but it's true.

Hopefully I've convinced you that acknowledgment is important, and managing your time based on your priorities is important. So how do we combine the two? By using the process of delegate, record, or do.

That leads us to the next section.

2.5.1. Delegate, Record, or Do

When someone interrupts you with a request during your designated project time, you have a few options:

• Delegate it. If someone else can do it, delegate it to him.

• Record it. If only you can do the request, but it isn't urgent, record the request. Be sure to do so in a way that the customer trusts; don't just promise to remember it.

• Do it. If the request is truly urgent, such as a service outage, drop what you are working on and do the request.

I admit that I actually pause to think, "Delegate, record, or do." It helps me focus on what I'm going to do with this person who is, alas, breaking my focus. The following sections provide more detail about this process.

2.5.1.1. Delegate it

If you have set up a mutual interruption shield as discussed in the opening of Chapter 1, you can refer the person to your shield partner. You don't have to say, "I'm sorry, but this is my project time, so I'm going to shove you on someone else." You can say it very politely.

Since people need a visual, positive confirmation that they've been heard and taken seriously, I think the best technique is to pick up the phone and call your shield partner to delegate the request while the customer watches. People don't want to have to re-explain themselves to each person they get delegated to, so I always try to explain the issue to the delegate. I can often explain it in technical terms, which is more efficient than the customer's original request.

Here's the general form: I say out loud, "Ah, let me ask Mary to do this" (I pick up the phone and dial Mary). "Hi, Mary. Joe is here. He needs X and Y. I'm sending him over to you." I look at the customer and say, "Stop by Mary's office, and she'll help you." Now Joe has received excellent acknowledgement of his request, and Mary is prepared to handle the task.

As technically inclined people, we often forget what it's like to be a nontechnical customer making a request. It may have been difficult, and possibly scary, to figure out how to phrase the request, so taking the time to explain it to Mary in your language makes it easier for Joe.

Sometimes the request is rather complicated, and I don't want to risk the miscommunication I can introduce by repeating a request incorrectly. However, I can still help focus the issue. For example, "Hi, Mary. Joe is here. He has a rather complicated request related to the web server. I'm going to send him over to you right now."

Of course, there are times when you are in a hurry and just can't call Mary. I think it is obnoxious to answer a request with a question like, "Did you talk with Mary?" A better way to express this is to simply say, "Mary is on call right now. Could you speak to her about this?" It sounds more official and orderly. People find a certain comfort to following an official process.

If your coworker says she doesn't know how to do the task you are trying to delegate to her, you have a few different options. You can use this as an opportunity to teach her how to do the task. That way, she'll know how to do it in the future. Otherwise, you might ask the customer if the task can waitif it can, record it.

2.5.1.2. Record it

If the task can wait, you can record it for later action. Record it in a place where it won't get lost. Make sure the customer sees you record the request so that he has visible confirmation that he isn't being ignored.

If you use The Cycle System, as described in Chapter 5, enter the request into your to do list. This is appropriate for smaller tasks that will be done soon.

For larger tasks, my favorite place to record a request is in a request-tracker application. I've found that the open source tool RT by Best Practical (http://www.BestPractical.com) is better than a lot of the commercial systems around. (O'Reilly recently published a book called RT Essentials that covers all the details of configuring, administrating, and using RT.) Emailing to RT automatically starts a new issue to track. If you haven't set up RT yet, a poor man's alternative is to email yourself the request. While you're at it, email yourself a reminder to install RT.

To make sure that the customer sees me taking action, I say out loud, "Let me record this in my to do list so I don't forget," or "Let me create an RT entry." Then as you type the message, speak what you are typing. "Jill needs a new printer installed. It is in the box just inside her office. She needs it by this Thursday at 9 a.m."

Always record a time in your deadline. A Thursday deadlinecan lead to trouble when a customer assumes you meant Thursday morning, but you actually meant Thursday close of business.

I then turn to the customer, who has heard what I've typed, and say, "Anything else I should capture?" This helps eliminate miscommunication. It also gives them the satisfaction of thinking that they're in controlwhich they are, sort of.

After clicking submit, send, or whatever the software requires, say something reassuring like, "I got it!" and return to the work you were doing before you were interrupted. Recording the request in RT, a PDA, or a to do list system shows professionalism that is reassuring to your customer. Writing on little scraps of paper or 3M Post-it Notes has the opposite effect.

Never try to remember the item in your brain only. I've already discussed keeping the front part of your brain free for more important things. Don't try to remember the customer's request. You're a smart person (and good-looking, too), but don't trust your brain to do something that paper can do better. Record it, then let it go. Free your brain. Which leads us to....

The Hallway Ambush

When someone stops me in the hallway and asks me to do something, I record it in my to do list. However, if I am without my organizer, I would rather refuse to acknowledge the request than trust my brain to remember it. I'm honest but blunt. I say something like, "OK, so I agree that's the best course of action. However, I'm in the middle of something, and I don't have my PDA with me. I don't want to risk forgetting this. Could you do me a favor and email me the words 'install web monkey' and that will jog my memory." By giving the person the exact words to use, the task becomes less of a burden on her. However, this tactic also unburdens your brain from having to remember the exact request.

If this situation happens while I'm near a computer that can send email, I'll ask the person at the computer to email me the reminder, even if they weren't part of the conversation!

Oh, and that reminds me. How dare you go somewhere without your PDA/PAA! Always keep it with you.

2.5.1.3. Do it

The third option is to do the request immediately. Your focus will be lost, but at least you made two good attempts to first deflect the task. If a request should take less than two minutes, it can be less work to do it than to record it and pick it up later.

Of course, if the issue is an emergency or a major outage, there's no other good choice. Heck, the major outage might also affect you, so it's worth doing right away.

I highly recommend that your organization create its own definition of major outage. This can give newer SAs direction and guidance, and if it's stated on your policy web site, it can set expectations with your customers. For example, a LAN group I worked with once defined a major outage to be any outage affecting more than 10 people. Other businesses define a major outage based on whether a deadline is in jeopardy or a Service Level Agreement (SLA) will be missed.

Before you do the customer's request, take a moment to record where you left off, or at least save your work. That makes it easier to return to the task. It also helps you focus on the new task because your brain isn't cluttered with trying to remember where you left off.