Why Most IT Departments Are Modeled After a DMV

I've seen another cause change of aversion in big organizations: admin bonus pay was tied to application uptime. This created a hilariously dysfunctional situation where the admins locked the developers out of production and refused to deploy any code changes to production, including bug fixes, for several months. Senior leadership in the organization insisted this was the best model to ensure service stability. In the meantime agile competitors ran circles around them until the service became irrelevant, but just look at those uptime numbers!

The problem is that IT gets inundated with tons of requests and everyone thinks their problem is more important than someone else's. The moment you start queuing up requests and trying to apply some order to the chaos is the moment IT's bad reputation develops. It's a thankless position for sure.

The article doesn't offer a solution, but points out what we already know. Even though the "cloud" is to supposed to eliminate the need for a big internal IT department, you still need someone to support your cloud environment, which takes you back to square one.

This is a well known problem - Joel has a great post on how procedures can kill creativity in his "Big Macs and the Naked Chef" post: http://www.joelonsoftware.com/articles/fog0000000024.html

Slides 40 to 56 of the following NetFlix presentation could be a solution. Instead of adding more processes and procedures, hire good people who are effective at managing complexity:

http://techcrunch.com/2009/08/05/other-companies-should-have...

"Simple, obviously non-destructive changes should have a way of being expedited in your organization."

One man's 'simple non-destructive change' is another's 'horrifying perversion of everything.'

Management is so slow to implement change because even the smallest changes can have lasting and far-reaching effects.

I think that adherence to codified change control is really not the cause as this article suggests. These issues are management issues - claiming a framework for managing the chaos which results from bad management is poor root cause analysis.

Poor management results in both poor testing and underdeveloped project understanding.

If you have solid, well funded (with both money AND time) testing - the impact of change is minimal.

Further, the propensity for IT to say no stems from their understAnding of how poorly upper management allocates resources to IT as it is historicLly been seen as a liability/cost center rather than integral to business. (obviously this is far less true in silicon valley).

Clearly though, having good IT managers and staff are important and you find a lot less 'no' with good staff.

IT organizatiOns typically report to the CIO/CTO and are overshadowed by the CEO. If the CEO is of the typical Sales/Marketing DNA (or the "I used to be a developer - we don't need that much redundancy!" DNA, which can be worse) then they typically underfund all infrastructure projects.

Finally, IT gets the blame for all downtime, so it's their asses if the shitty managers decisions impact service.

So, ITIL is not the issue. People are. IT needs competent leadership to succeed.