Thomas Limoncelli - Time Management for System Administrators

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."

Warning

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 control—which 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.

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.

Summary

Focus is important. You gain focus by removing distractions and dealing efficiently with interruptions.

Interruptions are, essentially, someone else controlling your time. Interruptions are the natural enemy of focus, and, therefore, time management.

Interruptions are bad because they delay your current work but also because returning to the prior task can lead to errors. Fixing those errors can take more time than the original task.

Removing distractions helps you to keep focus: clean your desk and your computer desktop, and remove distractions from your office. Disable IM, new email notifiers, and so on.

Everyone has a different peak time for mental and physical activity. Discover yours, and then schedule appropriate tasks for those times.

The first hour of the day can be your most productive, since it has the fewest interruptions. Getting to work slightly earlier than coworkers increases this productive time. Don't waste that time with maintenance tasks; use it for important projects.

Some General Advice

Sadly, this book can't give much advice about how to do the task. I don't even know what operating system you are using. I can, however, give you these general recommendations:

Measure twice, cut once. Be extra sure before you make a change you can't undo.

Make a backup before you change a file. Having a backup of a file can get you out of trouble. However, this only works if you make the backup first!

If all else fails, read the manual. When you can't figure out the solution, try the resources that you often forget to access.

When debugging, change one thing at a time. By changing one thing at a time, you see which change actually affected the system. This avoids confusion as the debugging process proceeds.

Always test your work. Some people never seem to make mistakes. I find that they are the people who do a lot of testing—we just don't see it.

You aren't done until your customer tests it, too. You may think you've tested things sufficiently, but until the customer has done his own tests, you really don't know whether you've fixed his problem.

The strangest problems often turn out to be misconfigured DNS. DNS is critical to so many subsystems, often in obscure ways, that a problem with DNS can mask itself as other problems. This goes for a client that can't reach its DNS servers, as well as a host with invalid DNS data describing it, or a client trying to reach a host with invalid DNS data.

The delegate, record, or do process permits you to take back control of your time. Use this when your project work is interrupted. Delegating the task means handing it off to someone else. Recording the task lets you acknowledge the request, but schedule it for later. Doing the task is your last resort, but it should be used for emergencies and outages.

When you record it, you gain the ability to plan and schedule rather than being interrupt driven. This is something we discuss further in Chapter 8.