Unassuming IT hero saves the day

analysis
May 2, 20125 mins

The techie's superpowers: Common sense, a clear mind, and the ability to read the fine print overlooked by everyone else

It isn’t often that a tech pro gets recognized for saving the day — especially when you’re just doing your job.

This is a story back from the early days of my IT career. It was in the ’90s, and I’d been out of school a couple of years and working at a VAR that provided hardware, software, and service. Recently, I’d been promoted to senior field support engineer and transferred to the corporate division, which served small business and enterprise customers on a variety of platforms.

[ InfoWorld’s Paul Venezia reveals the 9 traits of the veteran Unix admin and other secrets of data center administration in The Deep End blog. | Follow InfoWorld’s Off the Record on Twitter for tech’s war stories, career takes, and off-the-wall news. | Subscribe to the Off the Record newsletter for your weekly dose of workplace shenanigans. ]

One morning we got called to a conference room to deal with a hot issue that had come up. As we entered, the account manager and service manager were almost screaming at each other, and the tension was rising. This itself wasn’t too surprising, since sometimes the account managers promised customers more than what the service department could deliver.

Then we were told about the problem. One of our large corporate customers couldn’t configure a new server they’d just bought from us. Since this was a big company that had a large IT team of around 15 systems administrators managing Unix and Windows, they had not paid the extra fee to have us install and configure the server. Their admins had tried, with no luck. They were blaming our product and threatening to close the account.

The service manager was sending a tech to the customer’s site ASAP. He emphasized how important it was that we fix the problem and smooth over any hard feelings toward our company, and we could take all the time we needed to resolve the issue. Then he asked for a volunteer. Silence.

Finally, the service manager nominated the new guy on the tech team: me. The other techs gave me sympathetic looks as they left the room.

Before I left, I called the customer’s IT director to let him know I was on my way and to find out more details about the problem they were having. He said that he’d gotten just about everybody on his team to get the server configured, but they couldn’t do it. He was obviously angry and frustrated. From the sound of things, it was a big, complicated problem, so I grabbed most of my hardware and software diagnostic tools and ran through various scenarios in my mind as I drove.

When I arrived, the IT director had one of the system admins escort me to the server room. There sat the high-end server we had sold them. The admin described what they’d done to try to configure the server and said it would be good if I could get it to a point where they could install the operating system. Then he left, saying he’d check on me in a couple of hours.

I had started at the bottom level at the VAR as an in-house tech doing all the corporate configurations, so I could handle these setups with my eyes closed. For this particular server, you had to do some preconfiguration before starting to install the operating system and drivers. This process was clearly outlined in the included quick-start guide, which I noticed was taped to the side of their new server in plain sight but had apparently been ignored.

Ten minutes later, I’d completed the preconfiguration steps and started installing a version of Unix on that server. About an hour on, I went to the IT director to get him to sign that the work order was closed.

He was shocked that I was able to fix the problem so quickly when nearly everybody on his team had been working on it for two weeks. Not quite believing I’d solved the issue, he walked with me back to the server.

I demonstrated it was working and told him what I’d done. Then I mentioned that apparently nobody had read the quick-start guide taped to the server and showed him the part of the guide they didn’t do. He read the very simple step and rolled his eyes, then signed the work order and apologized for all the trouble.

After exiting the premises, I called my service manager to say the issue had been resolved. He was thrilled and gave me the rest of the day off. Not only that, the very next day the account manager took me out to lunch.

I felt like a hero, even though the issue was due to a very basic oversight from not reading the quick-start guide. I guess that’s why they now have the acronym “RTFM.” Taking a step back and looking again at the basics can save a lot of trouble.

Do you have a tech story to share? Send it to offtherecord@infoworld.com. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “Unassuming IT hero saves the day,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

infoworld_anonymous

Since 2005, IT pros have shared anonymous tech stories of blunders, blowhard bosses, users, tech challenges, and other memorable experiences. Send your story to offtherecord@infoworld.com, and if we publish it in the Off the Record blog we'll send you a $50 American Express gift card -- and, of course, keep you anonymous. (Note that by submitting a story to InfoWorld, you give InfoWorld Media Group, its affiliates, and licensees the right to republish this material in any medium in any language. You retain the copyright to your work and may also publish it without restriction.)

More from this author