There seems to be a spectrum that all people can be classified into. One end of the spectrum is “doing” and the other is “planning.” There are the cowboys at one end, who never plan anything but just do things. There are the dullards at the other end that never actually do anything because their plan might not be complete.
Most of the IT folks I work with seem to fall in the center somewhere, where they know just the right amount of planning that it will take to implement something, but then can switch gears and get it done. Often these people fall towards the “doing” side of the spectrum. I’ve noticed a disturbing trend lately, though, where managers are pushing their people to be on the planning end of the spectrum. This is great when the people they’re pushing are cowboys, who just do things and make changes without care or regard for anybody else. But for a lot of people these extra planning steps just reduce their effectiveness, and ultimately end up causing frustration. They’ve already done the planning, and are caught in two poor assumptions their managers have:
- Meetings, and meetings alone, constitute planning.
- In order to have effective planning for a change you must ask everybody who has anything to do with anything you’re changing.
I work with a lot of highly skilled techies, who, when they want to change or do something, can work out the plan in their head by themselves. They walk around to all their coworkers and use them as sounding boards first, then approach the stakeholders and talk to them about it. Once people agree they go ahead and implement that plan. They fill out all the paperwork in their change management systems, typing in a well thought out, cohesive plan that took all of 20 minutes to think up and get support for (and then another 20 minutes to document). They schedule the change for a time that’s least disruptive to everybody but themselves, just in case something should go wrong.
Suddenly, though, these techs that have pulled off change after change after change, flawlessly, are being forced to hold meetings and build consensus with people who have no freaking clue what the tech is talking about. If a meeting was necessary they would have held one, but if it wasn’t really necessary they wouldn’t have. They wouldn’t otherwise ask people about the change who aren’t going to have credible input on the topic. Why should they ask the customer about upgrading the backup clients on all the machines when the upgrade process is well-known, well-tested, non-disruptive, and the customer just cares that restores are possible when they need one? It’s nice to tell the customer what’s going on, so they realize that the money they spend on you is actually worth it, but it’s not up to the customer in the end. So don’t make it a choice for the customer (as an aside, I like to call this “sysadmin perogative” — you hired me to make the call so I’m making it).
These system administrators and programmers I speak of were hired to DO things, not to talk about doing things. While there is merit in a planning process when one is warranted, like for changes that cause outages, just because one cowboy doesn’t plan anything doesn’t mean that everybody is like him. Just because another tech likes to hold meetings for many of the changes doesn’t mean that everybody should. This isn’t first grade, and rules intended for one person don’t have to apply to everybody else. Managers, quit frustrating your good guys by saddling them with the B.S. you need for the bad guys. Let them do the jobs you hired them to do.
