Having spent 30+ years in IT, the one thing I can definitively say about the people that make up this amazing profession is that we are notoriously poor communicators! Even though there are those of us deal directly with customers or teams that aren’t in IT, we still struggle. As the late, great Strother Martin so eloquently stated in the film Cool Hand Luke, “What we've got here is failure to communicate”.
I recently had the opportunity to fill a manager level position on my staff and decided one of the questions I’d like the candidates to answer was “If something goes wrong or changes in the world you and your team support, what is the first thing you would do?”. Not one of those seasoned candidates provided anything close to the answer I had hoped for, which was something to the effect of, “Inform those that have been impacted.” As is natural for most techies they jumped right into problem solving. I got a lot of “troubleshoot”, “triage”, “assess”, and the infamous “root cause analysis”. Sure. I get it. We all want to figure out what’s wrong and fix it - we’re problem solvers by nature! But what about letting those impacted by the issue know there’s a problem and that IT is aware and working to correct it, and we’ll update you as soon as we resolve the problem? Unless it’s your email system that’s down, how long does it take to fire off a quick blurb to those that depend on those services?
"Good communication doesn’t take much time nor does it usually require much effort. Next time you’re hip deep in a situation that requires you to change something, take a few seconds to ask yourself “Who needs to know?"
But let’s get back to the real issue… communication. Being a good communicator isn’t just about sending out notifications when something is wrong. To help improve my team’s communication, I’ve tasked them to ask and answer one simple question… “When something changes, who needs to know?” Regardless of the nature of the change, there is almost always someone that can benefit from the information. I’ve yet to see an organization or even a person that “over communicates”. I have seen plenty of poorly constructed communication that was so long and verbose it left me wondering what the actual message was. But at the end of the day, that’s just poor communication.
Good communications shouldn’t be restricted to break-fix and other problems. Anything that is changing should prompt a communication of some sort to those impacted by the change. Rolling out a new version of software; let the team that uses it know! Upgrading some systems that will take down some servers for a while; let the team know! Even if you’re doing this over a weekend and “no one ever works on the weekends”, let them know. This could be the one weekend someone decided to pull some numbers for a new sales presentation and now IT gets a black eye because the systems are never up when they need them! One of the best ways to ensure communication occurs is to make it part of the Change Control process. Who needs to know?
The best thing about being in IT and improving your communication is that the expectations aren’t really all that high which means the journey to being a much better communicator can be relatively short.
So to the question “Who needs to know?” ask yourself the follow up, “What do they need to know?” The message should relatively short and to the point. And most importantly, it should be composed with proper context to the audience. I expect most of your customers or associates in your company do not care about ANY of the technical details or issues that caused the problem or might be changing. For issues and problems, let them know the current state and any next actions. If something is changing, in addition to the “what”, let them know what’s in it for them. A brief explanation of how will they or the company will benefit is always helpful. And if the situation around the change is new or different, let them know that too. Statements that are direct, simple, and contain as little technical information as possible are always best.
We recently had a situation where a ticket came in asking IT to grant system access to an associate who was taking over for someone leaving the company. The ticket was received by the appropriate team, assigned to a technician, and then closed a couple hours later. The next day the manager of that team emailed me asking if I could escalate the ticket. What? The ticket is closed. Upon some investigation I found that the access had indeed been granted, but as the technician closed the ticket, he neglected to contact the impacted party (Who needs to know?). Nor did he inform them that the access he had provided required a system reboot (What do they need to know?). By not answering those two very simple questions, the technician turned a positive into a somewhat negative situation.
Good communication doesn’t take much time nor does it usually require much effort. In fact, comparing the effort of communicating to that of solving some of the incredibly difficult problems presented to IT, it is probably the easiest thing IT ever gets to do. My advice to you is simple – next time you’re hip deep in a situation that requires you to change something, take a few seconds to ask yourself “Who needs to know?”