Thomas Limoncelli - Time Management for System Administrators

One person I worked with had a very shy, smart, but not so computer-savvy group of customers. They had a tendency to not report problems because of their shyness, and possibly because the previous system administrator was a bit of a grouch. As a result, they were living with many inefficient workarounds—most of which my coworker could easily fix to make their lives better.

When I learned that my coworker was doing a daily walk-around to troubleshoot problems, I was appalled! Doing this went against our policy of recording all issues in our request-tracking system! It was an affront to our attempts to get people to send email to "help" to report problems. How could this be a good thing?

I soon learned that it was a great thing. People tend to not report little annoyances, figuring that the problems can't be fixed (especially people who aren't computer-savvy). The walk-arounds dramatically reduced the number of annoyances and greatly increased the group's productivity. It also helped foster a better relationship between my coworker and her customers, so much so that they began to include her in planning for major projects, which increased her ability to solve problems before they happened.

Do not use this technique if you have a problem saying no to people. Part of the reason it worked so well was that my coworker employed something like the delegate, record, do process of Chapter 2. I'll call her system fix, redirect , or sympathize .

Fix. If the problem was easy to fix (less than two minutes), she'd fix it right then and there.

Redirect. If the problem couldn't be fixed in a few minutes, she would help the customer send email to "help" to create a ticket in the request-tracking system. This was a group that wasn't used to creating tickets, so it was scary for them. Walking them through the process made it less intimidating.

Sympathize. Many times the issue was just something that couldn't be fixed, or it was a known problem that wouldn't be fixed for a while. My coworker found that the best thing to do was to show sympathy without being condescending. "Yeah," she would sigh, "it's crummy that it works that way." The person would agree and feel better now that their complaint was acknowledged. Then my coworker would say, "I don't think there's a way around that, but I'll keep an ear out for a solution." This benefited the customer in that it validated that something was annoying and unfixable, rather than leaving it a mystery. It benefited my coworker in that it prevented the unsolvable requests from entering the request-tracking system but gave her a way to gain an understanding of what the general issues were. Some were noted in her PDA. When she did learn of a solution, she could return to the customer with the solution and look like a miracle worker.

The important thing is that she didn't try to solve every problem right then and there. Sometimes the walk-around was a more efficient way to collect requests that would be done later. Other times she was developing relationships with customers that would help her understand those customers' long-term needs. Other times it was simply a way to offer sympathy to get people beyond the unsolvable problems of our world.

I imagine that when my coworker started using the walk-around technique, she was overwhelmed by how many issues were being reported. As I mentioned, do not employ this technique if you have a problem saying no to customers. This technique requires discipline, or you'll end up spending the entire day with the first person you talk with. However, over time, the initial flood of requests will be dealt with, and the walk-around can become more of a maintenance mode kind of thing.

Routine #6: Pre-Compile Manual Backup-Tape Changes

In the Preface, I told an anecdote about changing the backup tapes. It was a complicated task with eight different tape servers that may or may not have needed a fresh tape each day. Each day I would spend time calculating which tapes were full enough to warrant a new tape (i.e., the next night's backups wouldn't fit in the remaining free tape). Then I would walk around to all eight servers, scattered all over the building, with the new tapes.

Eventually, I realized that I could avoid all the calculations if I changed the "big servers" every day and the "little servers" once or twice a week. That was a big savings, not just in my time but in my brain resources.

Again, this was a case of "stop thinking, just do." Sure, I wasted some tape by estimating rather than doing a perfect job, but my time was more valuable than the tape.

The other part of the story is that I tended to change the tapes at the end of the day. If I was deeply involved in a project (I usually was), then I wouldn't realize how late it was and would be scrambling to change the tapes. Usually I would be late to leave work, and the need to change the tapes would just make me later. Whether I was going home after work or to one of my many volunteer responsibilities, I would end up angry and upset because "those darn tapes made me late...again!"

This was a case of needing to figure out a better schedule. I realized this mantra:

If it has to be done every day, do it early in the day.

After I did my morning planning using The Cycle, I would list "change tapes" as an A priority every day.

As a result, there was one less thing weighing heavy on my mind all day, and I could be more focused and less stressed. I arrived home happier and less late. I started the day feeling like I had accomplished something right off the bat, and I had!

Routine #7: During Outages, Communicate to Management

Once upon a time there was a network outage. To make matters worse, there was miscommunication from the system administrators to management and the customers. Management felt they should have been told earlier about the problem. The system administrators felt they should be left alone to solve the problem. I'm sure this kind of thing has never happened to you...not.

After this event, we decided to develop a routine for the future. After all, this wouldn't be the last outage.

The routine was simple: after an hour, a particular manager (the boss of the chief system administrator) would be notified of an outage, even if it was late at night. The system administrators would then update this person every half hour until the problem was resolved. The manager would notify upper management and customers (if the outage didn't prevent communication to the customers) so the SAs could focus on solving the problem.

It was a simple routine and it worked well. Too bad we didn't have it in place before the first calamity.

If your company is particularly visible (hello Amazon, Google, and Yahoo!), such a routine should involve the Public Relations department. It's important to have this routine worked out before your first major outage, no matter how difficult it is to discuss. Some outages are so big that news reporters will want to know what's going on. You can imagine how messy things can get. This was more common long ago when anything with the words "Internet" or "computer security" was spiffy enough to draw in the news media. (Now the media has become jaded, and "Microsoft security hole affects millions of businesses" is unfortunately no longer considered news.) Nonetheless, if your business is high profile, it is important to have a media strategy worked out with the PR department ahead of time. Know whom to refer to if reporters start calling. If you don't have such a plan in place, the best answer you can give is, "No comment;" then hang up the phone before you are tempted to say anything else. It's very tempting to say something to a reporter, but many system administrators have learned that the best thing to do during an outage is to work on the technical issues and let PR deal with the media.