A different type of disaster recovery

Have you made plans for recovering from those employees who leave a catastrophe in their wake?

We all know what disaster recovery is, right? It’s the planning and execution of a set of steps following a catastrophe. While this typically applies to applications and hardware, it rarely refers to people. Sure, departments cross-train in case their key people get hit by a bus, but that’s not what I’m talking about. I'm asking whether you've ever thought about what it takes to recover from a bad hire.

Let’s say your company hires somebody who isn’t particularly bright. Not only does this employee write bad code, make bad purchases, or build horribly stupid processes, maybe he or she is even influencing more than their fair share of projects. Perhaps you’re stuck with them for a few months or even a year or two. After they're gone, how do you recover from the disaster that's left behind?

[ Cut straight to the key news for technology development and IT management with our once-a-day summary of the top tech news. Subscribe to the InfoWorld Daily newsletter. ]

In such an employee's aftermath, plenty of things could be out of whack, not only in terms of key systems, but in changes to company policy. Maybe this person insisted on Active Directory policies that complicated management duties. Maybe they championed ETL policies that slowed processes. These actions can be expensive to undo and require a lot of downtime or even extra hardware.

So what’s your plan for recovering from this human disaster? Are you keeping a running tab of the things he’s done? Are you doing your best to insulate your systems?

My first piece of advice would be to keep your senses. Trust your instincts and your training, and don't let them talk you into a bad idea.

From there, make sure you have some kind of plan you can implement after this person is gone. At the very least, keep a journal of what he or she has touched and the problems you had with them so that you can go back later and figure out what needs fixing. Don’t count on your memory to be accurate in six months. You may even find it helpful down the line -- seeing all of the project problems in one place may show you something you wouldn’t have noticed otherwise.

This story, "A different type of disaster recovery," was originally published at InfoWorld.com. Follow the latest developments in data management at InfoWorld.com.

Copyright © 2009 IDG Communications, Inc.

How to choose a low-code development platform