Stop Bashing IT Operations

Stop Bashing IT Operations

It has become almost fashionable to bash internal IT operations as the thing that must always get cut, as opposed to IT innovation efforts that must be nurtured. I’m a little worried about all the bashing. If all internal IT ops are lumped together and discarded, that’s bad for business. Some discernment is needed.

Sometimes, IT operations bashing is deserved — when organizations don’t keep up with the times, aren’t customer focused, or won’t consider adopting new ways of working that are measurably better. But let’s not throw the baby out with the bathwater.

I feel I can defend “traditional” IT ops, because I have played in both the innovation and operations spaces: everything from ops of public safety technology, where reliability is about 1,000 times more important than minor innovations, to innovation in cloud computing and open data.

I’ll share a non-secret: Operational excellence is the underpinning of any successful internal innovation program. Without it, my IT organization wouldn’t have the credibility to launch any of the cool things that we do. We would not have the time either. When things are always on fire, there is no time for innovation activities.

Let me be clear about whom I am defending. I am not talking about the “data center union,” those who will not admit that there are better ways of doing things. These folks are so busy saying no that they won’t take the time to evaluate new options, which today might include using infrastructure-as-a-service, or non-technology imperatives like collaborating more closely with marketing.

I have no time for those folks, and I’ll be watching with a certain amount of head-shaking when they plummet off of a cliff of their own making.

I’m defending those practical people who are focused on the rhythmic, trouble-free fulfillment of IT’s everyday details: making sure that we have enough capacity before we need it (people on the help desk, for example), ensuring that we responsibly plan before we execute (making sure that we don’t cut over a new system before business stakeholders have tested out critical functions), and so on.

Read more at InformationWeek>>