Wait! Before we get started, let's do something to make sure we actually finish.
I realize that as a system administrator (SA), you are flooded with constant interruptions. The phone rings, a customer![*] stops by with questions, your email reader beeps with the arrival of a new message, and someone on Instant Messenger (IM) is trying to raise your attention. Heck, I bet someone's interrupted you while reading this paragraph.
I'm not going to cover how to deal with interruptions until the next chapter, and I hope you don't take offense, but at this rate, I'm worried you won't get that far. To mitigate this problem I'm going to share a tip from Chapter 2, which, if you implement, will shield you from interruptions between now and when we can deal with the subject of interruptions properly.
Suppose you are in an environment with two SAs. You and your coworker can agree to establish a mutual interruption shield . Before lunch, you field all the interruptions so that your coworker can work on projects. After lunch, your coworker fields all the interruptions and lets you work on projects. Obviously, if there is an emergency or an urgent request that only you can handle, you'll drop what you're doing. However, you'll find that by organizing your days like this, you'll see an immediate improvement in the amount of project work you get done. You may also find some time to read this book.
This method works particularly well when there are a lot of SAs. I was once part of a very large admin team, and we were able to assign time slots of "interruption catching" that let the entire rest of the team focus on project work for all but one hour a day.
This method can be adapted to a solo SA, too. If you are a solo SA, talk with your manager about how you could improvise some kind of equivalent system. For example, management can make the users aware that afternoons are reserved for "project time ," and non-urgent requests should be emailed to you (or to your request-tracking system) for processing the next morning. This might match the natural flow of an office. For example, if most interruptions happen in the morning, it will be easier to schedule the afternoon as "project time." It may be more appropriate to do that only when a special, visible project is coming due. For example, your boss assigns you a project that will benefit many aspects of the company. This is an opportunity to ask for special dispensation so that the project can get done quickly.
There are also physical things you can do to protect your "project time." Obviously, if you have an office, you can close your door to prevent casual drop-ins and social visits. A more effective technique is to make sure that customers must walk past your Tier 1 (customer-facing) system administrators in order to get to Tier 2 people (you). If you are the senior SA, re-arrange your seating so that people must pass by a junior SA on their way to you. The role of a junior SA is to handle 80 percent of the interruptions and let the 20 percent that only you can do, get to you. Physical location is key to this. Walk 50 feet from your desk, turn around, and walk back to where you sit while imagining you are a typical customer. What do you see? Make sure it is the person who is supposed to be customer-facing and working on all the Tier 1 support requests.
Go away and arrange your mutual interruption shield right now. I'll wait.
Hey, what part of "right now" didn't you understand? You didn't make that arrangement, did you? Please do it now before you continue. I really want you to be able to read this book.
Ah, now we can really begin!
Time management is difficult for SAs because we are constantly being interrupted. How can we get anything done if we are constantly pausing to fix emergencies or respond to requests that arrive in person, via email, or via the newest source of interruptions, instant messages (IMs)? How many times have you told your boss that a project would take two uninterrupted days to complete, which means a month of actual time? Returning to a task takes a long time. If an interruption takes one minute, and it takes two minutes to return to your project, you're actually traveling backward in time! H. G. Wells would be impressed! Worst of all, returning to your project after an interruption can lead to errors. Often, when I'm debugging a problem, I find the actual "error" was that I skipped a step after returning from an interruption!
Management judges an SA by whether projects get done. Customers, however, judge you by whether you are available to them. These two priorities play against each other, and you're stuck in the middle. If you are infinitely available to customers, you will never have time to complete the projects that management wants to see completed. Yet, who approves your pay raises?
Why a book on time management just for SAs? This book needs to be different from your average "time management" book because SAs are different. In particular:
Our problems are different. SAs have an unusually high number of interruptions that prevent us from getting our projects done.
Our solutions are different. SAs can handle more high-tech solutions such as request trackers, email filtering with procmail, automation scripts, and other tools unsuitable for the average, non-technical person.
We lack quality mentoring. SAs need to learn the fundamentals of to do list management, calendar management, and life-goal management just like anyone else. However, our normal career path usually doesn't lend itself to learn these things. Our mentors are technical peers, often on email lists, and often in different parts of the world. There are fewer opportunities to learn by watching, as a supervisor often learns from a director.
[*] In this book, I will use the term "customer" to denote any internal or external user of your computers, network, applications, and so on. I prefer "customer" over "user" because it better represents the relationship SAs should have with the people they serve.