In my past I’ve been a theatrical lighting designer. I’m not professionally trained, I just sort of picked it up by working with community theater groups. A friend who is a professionally-trained lighting designer once gave me a tip about darkness, in one of those situations where I was trying to illuminate only a small part of the stage for a particular scene:
“Always leave some light on the rest of the stage. Humans get curious about what they can’t see, and they won’t realize it but they’ll spend a bunch of time watching the absolute darkness instead of what you want them to watch.”
When I light a show I usually have some general “down” light available, so the fix is easy. Just leave the down light on at a very low level, just enough to make sure people could confirm, even subconsciously, that there was absolutely nothing interesting to see on the rest of the stage.
The same trick is useful in IT, especially when you’re writing outage descriptions for users. Complete lack of detail is infuriating for many, and it steals focus from the good work you’re doing. Think of all the Apple update release descriptions: “Fixes for performance and security issues.” Um, what are the performance issues? Was it the one I am experiencing? Am I going to have to sit through downloading & installing this just to find out that you didn’t fix any of my problems? YOU HATE ME AND DON’T RESPECT MY TIME.
You don’t have to go to an extreme and list everything you’re doing (that’s what change logs are for), but a little bit of extra information goes a long way to tell users that their inconvenience is worth something. It makes them feel like part of the team, and often helps them remember to do something you’re asking them to.
Bad: “Leave your desktop on tonight.”
Good: “Please leave your desktop on tonight, and SAVE OR CLOSE ALL YOUR WORK! We are going to apply security updates and reboot the PCs to keep us all safe from hackers. Please let us know if you have any problems in the morning, or concerns in the meantime. Thank you.”
Also, always be polite. Please & thank you, even if you aren’t really asking.
I am usually not sorry for the inconvenience of routine preventative maintenance, because that’s what they pay me for. However, if it’s because of a hardware failure or human error I am, and I elaborate on what the problem is. After all, users hate computer hardware as much as we do, and it doesn’t take you more than 10 additional seconds to explain. Also, give them an ETA so they know if they should go grab lunch or something:
Bad: “The server is down.”
Good: “The server is down because one of its memory modules died. We are replacing it with a spare and expect it back up at 12:30 PM. We apologize for the inconvenience.”
You can also take the opportunity to show that you’ve practiced the work, and aren’t just recklessly messing with them (which is what some users will always think):
Bad: “Servers X, Y, and Z will be down from 0600 to 1800 on Sunday.”
Good: “Servers X, Y, and Z will be down from 0600 to 1800 on Sunday, as we are replacing the controllers in one of our disk arrays to make it much faster and extend the life of our investment. We did this on our test array and it went very smoothly if the servers were offline during the upgrade. Please let us know if you have any questions or concerns.”
IT is a no-news-is-good-news operation. Use the little bit of contact you get with your users and customers to show them that you’re on top of things, and give them enough detail, in layman’s terms, to keep them from feeling like you’re trying to hide something from them in the dark.
