Techie, trust thyself and respect will follow

It’s a tricky business, communicating IT updates to users, particularly during a system downtime. Send out too many messages, and users ignore them or find them annoying. Send too few, and users demand to know what’s going on. All the while, you want to convey the kind of information that shows the tech team is in control. Well, a few years ago I was that person walking the thin line.

I was working in the IT department at a hospital, a setting that poses unique challenges in and of itself since it never closes and people’s lives and health are on the line. Technical maintenance was difficult because we often had to shut down the systems. By doing it at night, the shutdowns impacted the fewest people, but departments had to use their “downtime procedures,” which could affect patient care. Communication was critical.

[ Get a $50 American Express gift cheque if we publish your IT story. Send it to offtherecord@infoworld.com. | For your daily dose of workplace shenanigans, follow Off the Record on Twitter. | For a quick, smart take on the news you’ll be talking about, check out InfoWorld TechBrief — subscribe today. ]

While we were being trained for the task, my supervisor stressed how important it was during downtimes to contact all the tech departments involved before sending any information; that way, the updates would be accurate. We had to work efficiently to show users that we recognized the inconvenience and took systems down only when necessary.

Learning the ropes

Luckily, the first few downtimes that I was responsible for went off without any problems. But it was a busy job. Days in advance, I’d send out pre-downtime emails alerting the users to the scheduled maintenance. Then, on the night of the downtime, I’d send email and text updates of when the maintenance was starting, open up a conference line for anyone to get a status, answer questions from users, keep in contact with the techs, send announcements if an unexpected problem occurred, and finally notify users when the system was back up and ready to be accessed.

But it wasn’t too long before I learned that even though my job was to be a conduit of information between the techs and the users, making the decisions about what information to pass along was ultimately my responsibility. I had to trust myself.

A botched communication

The evening of another scheduled maintenance arrived. I took my place, ready for action. Everything started on time, and I sent the necessary messages letting users know. The techs reported that all was working as it should. I watched the clock as it ticked closer and closer to the stated finish time.

The phone rang. I expected the all-clear, but the tech said there was a problem and we would be “just a few minutes longer.” When this had happened another time, the techs had given me an estimated delay to pass along to the users, so I asked what it would be. The tech’s reply surprised me: “There’s no need to send out any messages since it will just be a few minutes more. No need to make us look bad.”

“OK,” I said to myself. But 30 minutes went by and I was getting nervous. I called the techs and got the same response: No need to send out the message. My instincts told me that users needed to know and keeping them informed would make the tech team look less bad than no message at all. But I waited.

Another 30 minutes went by. At this point, I was starting to panic but was told the same thing by the techs. Meanwhile, calls were coming in from angry physicians and nurses wanting to know why the system was not up and why they were not being informed.

I was sweating and going in circles in my mind about what to do, but was too hesitant to take any action. Finally, 90 minutes after the stated finish time, the system was back up. I had not sent out a single word of communication in that interim.

The next day, I caught serious flak from what seemed like every employee in the hospital, including my managers. My reputation and confidence took a serious hit. Fortunately, I was neither fired nor relieved of the communication duty.

Be strong

But I learned a valuable lesson: When it’s your job on the line, don’t let others influence you to deviate from the plan. They won’t suffer — but you will. And not sending information was a disservice to the users. I resolved that the next time this happened, I would trust myself and do what I thought best in the situation.

Eventually, this same scenario happened again. But this time I was the seasoned and battle-tested veteran. As soon as the tech called and said, “It’s going to be only a few more minutes, no need to send out the communication,” my fingers were already flying, writing and sending out the messages. Three hours later the system came back up. The techs were upset with me, but I felt I had done the right thing. I went home and slept soundly.

The following day, users and my managers showered me with accolades. And the next time maintenance was delayed by the infamous prediction of “just a few minutes,” the techs told me to do what I thought best.

Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to offtherecord@infoworld.com. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “Techie, trust thyself and respect will follow,” 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.