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:

There are six principles that I base all my techniques on. I don't claim that any of these are my own invention, but I certainly put my own spin on them. You will see these principles throughout the book:

Let's take a look at each one of these principles in greater detail.

I'm told that when teaching, it's better to tell people how difficult it's going to be early in the process so that they aren't so disappointed when they realize it isn't all milk and honey (or Jolt and chocolate). I'm told that it's a lot better than promising people "easy, fast results" and having them give up at the first challenge, possibly blaming themselves for not achieving the instant results promised.

Therefore, let me be perfectly clear: this may be the most difficult journey on which you've ever embarked. You've spent your entire life developing the bad time management habits you have right now; you can't fight that inertia over night. It's going to take long hours of practice. You are going to stumble through a lot of this, come back a month later, reread a chapter, and realize that you've been doing it wrong. At times it will seem like there is no hope, that these techniques are a waste of time and more difficult than just muddling though the old way.

I can assure you that you'll have all these feelings because I felt them all, too.

But now I'm writing this book. I must have survived. So will you.

Every time things look grim and difficult, just remember that change comes in small steps. Keep trying. Stick with the program. Squeeze those negative thoughts from your brain by saying to yourself, "Trust the process" and give it another try.

When you least expect it, someone will say to you, "You're so organized! I wish I knew how you do it all so well!" and you'll realize that you haven't had to refer back to this book in ages. Success!

Focus is about dedicating as much of your brain as possible to a particular task. The brain has many parts: the front part is dealing with whatever you are thinking about right now (the CPU and L1/L2 cache, if you will), the back part is where you store stuff (the RAM), and the far back part is where you store long-term knowledge (your hard drive). Focus deals with what I'll unscientifically call the front of your brain.

When you focus, you are trying to dedicate 100 percent of the front of your brain to your current task. To best understand this, let's look at an unfocused brain. Pretend you're trying to concentrate on a task, for example, writing a new Perl program to automate a procedure. However your mind is also cluttered with thoughts about the meeting you have in an hour, the three other tasks you have to do today, the milk you must buy on the way home, and you are still worrying about something your boss said to you this morning. All those things are taking up space in the front part of your brain, stealing capacity away from that Perl program you are writing! How good do you think that Perl program is going to be with all that other stuff filling up the front of your brain?

You wouldn't think that just trying to remember that you need to buy milk after work would take cycles away from your task at hand, but it does. Part of the brain is used to keep that memory alive. DRAM chips work the same way. They have to keep refreshing their memory or the information disappears. (Interestingly enough, SRAM doesn't require constant refreshing and is much more expensive.) Keeping a memory alive in the front of your brain is just as much "work" as doing any other physical task.

Clear all those "need to remember" things out of your brain by delegating responsibility for remembering to some other system. Set an alarm to ring before the meeting starts, write those three tasks on a to do list (see Chapter 5), write "milk" on your shopping list, and write down that you are going to visit your boss first thing in the morning to find out what he really meant (see Chapter 8). Now, you can rid your mind of those items and free up space for that task you're working on. Don't worry about forgetting those things; trust the systems you've delegated them to.

Lack of focus doesn't just come from external interruptions. We are also to blame—we turn on music, we have magically updating screen backgrounds, we have IRC chat rooms scrolling and instant message clients trying to catch our attention. Clutter distracts the eye, which distracts the brain. A messy desktop (both physical and on the computer) is full of distractions.

Spend a few minutes cleaning up your desk. Personally, I find it very difficult to clean my desk, so I've developed an office cleaning mantra:

I then follow this three-step plan:

Three months from now it will take extreme willpower to throw out the envelope without looking at the contents. The point is that I don't spend a lot of time thinking about each item and worrying that I might need it later. When deciding to throw out the envelope I repeat the following mantra:

I've also found it useful to take down posters, calendars, and other things that are in my direct line of vision. I still have many posters, they just aren't in my direct view. When I'm sitting at my desk facing my computer, I want blank walls, nothing distracting.

Finally, once you have a visually uncluttered work environment, do the same for your computer. Remove icons from your desktop; turn off all instant messenger clients, music players, stock tickers, and news tickers; and close your email program. I'm an email addict, and if I know I have new email, I read it. I could spend my whole day just waiting for the next email message. Instead, it's much better to open your email program every two to three hours, read everything, and close the program. I don't worry about missing urgent messages. If it is so urgent that the world will end, I'm sure someone will walk by my office and tell me (or perhaps I'll see a vision telling me what to do).

Interruptions are unavoidable. They are a natural part of the business flow. It is up to us to manage them well.

Being interrupt driven means doing tasks as they arrive as opposed to doing tasks based on some business-driven priority scheme. Sure, many times our business directive is to do interruptions as they arrive, but as you advance in your career, I assure you that this will be less and less so. Think about the organizational structure at a retail store. The clerk working the counter is interrupt driven: a customer comes to the counter, the clerk takes his order, makes change, answers questions, and so on. The clerk's boss, on the other hand, has a schedule of things that must be done: she opens the store, orders products, schedules staff, and so on. Yes, the manager stops for interruptions (questions from staff, emergencies, etc.), but that's a fraction of her job.

When we are interrupt driven, we're letting our interrupters manage our time. We're handing control of our workflow to someone else. Now, I'm all in favor of being customer focused, but only you know what your priorities are. If you control when you do tasks, you can intelligently group and prioritize them in ways that save time. For example, you can collect all the tasks in a particular part of the building and do them in a cluster. This reduces the amount of time spent walking up and down between floors. Chapter 8 shows how doing tasks in the order they are requested can be non-optimal and suggests a number of prioritization strategies that will save you time.

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.

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.

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!)

We can do the same thing in time management: develop routines whenever possible. Here are some examples.

Now that you've seen some example routines that work for me, how can you develop routines for yourself? Here are some things to look for:

Sometimes you have to update your routines.

In the "gas tank" story, earlier in this chapter, I pointed out that eventually I forgot why I had started such a routine but I continued doing it. That sounds a little dangerous. Without knowing why I was doing something, is it right to keep doing it?

I guess it comes down to faith in myself. Since I created the routine, I know I have already settled any ethical dilemmas. And I'm talking about changing backup tapes and filling gas tanks, not life-or-death decisions.

I find that routines delete themselves by becoming obsolete. When I got a promotion and someone else took responsibility for changing the backup tapes, the routine I had developed expired on its own.

Routines also modify themselves and evolve. This isn't a Perl script that, if left unmodified, will fail after the files it affects have been migrated to a new server. This is you. You're human. You see things as they happen and adjust.

Of course, I try to be flexible. When someone challenges my adherence to a particular routine, I keep an open mind and listen to his concerns. Sometimes he is even right.

The more routines we develop, the less brainpower we have to put into small matters, and the more brain power we have to focus on the fun and creative parts of being a system administrator. Throughout your day, look for opportunities to create your own routines. Red flags for such opportunities include:

System administrators in general are smart people. You're smart. I'm smart. We're all smart. We've achieved our stature through brainpower, not brawn. Sure, our good looks help, but deep down ours is a "brain" job. On average, people have a short-term memory capacity of seven items, plus or minus two. What about the average reader of this book? I bet you're closer to eight, nine, or, heck, you in the back row reading the comic book might be as high as ten (plus or minus three).

Turning to my personal to do list, I see about 20 items. Damn. That's a lot more than 10.

There's no way I can trust my brain to remember 20 items. I need a little external storage. So do you.

I hope you aren't insulted when I say "Don't trust your brain."

I don't trust mine. That's why I write down every request, every time. Whether I use a PDA or PAA, when someone asks me to do something, I write it down. This has become the mantra:

My brain feels a little insulted by this lack of trust. When someone asks me to do something my brain starts yelling, "I'll remember it! Put down that PDA, Tom! Trust me this time!" However, all the inspiration I need to record the request is to hark back to those times when I've had to face a customer who was upset that I hadn't completed his request and deliver the rather lame excuse, "I forgot."

In Chapter 2, I discussed delegate, record, or do. When we delegate a task, we don't have to record it, though it is sometimes wise to record that we should follow up with the delegate to make sure the request was accomplished. (We are, so to speak, our brother's keeper.)

Also, if we are going to do the task, we don't have to write it down. If someone asks, "Please pass the salt," I don't write in my to do list, "pass the salt," and then cross it off my to do list. That would be silly. However, if someone asks me to do something and I say, "Sure, right after I'm finished with this," then I write it down. Don't confuse "when I'm finished" with doing something right away. In fact, for me, the biggest temptation to not write something down is when I think I'll remember it because it's what I'm going to be doing next.

Before I reveal The Cycle System, I want to explain some systems commonly used by system administrators that don't work: The Scattered Notes System and The Ever-Growing To Do List of Doom.

The Scattered Notes System involves writing notes on random bits of paper or having multiple to do lists scattered about. My favorite is when I see a video monitor encircled with yellow rectangular sticky notes. Is each one an action item? A reminder? A phone number? Who knows? What is the priority of these? What if one falls off? There's too much chaos.

When you get assignments at a meeting, you start a new list. Now you are managing two lists. Then you lose one list because it got thrown out with other papers. Now you're missing meetings and failing to meet deadlines. Not a good situation.

The other extreme is The Ever-Growing To Do List of Doom . Usually someone realizes that having many lists or scraps of paper isn't a good way to track things, so he buys a notebook and declares that this will be his one list. No more confusion, right? He diligently carries this notebook everywhere. Any new assignments get written in the notebook, and old tasks get crossed out as they're completed. The process works great at first, but then it starts to break down. It's difficult to prioritize work. Older items get forgotten since our eyes tend to look only at the last (newest) few items.

The most important failure of this system, and why I call it a list of doom, is that it's pretty damn depressing. The list never ends. You work and work and work, and the list never seems to get any shorter! You cross off items that you complete, but new items appear at the end. The number of pages starts to accordion out as you cross off items in the middle, but there's that one item waaaaaay at the beginning that is just never going to get done. Soon you are flipping through pages of crossed-out items to find the one item that isn't crossed out. You feel stressed because you fear missing an incomplete item hidden in pages of crossed-out items.

I've explained why follow-through is important, that we shouldn't trust our brains, and the qualities of systems that fail. Now I'll explain what makes a system that will succeed.

A good system has the following qualities:

The elements we need to make a good system are:

The essence of the system is the day-by-day page, which should be big enough for both that day's schedule and that day's to do list. FranklinCovey and Filofax sell stationery like that (see Figure 4-1). Alternatively, you can keep this information in a PDA. We're going to take our organizer with us everywhere we go so that if someone asks us to do something, we can record it right away and not be tempted to scribble it on a slip of paper that will be lost before we can copy it into our PAA/PDA.

The Cycle is the evolution of a system that has worked for me for over 10 years. It's relatively lightweight, yet it includes all the pieces a system administrator needs.

There are four parts in our organizer:

The Cycle goes like this: each day starts by investing 10 minutes to plan my day. The planning process is simple:

Let's work through a single-day example to see how the system works.

When you enter the office each morning, you should immediately focus and start this process. Otherwise, you will be caught by the interruptions and distractions that surround you: your voice mail light is flashing, people are stopping by, the coffee machine is calling you, and you are curious what Dilbert and the group at User Friendly are doing today. You decide to check your email and...hours later realize you've wasted half your day.

So STOP. Don't check your email or read the news sites. Instead, close your door (if you are lucky enough to have one) and follow the steps of The Cycle.

The system is flexible enough that as you face new situations, you can adapt the system to handle them. This section lists some of the techniques I've found useful.

If you use a PAA (paper notebook), you can find filler paper that fits all of the following needs at a stationery store. You will need:

If your projects are small, you might be able to make due with a small datebook. Larger ones contain at least a few lines per day to keep notes. However, you might not be able to keep many to do items in such a book.

If you use a PDA, you have many choices. PDAs usually come with software that lets you keep an appointment calendar, to do lists, and notes. However, there is a wealth of aftermarket add-on packages that can greatly enhance the experience.

DateBook (DB) V (http://www.pimlicosoftware.com) won my favor early on because it makes implementing the "to do list per day" concept very easy. I like to think of it as finishing what Palm set out to do. A Palm-based PDA without DateBook V is a toy. DB V makes to do entry very fast through the use of templates, uses color effectively to highlight what's important, and can give advanced warning of an event. This last feature is particularly useful to me. Before DB V, I had to enter a reminder for someone's birthday and plug in an additional reminder a week early so that I had time to buy a gift. With DB V, I can simply request advance warning of an anniversary or birthday. DB V is only available for PalmOS. One of the nice things about DB is that it maintains its data in the normal PalmOS data structures, so all your items sync just as you would hope they do.

Life Balance (LB) (http://www.llamagraphics.com) is not just great software, it's a great philosophy. LB has all the important features of The Cycle (to do lists, calendars, and so on), but it adds the important concept of being aware that your life needs balance. Maybe you've decided you want to split your time between three projects plus home life. If you've been ignoring one of those categories, to do items from that area will start appearing higher in your priority list. Eventually your life is back in balance. It's a great concept and many people swear by this software. It's available for Mac OS X and Windows, and it syncs to a PalmOS version.

Once, while I was teaching my Time Management for System Administrators seminar, someone said that when he's done with one task, he wishes someone else would pick the next task for him. He said he spends too much time worrying about what to do next. That's when someone else chimed in about Life Balance. You program it with how you want your life balanced, and it sees to it that you meet those goals.

The Cycle uses the calendar part of your organizer for three primary purposes. First, to block out time for events and meetings that are further in the future than today's schedule. Second, to list any reminders or milestones such as birthdays and anniversaries. Finally, if you use a PAA, the calendar is where you can record to do items that are further in the future than your current daily filler paper permits. Here are descriptions of calendar items in more detail:

It's rather simple: always record everything, and always use your calendar to guide your day.

When you take 10 minutes to plan your day, start by reviewing what you've recorded in the calendar entry for today. It points out meetings and appointments that you've committed to; use this information to make your day's schedule. To do items noted in your calendar are transferred onto today's to do list. Milestones and deadlines may translate into additional to do items.

Balance is important. Work, family life, social life, volunteer work, personal projects, sleep—these are all important things. I'm a firm believer in using one calendar for all of them.

The reason to maintain one consolidated calendar (or merged calendar view) is that it helps prevent your work life from overrunning your nonwork life. When you are about to agree to work late, you can look at your calendar and verify that you are actually free.

I used to leave work and then realize that I had a party or something fun to go to. I would drive like a maniac to get there before it ended. When I did arrive, I was too angry with myself for being late or forgetful to really enjoy the party. Now if there is something fun after work, it's part of my daily plan. Being on time for a party is as important to me as finishing a project on deadline. I give my full effort during the day, but nighttime is my time.

Most PDA software lets you keep multiple calendars but merge them into one display. In fact, it can be useful to configure your PDA synchronization software to not sync personal items onto your work PC (and work items onto your personal PC). You might not want your party plans synced to your work computer.

History repeats itself. So do status and staff meetings, oil changes, El Niño, and a good burrito. A lot of the routines developed in the previous chapter become recurring events. One of the benefits of a PDA over a PAA is that recurring events can be scheduled once, and the PDA does the work of calculating all the subsequent dates.

Here are some of the things you might want to put into your calendar:

Take a moment to record those things in your PDA right now. Then develop the habit of recording any new date the moment you hear it.

Nature is full of rhythms. As you accept requests for meetings and appointments, it's a good idea to consider your personal rhythms .

There are two hours each day that I'm able to get a lot done.

The first is the hour before most people arrive in the office. I'm not a morning person, but I find that if I can drag my lazy self into the office an hour early, in that first hour I can get more work done than I can the rest of the day because there's nobody else around. It's important not to waste that hour on things like email. Use it for a project that can't get done without your full attention. (See Chapter 2 for more examples.)

The other hour is your high-energy hour. There is a part of the day that you are able to concentrate better than you can the rest of the day. I call this my "big brain hour." This is a different hour for everyone. For some it is the afternoon, for others it is late at night or early in the morning. This is a real biological phenomenon (Google "circadian rhythms"). NASA uses it to schedule shift work in space missions. Many people take advantage of it to schedule their most difficult tasks during the time of day when they naturally have more energy and ability to concentrate.

Take some time in the next week to find when in the day you are most able to concentrate. You might set your computer to beep once an hour. When you hear it beep, write down on a scale of 0 to 10 your energy level and your ability to concentrate. Find the time that both of them are high.

Once you find a pattern, try to modify your schedule around it.

Schedule your brain work around the time of day when you concentrate the best. Reserve that time for the most important (high-impact) projects. Try to schedule meetings away from that time, unless your meetings require serious brain power. Most don't.

Your high-energy time might change as you grow older. When I was younger, that time for me was right around 2 a.m.; now, it's more like 2 p.m.

Business is full of rhythms, too. If you identify the rhythms of your company's year, you can make sure your plans are in concert with those rhythms. Anything else is like trying to swim upstream. Your calendar is the long-range planning tool that lets you do this.

Every business has a light time of the year and a heavy time of the year. You can plan your system administration tasks and goals around these patterns.

I used to work at a software company that produced three software releases each year. Every 120 days, a new release would ship. The first month was mostly spent developing marketing requirements and feature lists. There were 60 days of development, two weeks of quality assurance (QA), and two weeks of manufacturing of the software and manuals. Day 120 was shipping day. Then the entire cycle began again. Because it ran like clockwork three times a year, it was a system administrator's dream.

During the first month of the cycle, most of the employees were in meetings and the network was quiet. As long as email was running, nearly any other function could be taken down for maintenance and upgrades. The "tool group" planned which OS/compiler releases would be used for the next version during the last days of the prior release cycle. The first month of the current cycle was when the system administration teams would deploy those tools. During the development stage, outages were tolerated if they were scheduled. Regular system administrator activity could happen. However, toward the end of each 120-day cycle, planned outages were banned. This was a very intense part of the cycle, when new code releases were being shipped to QA almost daily. As a result, this was the best time for system administrators to take time off. A skeleton crew was always around to deal with emergencies, but, otherwise, this is when the system administrators scheduled their vacations. Once the software "went gold" and was in manufacturing, stability was only important in the parts of the system that manufacturing relied on. Everyone else was celebrating. Then the cycle began again.

The big secret is to write down your goals. When they are in your head, they aren't as fleshed out as you think they are. They are nebulous. They can't be evaluated, shared with others, or worked on.

The process of writing them down forces you to make them concrete. It's also a lot easier to prioritize a list that is written down.

Written goals can be shared with others. If you have a significant other, you can share your goals with him or her and discuss them. We forget that our loved ones aren't mindreaders. By sharing our goals, we get support and a reality check. We are more likely to achieve a goal if we have told others about it. There's something about telling someone our goals that motivates us to act on them.

It is easy to accidentally write vague goals. You can make a goal significantly more concrete by answering these questions in each goal statement:

Everyone forgets the when. It's easy to never begin if you don't set a deadline. In the chapter opening, I was careful to include a specific deadline for each goal.

It is also important that goals are measurable. The goals in the chapter opening were mostly measurable. "Living comfortably" could be more specific: a retirement income of 70 percent my current income. Learning "more" about Linux kernel internals isn't measurable. I can fix that by adding a milestone to be achieved, like writing a simple device driver.

In preparation for writing down your goals, take a moment to think about your values . What do you see as your personal mission? Do you believe in helping others or letting others help themselves? Do you want to be rich or happy (or can both be achieved)? Do you value independence or cooperation? Do you value community or self-interest?

How to Get Control of Your Time and Your Life (Signet) is a classic book on time management. The book brings out the necessity of listing your short-, medium-, and long-term goals, and encourages you to categorize them into A, B, and C priorities, with A being the highest priority.

Let's do just that.

Take a big sheet of paper and divide it into six sections, as shown in Figure 7-1 (people with lots of goals or large handwriting might want to use multiple sheets of paper).

You're going to fill in each box with a list of life goals in that category. You can add additional timeframes if you feel your goals are grouped differently.

Now spend some time listing your goals. To help you get started, here are some guidelines:

Don't worry about their order or whether your goals are good enough for anyone else to see. Just list them. I'll wait.

Really. I'll wait. Don't continue to the next paragraph until you've completed your chart. Not in your head, but on real paper.

To achieve these goals, you must determine the steps required to get there. You need to break down each goal into the specific tasks that you can write on your to do list. You might want to do this in a word processor so that you can cut and paste into your PDA or print the list and hole-punch it so that it fits in your PAA.

If you aren't sure of the steps, write what you can think of or write down "Research how to do this" and some ideas of where to do the research.

Don't worry about writing the steps in chronological order. Sometimes we have to work backward. You ask yourself, "How would I get there?" and write that step, and then ask yourself, "But how would I have gotten there?" and write the step necessary to do that. Eventually, you work backward through the process until you have all the steps you need.

As an example, I'll write my next steps for the goals listed in the beginning of this chapter:

Now that you know what you want to achieve and the steps that will bring you there, you can sprinkle your next steps throughout your calendar as to do items.

Due to business patterns or family responsibilities, you might have more free time during a certain time of the month or year. Pick the time that you think will most likely assure success. (If you are off by a day, don't worry. The Cycle System will move the steps to the next day.)

Look at the steps you've recorded and consider what the best order should be. Write the first one or two items from each list on the appropriate day's to do list. Let's use "Learn more about Linux internals" as an example. If today is Monday, I write the "Ask for recommendations" step on today's to do list. I should have recommendations by Wednesday, so turn to Wednesday's to do list and write, "Purchase a book based on sage-members recommendations." I'm too cheap to pay for overnight shipping from Amazon, so on the following Monday's to do list, write, "One hour of reading Linux kernel internals book." I write that same item on Tuesday's through Friday's lists, or if I'm using a PDA, I use the "repeating to do item" feature. I don't know how long it will take to read the entire book, but I can set a goal of having done the last item in that list (write a nontrivial program using what I've learned) a week later. If I don't add these items to my to do list, they will never get done.

The 24-hour goal of doing laundry was a joke; it is more of a task than a goal. However, it is a good example of how to link goals to a to do list. I put the first three steps on the place reserved for "after work to do items." I put the last item (fold and put away) on the to do list for the next day.

If you have a lot of goals, this process may seem intimidating. However, this just means that you need to spread your goals out more or downgrade some of the priorities.

It's easy with a PDA to schedule to do items far in advance. However, I find it better to not schedule any single item too far in advance; otherwise, it gets lost. Or I read the item and don't remember what it means. Instead, I schedule the next one, possibly two, steps for each goal. When the step is done, I have a better idea of how much time to allocate for the following steps.

What you have now is a good start. However, you need a way to make sure you keep with the system. On the first day of the month, every month, take a moment to plan your goals. Close your office door (or go to a quiet place) and do the following:

Over time, you'll get much better at figuring out how to schedule the next steps into your calendar. I try to sprinkle them into Mondays so that when I plan my week, I can make room for them, sliding them to a better day if needed.

How can you remember to do this? Set a repeated event in your PDA called "Goal & Next Step Review." Have it repeat on the first of every month or the first Monday of every month. Now you'll always have a reminder to do this process.

If you use a PAA, set up a sheet of "repeating events" that is reviewed at the start of each month. Every time I load the next month's worth of page-per-day sheets, I go through the "repeating events" sheet and use it to mark the various goal steps in my calendar.

There you are at your desk facing today's daily to do list. Dozens of items. How do you decide what to do first?

This section is about prioritizing these items. Different situations call for different schemes. In previous chapters, we used a very simple scheme: if it has to be done today, it's an A priority; if it has to be done soon (but not today), it's a B priority; and everything else is a C priority.

"So what do you do if all your items are A priorities?"

Read this chapter.

The previous sections described ways to prioritize individual tasks. Now I'll present some useful techniques for prioritizing projects.

If your boss asks you to do something, and it's a quick task (not a major project), do it right away. For example, if your boss asks you to find out approximately how many PCs use the old version of Windows, get back to him with a decent estimate in a few minutes.

It helps to understand the big picture. Usually such requests are made because your boss is putting together a much larger plan or budget and you can hold up your boss's entire day by not getting back to him with an answer quickly. Perhaps he is working out the staffing and cost estimates to bring all PCs up to the latest release of Windows. The entire project would be held up while waiting for your answer.

Why does this matter? Well, your boss decides your next salary review. Do I need to say more?

Maybe I do. Your boss will have a fixed amount of money he can dole out for all raises. If he gives more to Moe, then Larry is going to get less. When your boss is looking at the list of people in the team, do you want him to look at your name and think, "He sure did get me an estimate of the number of out-of-date Windows quickly. Gosh, he always gets me the things I need quickly." Or, do you want your boss to be thinking, "You know, the entire budget was held up for a day because I was waiting for that statistic." Or worse yet, "All the times I looked foolish in front of my boss because of a missed deadline, it was because I was waiting for so-and-so to get me a piece of information. So-and-so isn't getting a good raise this year."

As a system administrator, I find my two biggest sources of stress are feeling overloaded and being given conflicting directions from management.

When I feel overloaded, I remind myself about the techniques for to do list management in Chapter 5. I close my office door (or steal a conference room), get some peace, and focus on The Cycle techniques. Soon, I realize that what got me feeling overloaded was that I was skipping steps. I go through the steps and plan the remainder of my day, moving to do items to the next day, and so on. It feels good to manage all of my tasks.

When I'm really overloaded, that doesn't work, and I have to seek a higher power, most particularly my boss. A good boss can help prioritize your workload when you are overloaded. It is not a weakness to confess that you are overloaded. Asking for help is a sign of strength. It takes a lot of courage to ask for help, and even more to accept the advice offered.

If your boss isn't around, anyone can help. Explaining the situation to someone can really help with the stress. Even if they don't have any advice, at least you feel like you've been heard. Often that's half the battle. Being heard by others feels good. However, they usually do have advice or can give you reassurance about the things that are unsettling. That always makes me feel better.

The act of explaining something out loud to someone helps us solve our own problems. How many times have you realized the solution to a problem while explaining it to someone else? Life is full of those moments when you tell someone, "So there's this problem, see? If I...." Suddenly you realize the answer, and there is no need to continue talking. It happens all the time.

The Practice of Programming (Addison Wesley) tells the story of one person at Bell Labs who was known for helping many people solve their highly technical problems. Sadly, he couldn't always stop what he was doing to listen to someone, so he had a teddy bear in his office. When he was busy, he would tell people to "talk to the bear." It worked very well. Soon he found people stopping by his office and going straight to the bear.

Let me tell you a little secret about vacation time.

Companies don't give you time off because they want to be nice to you. They aren't doing it to be charitable.

They're doing it because you're difficult to work with when you are stressed. Let me say that a little more forcefully: when you postpone taking time off, you become a pain in the ass to everyone in the office, and we don't like working with you. You're irritable, difficult, and disagreeable. SO TAKE TIME OFF, DAMN IT!

Sorry for yelling, but it's for your own good.

A successful vacation takes your mind off work enough so that it can relax. It may take several days to forget about work enough so that you are in full relaxation mode. Only then can your body repair itself. I need at least three days to get to relaxation mode, and then six or more days of relaxation to really feel refreshed. Add a couple travel days and a day to get back into the swing of things, and we're talking 12 to 14 days for a really successful vacation. You deserve at least as much.

Let's look at some common vacation mistakes that system administrators make:

From an early age I had bizarre misconceptions about yoga, meditation, and massage. I thought they were strange things that should be ignored. How wrong I was! They are all excellent techniques for relaxing the body and mind. They are important parts of a good relaxation and stress management program to maintain top mental health.

But before I go on, let me embarrass myself by telling you what I thought they were:

It's funny how early impressions stay with us for so long.

When I was in my mid-20s, I signed up for a class on relaxation that met one night a week for eight weeks. I wouldn't have taken it if I knew it was going to teach things like yoga, meditation, and massage. As I said, those were "weird" things that I ignored. They tricked me!

The idea of the class was to give people a taste of various techniques. It wasn't expected that everyone would enjoy all of them. However, if there was a single one that worked well for you, you could explore that further. Sort of like the fried appetizer special at Denny's.

Your email reader is not the most effective time-management tool. Anyone who has tried to use his inbox as his to do list quickly discovers this. It works great for a day or two, then suddenly you get a flood of emails, and it all goes to hell in a handbasket. Messages are mixed with to do items, and there is no way to prioritize or keep track of things.

Therefore, my recommendation is to keep your inbox clean.

To keep your inbox clean, you need to have a plan for what you're going to do with every email message you receive. Each possibility has to end with "delete the message," or your inbox will start to fill up. In fact, if you don't delete it soon, you'll be stuck going back over old messages to figure out what to do with them. That means you'll read each email message twice (maybe more) before acting on it—not very efficient.

When dealing with interruptions in Chapter 2, we used a system called delegate, record, do. For dealing with email, we have a few more options:

I know to an experienced email user like you these points seem obvious and self-explanatory, but indulge me. You might know how to manage email, but are you really doing it? The following sections go into more detail and include tips I've picked up along the way.

The difficult part about this system can be getting started. If you have 2,000 email messages in your inbox, this system must sound like some kind of unrealistic fantasy.

My recommendation? Forget the really old stuff and move forward.

Some mail clients have special archive functions. However, it is just as easy to create a folder called "DeadItems-2005-11-19" (or whatever the date is) and move all items older than that date into that folder.

Now you have a clean inbox, and if someone does need you to pull something out of your old archive, it's all right there.

And if you don't touch that folder for a full year, burn it onto a CD-ROM, delete it, whatever, just get it out of your mailbox. If you haven't touched it for a year, there is little chance you'll touch it ever. Your email client will run faster now that it doesn't have to manage such a huge index.

I'm still waiting for someone to write a program that will seek out all email older than a year and burn them onto a CD-ROM, along with a little Java program that would let me search and browse the messages, and even restore selected items to my mail reader. Alas, such a beast doesn't exist. I even have a cool name for the technique: "Pickled Email" (like the food-preserving process). If you invent such a tool, you are free to use that name—no charge.

Does it sound impossible to just let go of 2,000 email messages?

Let me ask you this: when are those 2,000 email messages actually going to get processed?

Next month?

How long have you been saying "next month"?

Before I developed the previously described technique, I tried two other methods unsuccessfully:

I define a time waster as any activity that has a low ratio of benefit to time spent.

Everything has some kind of benefit. Spending five hours playing video games has an entertainment benefit. However, other things have benefits that might be more valuable to you. For example, spending the same

amount of time to increase your quality of living by doing home repairs has longer-lasting benefits than blasting millions of pixilated aliens.

The things that waste our time at work are different—phone calls with people who never stop talking, inefficient processes, waiting around for all our lunch buddies to assemble so we can leave for lunch, etc.

Some time wasters are just irresistable. It comes down to "everything in moderation." Short conversations around the watercooler break up the boredom and monotony of the workday and let us return to work refreshed. Multihour conversations about nonwork topics, on the other hand, are not so valuable.

The problem is that it is difficult to do things in moderation. As Oscar Wilde said, "I can resist everything but temptation." It's difficult to say to yourself, "I'll just play video games for a minute" or "I'll just look at the subject lines of my email and only read the important ones." Soon you're deleting spam, replying to requests, and then you look at your clock and see that a few hours have passed.

So what works?

I can avoid temptation if I set up rules of thumb and mantras for myself (see Chapter 3) and then find ways to enforce them.

It would be nice if every five minutes our brains would think, "Gosh, what's the benefit of what I'm doing right now?" That would help us recognize when we've fallen into a time waster and snap out of it. Sadly, we're not built that way.

I've found that it's better to set up rules for myself. Rules such as "When this alarm goes off, I'm going to stop playing this game." At home, I have an old-fashioned kitchen timer with a loud bell that requires two hands to turn off (one to hold the device, the other to turn a knob to 0). Thus, I can't just slap an off button and return to my video game. (I also enjoy the irony of being surrounded by technology but using an antique timer.)

In the office, I'd feel silly with the mechanical timer going off all the time, and the noise would disturb my coworkers. Therefore, I use other alarms and reminders, such as iCal.

While I find that I can be much more productive in an office with the door closed (due to the lack of interruptions and noise), there are times when having a coworker with me makes it easier to avoid temptation.

Here are some common work time wasters and advice about how to better manage them.

We can often find ourselves deluged with meeting after meeting. That's OK if work is getting done, but learn how to detect when meetings are wasteful .

There are many kinds of meetings, but let's group them into two general types: status meetings and work meetings. Status meetings are just that: people reporting on progress on their aspects of a project. Work meetings are when people try to get work done.

It can be a waste of everyone's time if you try to problem-solve during a status meeting. If something can't be resolved quickly, pick a time for the involved parties to work it out—don't waste everyone's time. I find it useful to have that meeting immediately after the current meeting. People not involved can leave or drop off the conference call. Everyone is already together, so there's usually no scheduling conflicts to work out.

When I email an announcement of a meeting, I indicate whether it is a work or status meeting. This makes it clear what people should expect and puts them in the right mindset. It also makes it easier for the facilitator to cut off inappropriate discussions when they arise.

As a participant, I realized that I had an influence on whether the meeting was going to be a waste of time. Being on time significantly improved the meeting's efficiency. Being prepared (reading the material being reviewed, etc.) meant I wasn't dragging the meeting down. If I was presenting material, emailing copies to everyone a day early made other people better prepared (though that meant I had to be prepared a day early). I always send an email reminder about meetings 24 hours in advance. This reduces the number of people who arrive late or people who disrupt the meeting's effectiveness by not showing up at all.

For a system administrator, the ultimate time waster is any task that could be eliminated if only we had time to build the infrastructure to make such busywork go away. In other words, the ultimate time management technique for a system administrator is a good IT infrastructure.

Strategic tasks are those dealing with long-term planning, like constructing a security policy, getting buy-in from management, and deploying the policy. Tactical tasks are specific tasks related to a particular process, such as formatting a hard drive or installing a new PC.

The problem is that we get so caught up with tactical tasks that we never feel that we have time for strategic work. We're so busy mopping the floor that we don't have time to fix the leaking faucet.

You won't need to spend time handing out IP addresses if you deploy a DHCP server. You won't find yourself spending days fixing security problems if you have a modern and pervasive security program with things like automatically updating virus/malware/spam detection, self-defending networks, and policies that are supported by the highest levels of management. You won't spend afternoons debugging oddball Windows problems that turn out to be slight misconfigurations if you have an infrastructure that automates operating system installation so that every new machine starts out right. You won't spend nights restoring data from backup tapes if you have a server infrastructure that includes proper power, cooling, and redundant storage (RAID). (Not that RAID replaces the need for disaster recovery backups.)

The key is to make time for the strategic projects. Get them onto your calendar and schedule time for the individual steps in your to do list. My rule is to always have one strategic project going on. I'd like to have 50, but if I spread myself too thin, I won't get any of them done. It's better to pick one good project that gets done than to start 50 that never get finished. The advice in the section "Prioritization for Impact" in Chapter 8 will help you narrow down the project. Get consensus on which project will have the biggest impact, and get the whole team working on it until it's complete.

In place of big ol' scary documentation , what do system administrators need? You need repositories to store the information that will help you from a time management perspective. Your boss may have her reasons for wanting you to maintain documentation, but I recommend that your inspiration be something different—selfish. Build documentation repositories that serve you and your time management needs, not the seemingly irrelevant needs of your boss or quality department. Specifically, SAs need two repositories:

The first repository saves you time by making customers more self-sufficient. It deflects them away from bothering you. Why should they call you to ask a question when they could read about it? This way, they will only call you when they need clarification. Many customers prefer the self-help route simply because it saves them from embarrassment when they ask silly questions.

The second repository is useful because you make it useful. In particular, you record all the processes, procedures, and reference materials that you need at your fingertips. It is another opportunity to store something digitally so that it doesn't take up space in your brain. It reduces the work your brain has to do so that you can be more focused. Focus is good.

I suggest two repositories because one needs to be freely accessible by all customers, while the other may contain sensitive information that should be restricted for security reasons.

In these two repositories, you should accumulate:

To make a web site (repository) full of pages that are easy to update, use a Wiki. A Wiki is a concept, not a particular software package. There are many software packages that give you the Wiki feature. There is the original Wiki (Hawaiian for quick), then there is TWiki, KwikiKwiki, PHPWiki, etc. It's such a good idea that plenty of people have written software systems that give you the feature.

So what the heck is a Wiki?

It is a web site in which anyone can edit any page, and linking pages is really easy.

Sounds crazy, right? I mean, if anyone can edit any page, what about vandalism? Someone could come along and delete things, put incorrect information into the system, and so on. It would be a disaster!

I promise you that there are some features that completely eliminate these problems. First, let's just consider the positive side:

It's difficult to find time to automate processes, so we have to be choosy. We can't automate everything. The problems SAs typically deal with fall into four general categories :

Now, for the visual thinkers, it may help to see these categories as a chart (Figure 13-1).

To automate something, first you have to do it manually. Then you write code for each step. Next, you bring the little bits of code together, testing each addition as it is added. Finally, you test the entire system.

Here are some automation examples that are simple things we do a lot. Windows system administrators take heed—these examples are fairly Unix/Linux-centric, but the general principles apply to all operating systems.

    alias book='cd ~tal/projects/books/time/chapters'

    alias book 'cd ~tal/projects/books/time/chapters'

When we find ourselves doing something very difficult, automating the task records what we've done. When we do it in the future, it will be easier. This is how we build up our little bag of tricks.

    $ mkisofs -D -l -J -r -L -f -P "

               

                  Author Name

               

               " -V "

               

                  disk label

               

               " -copyright

      copyright.txt -o

               

                  disk.iso /directory/of/files

               

            

    #!/bin/bash



    mkisofs -D -l -J -r -L -f -P "Limoncelli" -V 'date -u +%m%d' $*

    $ makeimage1 cdrom/

            

    $ makeimage1 cdrom/

               

                  dir1/ dir2/

Often we are asked to create a way for normal users to do things typically permitted only by an administrative account such as root. This can be quite dangerous and should be done with great care.

In Unix/Linux, there is a program called sudo that lets system administrators give a person the ability to run a command as another user. It is very restrictive, requiring the system administrator to configure it to specify exactly which user(s) can run which command(s) as which other user.

For example, you can configure it to permit a particular person to run a command as root. You can rely on sudo to make sure that only the people you specify have the ability to run this command as root, but it is important that the program check the parameters to make sure that privileged users are able to overstep their bounds.

For example, if it requires root to run the Unix mount command to access a CD-ROM. It is a bad idea to configure sudo so that the person can run the mount command as root with any parameters. He could crash the system or break security. It is much better if you configure sudo to let the person run a new command (say, mountcd) as root. This command will make sure that he has specified the particular CD-ROM drives that the user is permitted to mount (with a logical default), and mounts that drive. You also want to give him an (unmountcd) command.

I like to build three layers when I automate something for other people:

The techniques in this book may save you hours, if not days, each week. If you save a little more than an hour per day, you can get the same amount of work done in a four-day workweek .

So, what will you do with all this free time ?

Please don't squander it. I beg you. When I first started applying time management techniques to my life, I used all the new free time I gained on my then-current addiction: reading more Usenet NetNews. I guess the contemporary equivalent is to spend it reading RSS feeds, blogs, web sites, and such. Many such things are time wasters. Please don't use your new-found free time to pack more time wasters into your life.

I have a better idea.

Use this new-found free time to fight injustice.

The most common injustice that I see every day is the way corporations steal our lives away from our families. We wake up one day to find that our children have grown up hardly knowing us, or that our significant others are leaving because they hardly see us. "How did the time pass so quickly?", we wonder to ourselves.

There used to be the so-called "implied social contract." We work for a company 40 hours a week and in return we are paid enough to live plus a pension to retire on. It was a fair deal. However corporations now expect more and more of our time with no increased benefit to us. Geeks typically work 60–70 hours a week only to be laid off en masse due to the bad business decisions of clueless CEOs that are paid hundreds, if not thousands, times our salary. When I was at AT&T/Lucent in the 1990s, we were constantly reminded that we should expect less job security from the company whether or not we did a good job. We were told to praise the shift from guaranteed pensions to "every man for himself" 401(k)s. And yet, in my final years working there, the management was shocked and dismayed to find less loyalty from the employees. Loyalty is a two-way street.

Want to do something radical? Revolutionary? Use the techniques in this book to reassert the 40-hour workweek and reclaim your family life: