Of course, the fastest way to deal with an interruption is to scream, "Get out of my face!" at the requester and slam the door. However, I can't recommend this technique unless you want to get fired. I have met SAs who recommend being gruff, "scary," or even a "bastard operator from hell" to deter customer requests. I think SAs can do better than to follow this advice.
Directing Interruptions Away from You
Let's begin by trying to eliminate the single most annoying interruption that exists: someone interrupting you when he should be going to someone else. Is this the right way to handle such interruptions?
"Tom, there's a problem with the web server."
"Great! I look forward to your results when you talk to the people responsible for the web servers."
No, that would be rude. The great thing about being a system administrator is that everyone assumes that you are all knowing and all powerful. Sadly, most of us are only all powerful within a certain scope of responsibility. While it may be annoying to be asked about systems outside your scope, you really can't get angry at someone for trying. Have you ever intentionally asked the wrong person a question? Not likely. So when you get annoyed at someone for making a request that "is obviously not my job," put yourself in that person's shoes. He didn't know a better place to go. Chances are, it's a compliment: you're the smartest person he could think of to ask for help (or the smart people were at lunch). Most organizations don't make it really obvious who is the most appropriate person to go to for help with particular problems.
Until you make it clear who to turn to for help, you can't really get upset that people don't go to the right person. I use several methods to communicate to people the right way to seek help: web pages, signs, email signatures, and so on. When I was at Bell Labs, we had posters all over the walls leading to the SA area that read, "Stop! Have you sent email to 'help'?" At another organization, the first thing I did was to install an internal web site that gave users a list of specialty areas and directed them to the right person given a particular situation. Web browsers were configured to open this page on startup, and soon everyone became familiar with the information on the page.
"Hey, Is There Something Wrong?"
Customers often bother me just to ask, "Hey, do you know that something is wrong?" Having a monitoring system like Nagios that lets them check for themselves can reduce these interruptions. However, if your system is very stable, there are going to be few chances for them to develop the habit of checking the status web page first. The least you can do is to make it a link on your intranet home page.
When someone notices an outage that Nagios hasn't been configured to test, I make a big deal out of thanking him, even going so far as to send a follow-up email pointing out that that situation is now being tested for in Nagios and that we appreciate him making us aware of the issue because it has enabled us to improve our monitoring system.
How do you advertise the right way to get help? Stop for a moment and look around your office. Walk 50 feet from your desk. Now turn and walk back toward your desk while pretending to be a typical user and see what she sees. Does the path naturally lead her to interrupt you or someone else? What can be done to guide the customer to an appropriate person who isn't you? If you have a formal, tiered support system, are customers directed to the right people? How can they be directed better? Maybe a big sign or whiteboard that explains people's responsibilities would prevent a big heap of interruptions. It would be fun to make overhead signs like at an airport, but instead of signs for Concourse A, Baggage Claim, and Ground Transportation, you would hang signs that tell people where to go for help with Email, Internet Outages, and Printers.
Can customers be trained to go to the right place for help? Maybe. The first step is to make sure they're being properly told what to do, then to make sure they get significantly better service when they follow the directions. Punishing someone for not following directions rarely works. Ask any animal trainer and they'll agree: positive reinforcement works better than punishment (in the long term). People not following directions is usually a warning sign that the directions aren't clear to them, aren't visible enough, or that the directions don't work.
Alas, people will still come to you when you are trying to focus, which leads us to the next section.
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!)