Fire the Process Jockeys

Everybody in the IT Industry loves ITIL these days. That’s fine, it’s a solid framework for operating IT. My problem though is when processes, especially incident, change and problem management, become organisational constructs full of laddershakers. If, like me, you’ve been on incident calls with over 50 people it’s likely that many of the people on the call are incident, problem and change managers. Thanks to twinning, you don’t just get one of each –  different silos in your organisation have them, your outsourcers (likely several companies) have them, and the managers have assistants (more grandly titled ‘analysts’) to do the pointless admin when the boss has finished wasting everyone’s time. Fire them all.

Why do I hate these roles so much? Because they have little or no technical expertise, so they constantly require the technicians who do to explain and justify their actions. That wastes effort and valuable time when an incident is critical. Change Management used to drive me and anyone else who wasn’t a laddershaker insane, explaining to them what I was doing, why it was important, how I was doing it and what I was going to do if it went wrong. On the plus side, because they knew nothing, I could spin any story I wanted (short of blatant lies) to get over the first hurdle. I used to tell people that it didn’t matter what they put in the backout plan, it just had to be ten lines long. Any less and you’d get told it was too short, any more and it was too long, these being the only available checks to the incognoscenti. Some very bad people just used to copy and paste random examples. Lorem Ipsum generally got spotted, but any plausible text would do. Once I’d persuaded Change Management, the change then went to an army of approvers, 90% of whom had no idea what I was doing and what the implications were. Most of them just nodded stuff through, but not before I’d wasted more time nagging them.

I remember a meeting in Melbourne where we decided to test the system. We had to submit a change form for a major project, and as part of that we had to list all the software we were going to use. This seemed pointless, so we took the initials of our first names and came up with CRANGLE 2.0. No-one questioned it, although I found out later that crangle has a rather unpleasant meaning in the urban dictionary.

What to do then? First, accept that implementing processes does not mean that you need a team for each process. Embed the processes into the teams that do useful work. Train people to operate the processes and support and audit them with lightweight communities of practice. You will get rid of lots of expensive people and your organisation will move dramatically faster. That one-line change that took six weeks (see Ever wondered why you can’t get anything done?) might just get back to being a five-minute piece of work. Remove the comfort blanket, trust people to do their job and sanction or fire them if they wantonly put the organisation at risk.

Just to show this really is possible, next week I’ll look at probably the most effective team I ever ran – completely laddershaker-free.