This is where the Egoless Admin comes in. The advice below, tempered with a little hard-headed common sense, will get you through most situations.
The Egoless Admin has five simple rules:
Let's look at each of these rules individually, then see how they work together.
You were hired to perform a service. Period. Among all the other responsibilities that get heaped upon SAs is authority to maintain and manage the systems for the benefit of the users. You might be there because the users will not or (much more likely) cannot do it for themselves. You may be there simply because it's cheaper to have you do it than to let them do it. Don't think for a minute that everyone likes this. Very few people have the strength of self to admit that they don't know something important, and your systems are very important.
If you keep in mind that you are first and foremost a service provider, it will keep you humble and it will put you in the right mindset to deal with the users. Sit there demanding fealty and posturing like a tin god, and you will have nothing but problems.
By the time users approach you, they've exhausted their other options or simply don't know what options they have. They might try to cover for it by throwing around jargon, or they might fall back to telling you to fix it (whatever "it" might be). They will probably be in a huff or actively hostile. They don't want to be there and, frankly, at that moment, neither do you.
Now is the time for you to "Shut up and listen".
Don't allow yourself an emotional reaction. Actively listen to what they have to say. If they are simply teeing off, you'll know within a few seconds and you can move to the next rule, but they may be describing a real problem. You won't know if you don't make the effort to find out, and that means active listening.
Active listening involves focusing on the speakers and waiting for them to make their point, not rushing ahead or emitting affirmative grunts until you get to the good part. If you have not turned to face them, are not making eye contact, have crossed your arms, or have allowed yourself to continue doing what you were doing before they arrived, you are not listening. Stop, take a deep breath, exhale, relax, turn to them, and ask them to tell you what is going on. Don't cut them off. Don't correct them until they've finished. When they have finished, paraphrase their statements aloud to show that you really heard what they said.
This technique works well with your significant other, too. Pay attention.
Often, just asking "What can I do to help?" is enough to defuse the situation. If they reply with some incoherent sputtering about feelings and blame and ownership and stress and what-have-you, calmly ask them again "Okay. You're upset. What can I do to help?" Don't try to minister to whatever psychic wounds they carry around. Just find out what they're doing at your desk and what they want.
If they can't get themselves together to describe what they want clearly, don't pursue it; just skip down to the last rule.
A footnote that should be noticed here is that there are phrases that raise people's hackles and which should not be used unless you've been itching for a good fight. For example:
What these all have in common (and there are many, many variations on these themes) is that they turn the discussion into an argument by ignoring or demeaning the person asking the request. They thought it was important enough to come to you, so you should at least try not to insult them before they go away.
Sounds simple, right? It should be.
You are providing a service (remember?) and you have a clear idea about what needs to be done. As in the sneaker ads, just do it. Don't whine about time or other projects or anything else. The longer you hassle over accepting the task, the longer the person standing at your desk will pester you. It's easier to agree to do it, qualifying that it will be done "soon" or "when time permits". Be doubly generous with the time estimates, and always be prepared.
In any case, you must always honor your commitment. If you said you would do something, then do it. If something else intervenes, do it as soon as you can. People understand that some priorities outweigh their needs, but if you always run late and fall back to excuses, nothing in this article will save you.
One of the best ways to keep out of the way is to proactively do things like monitor systems and perform upgrades. Well-managed systems will have problems now and then -- it's unavoidable -- but poorly managed systems pummel you with problems every day. It's better to put the equipment or software aside than to scurry around at the last minute. (One such technique is to never allocate all the space available. Don't even tell your manager exactly how much is left; always underestimate.) However, if you know that the budget faucet isn't going to open until there is a problem, get ready for the problem. Contact the vendors months ahead of time, circulate an informal RFP, let your manager know what's coming, and have a recent list of prices and an estimate of the time and cost so that when the fire starts, you can be the first on hand to put it out.
Never accept responsibility for someone else's problem. What? That sounds more like a tip from The BOFH (Bastard Operator From Hell) than one of these touchy-feely Egoless Admin techniques, but it's true. Unless you're seriously screwing up, the problem that brought the user to your desk isn't likely to affect you one way or the other. It's not your problem, but the person standing there is, so be sure to share it with her.
Make her perform some legitimate minor exertion or place a necessary but trivial precondition on getting what she wants. I like having users send requests via email; that way, it's logged. If the request involves or affects other users or has potential consequences beyond that user (such as system patches or installation of new software), make them CC their manager (and yours, if appropriate). If it requires a budget item, have them find it and get back to you. For really trivial things -- the ones I take care of while they wait -- I have them email me when they get back to their desks. The reasoning is simple: if you happily make small but minor changes (reset password, manage a group, kill a process) on demand but have them send the request afterward and defer important changes until you have a chance to review or get approval, you look like a nice guy who bends the rules instead of a tyrant or bean counter.
The real advantage of this, when properly done, is that it requires that they go away and establishes a document trail. Nothing causes a hot-tempered developer with a bad attitude to quietly go on her way than to know that the higher-ups will review every ridiculous request the minute it's sent.
I've provided two examples of these techniques below and numbered where each was used. The numbers don't necessarily follow in sequence, and you should show similar flexibility.
It's really a DBA problem, but since you're responsible for the server, it's your problem too. Everyone from the junior DBA to the executives knows about this one, and they're calling meetings. When the big meeting starts, you let them shout (1). They shout at you a little, but you keep your cool and follow the discussion (2). You let the discussion flow unimpeded, answering questions openly and correcting misstatements, until it gets to the technical matters for which you have responsibility (2). You notified management six months ago that this was likely to occur but decide to sit on that fact since it's only going to aggravate the DBAs and start a new round of arguing over blame (3). But you knew that this was coming and you already have a RAID expansion unit on hand from the last round of budget games, and just need the vendor to come in and integrate it (4). You defer a time estimate until you contact the vendor, but say it should be no more than a few days (4). Before the end of the meeting, you ask that the DBAs email a formal request for the expansion and that someone send you the budget information so you can get going on it (5).
Two groups on parallel development tracks are vying for control of the admittedly limited resources of a single development server, and have taken to ignoring each other's existence. Since they share the same environment and their products must coexist in production, you privately tell the leader of each group that they need to work it out themselves (4). Within days, one team consumes the disk space allocated for development and the other trashes the configuration of the Web and App server. Self-appointed envoys from each team descend on your desk to argue with each other, and expect you to arbitrate. You tell them that they must work it out themselves (1) and that you will handle any technical matters that crop up (3). The fight continues at your desk and escalates as developers -- some of whom don't leave their cubes for weeks at a time but decide to do so today -- join the fracas. You try to restore order by telling the group that each of them will have one minute to say what's on her mind and that no one will interrupt (2). Ten minutes later, everyone has said something, most of it about accusing someone else (1). You ask each one, one at a time, what should be done, but halfway through, the arguing resumes as each group tries to impress upon you the immediacy and importance of its project (2). You declare that since no one has said anything useful and they are wasting your time, they all lose their access (3) and that you will be sending email of this discussion to all of them, their respective managers, the project manager, your boss, and the executives (4). Not wanting to call your bluff, they agree to hold a meeting that afternoon to work it out. You ask them to leave you out of the meeting and to CC you the decision (5).