Выбрать главу

It took me nearly 10 years to develop a rule for each of those questions, and, by amazing coincidence, for each of them the answer was the same. Save yourself many painful experiences and believe me: the answer is "Yes!"

However, scheduling mini meetings with 15 people would have taken longer than the meetings themselves and wouldn't have worked in the chaotic environment of system administration. Therefore, every Monday and Thursday at 9 a.m., I would do my "walk-around." I would walk a particular path that went by each person's office. Their offices were, essentially, in three different clusters, so it was almost like having three mini status meetings. I would stop in, say "hello," and this would present them with an opportunity to bring up issues.

It would take me half a day to do this, but it was a really good opportunity to troubleshoot problems in real time, remove roadblocks, and solve the problem of people feeling ignored.

Our weekly staff meeting was on Tuesday morning. The Monday walk-around usually resolved a lot of issues that would normally tie up the Tuesday meeting, so we reduced the time allotted to our staff meetings. Shorter meetings are cool.

I was surprised at how well it worked. I was also surprised that anyone noticed. Alas, one day I was walking towards a cluster of offices, and I overheard someone saying, "Here comes Tom for his Thursday visit," followed by a little laughter.

OK, they were mocking me. Did I change? Did I vary the schedule to be less predictable and obvious? No. I'm too thickheaded for that.

However, I did notice that over time my staff started planning their schedule around my walks. Sometimes I would arrive and they'd have a list of issues on the whiteboard ready to discuss.

Here are two takeaways from this story:

Develop a routine that solves your problems.

Perform the routine on a predictable schedule, and others will plan their schedules around you.

Routine #5: The Check-In-with-Customers Walk-Around

If you are supporting a number of people who are in the same building as you, you can increase customer satisfaction by doing a walk-around once a day to visit customers, talk with them, answer questions, fix problems as you see them, record bigger problems to be worked on later, and so on. If anything, it develops a better rapport with your customers. That alone is very valuable.

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