At the end of last week a bunch of us network folk on Twitter were having a rollicking conversation about why the network always seems to be the first thing blamed when problems in an IT environment erupt. That and some recent happenings here at work got me thinking about the communication flows between teams in an enterprise IT setting.
Communication in IT Departments you ask?
Short Version: It usually sucks.
Long Version: It usually sucks, but it’s not necessarily our fault. I think a lot of it is the nature of the tasks we deal with.
I imagine just about everybody in this biz runs into a situations where if just a little extra bit of info was originally communicated it would have saved you a boatload of work. I’m not talking here about the flow of info from clients (This is one I heard today – I guess I should have told you I moved that cable to another jack in the wall.) I’m referring to things that your buddies who working in the same IT trenches that you are knew but didn’t share. They may be members of your immediate team, or members of some other IT group. Whoever they are, valuable info that could have saved you and your clients time fell through the cracks and never reached your ears.
I don’t think this would be very surprising to non-IT folks. They tend to have that image of the geeky kinda socially clumsy IT guy. Remember Jimmy Fallon’s socially challenged version from Saturday Night Live (I always laughed my ass off at that skit)? Most of us probably know one or two guys like that, but that hasn’t been the norm in the environments I’ve worked in. So why does this issue always crop up?
Big changes seem to get handled well. Circuit switchovers, server/system rollouts, maintenance upgrades are usually pretty smooth from a communication standpoint. Multiple announcement emails/updates are always sent out; anybody who may possibly be affected always seems to get a notification (whether or not they bother read it is entirely different matter, of course). That kind of communication usually works pretty good.
Unfortunately, It’s the small stuff that trips us up. The list is endless.
You mean that application connectivity issue I’ve been dealing with is due to a small bug the app folks are working on right now?
An anti-virus update started by the security team is slowing down that small remote office?
Firewall rules for that application were modified yesterday?
You’re working with the vendor on an ongoing slowness issue with that site I’ve been troubleshooting?
To me, the problem is with how much information there is. If we try to communicate every little change and every little incident we would be overwhelmed. The flow of info could be enormous, especially for larger teams. How would you ever be able to see through the noise and zero in on the relevant info?
I also think there’s a natural tendency in IT to not want to be blamed for doing something when you’re pretty sure there’s no way what you did could effect anything at all. Let me give an example (yes, this recently happened to me). Say you close up some ports on your firewall that were for an old app that’s not is use anymore (verified through the application team and your own analysis of archived sniffer logs), and you announce the change to the rest of IT. Are you really that surprised when you come in the next morning to find three help desk tickets assigned to you for problems that have nothing to do with your change?
The reasoning on the helpdesk’s part was simple – These users are having trouble hmm… Wait! Didn’t the network team make a firewall change last night? That probably what caused the problems! They’re the ones to handle this. Is it any wonder why information isn’t always shared? Sometimes all it seems to do is put a target on your back.
I’d love to hear how others navigate the murky communication waters in IT. Do you find using Instant Messaging helps? Do you use tools like Twitter or Yammer? How do you draw the line at what levels of communications you announce?
Thanks for reading,
Jason