First things first. Backpack fucking rocks!! I’ve been using it to take notes where ever I am on topics I’d like to write about. Now I just gotta write about them. Here’s a rough draft of an essay I’m working on about Change Management in the Enterprise.
Change Management professionals have value… Everyone in the enterprise has value. They keep (in theory) developers out of the production environment. Which is good. As much as I like dropping a quick fix in on the fly, I don’t want that responsibility on my head. No developer in their right mind should. If it hasn’t happenned already, give it time, we all slip up and when developers have production rights, those slip ups can cause serious problems
This isn’t to say that CM is just as capable, if not more so of fragging up the works in production. Quite the contrary in my experience. But that’s a matter of training and culture.
It’s all about the benjamins, yo!
Recently I’ve noticed an alarming trend among the CM people at my office. They’re inefficient. Actually they are beyond inefficient, they’re slow and mostly incompetant. They take hours to complete any task. Tasks that they would historically spend hours on, have been canned into 20 minute processes. The key, that I have found… they’re contractors. It’s financially beneficial to be slow and inefficient. Every hour it takes to complete a build request and deploy code to INT, is money in their pockets. I can’t say I blame them, money moves us all (though for teh record, as a consultant, I’ve never billed for a mistake I made. Fixing my errors has always come out of my own time). This phenominon isn’t limited to the CM people at my office, or even to CM people. It’s everywhere. For reasons I can’t fathom, large companies hire contractors, who (in my experience) take much longer to complete tasks than their salaried counterparts. On top of this, most companies keep these models of innefficiency around well beyond a year. Often several years. A year is often the magic cut off for contractors. Keeping a contractor less than a year is cheaper than keeping a salaried employee the same amount of time.
The rules apply to everyone.
Recently one of our CM people made the call that application X was broken. Our latest build package had bad code. Without consulting development, he chose to “fix” the problem by taking a zip file he was given as a one time solution and apply it this time. The code in this file was old production code. He was “fixing” cert. In the strictest sense of the word, he did indeed fix cert. Application X was working. Of course it was working like old production code, so the functionality that was to be tested wasn’t present. Long story short, and believe me, it’s a long story. He broke two key tenants of the CM process.
- Don’t deploy code without a build request
- Don’t act without technical input. CM is not development.
By breaking the rules that they have strictly enforced on development CM, illustrated that they are no better at being the gatekeepers than developers are… at least developers know the system the are keeping the gate for.
Code pushing monkeys
I know this sounds harsh, but CM really is nothing more than code pushing monkeys. Yes, they can be more than that. They can be much more. Most seem content to not be all they can be though. Most seem happy being, “warm bodies” and nothing more. CM has the potential to regulate the flow of applications moving toward production. They can be the gatekeepers and keymasters.
Why do they stumble? I don’t know, it seems to be an enterprise culture type of thing. CM seems to infest an organization, grow in number, then stop. They become road blocks, or worse even, detours in the abyss. They’re not developers (wouldn’t that be nice if they were?!), they’re not technical in most cases. They deploy code. They copy zip files. They send emails asking DBAs to run scripts. They send emails asking infrastructure people to bounce servers. That is what CM does.
One day the enterprise will realize this, and the era of “Change Mangement” as we know it will be over.
I’ll clean it up a bit soon, expound on some thoughts, add some new ones. This is version one. But you can see where I’m going with it.
