Say you’re an IT manager with a project that’s doomed. You know it’s doomed. Everyone on the project team knows it’s doomed. Maybe it’s underfunded, or the technology turned out to be half-baked, or it’s beyond the skills of your team, or it’s just hopelessly off the tracks. Maybe you argued against it, but it has powerful sponsorship and there’s no way you can talk the powers that be into shutting it down.
Is it time for a little sabotage to put it out of your misery?
Of course, sabotage is wrong. We all know that. But which is worse: torpedoing a doomed project, or flushing time and budget and morale down the drain in a futile effort to make it work?
Or suppose some user’s PC fails intermittently. It doesn’t happen every day, but every time it does, the user loses time and work and a little more sanity. The user’s manager is demanding that you fix the PC, but there’s no problem you can identify and reproduce. You know the right solution is to replace the PC, but as long as it tests out OK on the bench, corporate policy says it must be put back in service.
Do you make sure it gets a little, er, help to fail on the bench, so that poor user can get a reliable PC again?
Now try this one: For the first time, your team has been assigned a user to help identify problems with an important application. The user doesn’t understand how your shop does things, doesn’t have the clout or charisma to overcome outsider status and has slowed progress to a crawl with all his questions and objections. And you know that if this project is completed, you’ll have users on lots of future projects — all with the same problems.
Do you drive the project — and the user — straight into the ground, just to avoid all that trouble?
It’s sad but true: Sabotage is a slippery slope. At heart, it’s about breaking things instead of making them work, destroying instead of building. It’s an ugly concept that runs counter to everything you’re supposed to be doing, a notion nasty enough that in most IT shops it’s never even mentioned out loud.
Trouble is, in most IT shops it’s also a reality. In fact, it’s a necessity.
Sabotage shouldn’t happen. But then, neither should ill-conceived projects or wrong-headed policies. And ugly as it may be, sometimes sabotage is the least ugly of the real options available.
Ironic, isn’t it? You want your IT people to do what’s right for users and the business — to keep time and effort and budget from being wasted. But sometimes they can’t do that without a little sabotage. And you can’t encourage them to keep doing what’s right for users and the business unless you tolerate that sabotage.
But if you’re too tolerant of it, you’ll end up with self-serving sabotage — the kind that doesn’t help users or the business at all, but is just a convenient way to cut corners and avoid challenges.
How can you be sure you’ll get only the right kind of sabotage? You can’t. Remember, sabotage is unmentionable. You can’t clearly explain what kind is OK and what’s not. And you can’t officially support it, because by definition sabotage is against the rules.
So you’ll have to depend on nudges and hints and the good judgement of your staff. You’ll also need to watch out for cases of the wrong kind of sabotage, to stop them quickly and publicly. If you can’t explain, at least you want to offer lots of examples.
Does all this subtlety and ambiguity make you uncomfortable? Good — it should. You really shouldn’t need sabotage to serve users and your business. That discomfort should motivate you to keep chopping away at the things that make sabotage necessary — the foolish rules, the politically motivated projects, the really awful decisions.
Because until you can get rid of them, you’re stuck with sabotage.
