Delegation: Has there ever been as broad a chasm between a concept and its execution? Delegating is to management what antibiotics are to medicine—the cure for a thousand ills.

  • Do you need to grow your staff, and groom them for management?
    Delegate some work to them!
  • Are you swamped with work yourself?
    Delegate some tasks to your subordinates!
  • Is your organization missing out on the input of your line employees?
    Delegate meaningful authority to them!

Unfortunately, it’s much harder to actually delegate than to simply talk about delegating. In this column, I’m going to quickly review the problems behind effective delegation and then offer you a strategy for deciding which projects to delegate, and to whom.

The 800-pound gorilla lurking behind every delegation decision
When you ask IT managers why they don’t delegate more of their work to their staff, you get a variety of responses. Some will tell you that delegation takes too much time to explain and implement (time that they don’t have). Others will say that their people are already overloaded themselves and don’t have time to pick up more work. Still others will point out that they don’t know which projects to delegate and which to keep.

There are other objections to delegation, but behind all of these lies the real issue with delegation, the 800-pound gorilla no one wants to talk about. Crudely put, even if you delegate a task to a subordinate, it’s still your butt on the line. If a project goes south, you can’t go back to your boss and say “It wasn’t my fault. I delegated it to Joe Smith.” Well, you can try it, but your boss won’t be very impressed.

The sad fact is that you can only delegate work, not responsibility. If you own the project, you own the project, whether or not you do the work yourself.

Risk analysis can help
Since you can’t get off the hook, the temptation for too many technical managers is to keep all the work. Managers who do so are operating on the theory that since they are going to be held accountable for task failure, they’re going to do the work.

While such an attitude is understandable, it’s not sustainable. No IT manager that I know could possibly do all of his or her work without help. They’re just too busy.

Besides, those benefits I mentioned earlier (helping to develop a subordinate, getting broader participation in decision making) are real, even if often over-stated. Therefore, the decision isn’t whether to delegate, but how.

One method for successful delegation is risk analysis. I’m not talking about a long, drawn-out process with interviews or charts.

My idea is to ask yourself a series of questions that can help you determine which projects to delegate and to whom you should delegate them. These questions are designed to determine the risks associated with delegating each project, and how to limit that risk.

Here is my list of questions. Chances are, you already ask yourselves several of these before delegating any task:

  • How important is it? This is probably the most common factor in choosing a task to delegate. In general, managers are more likely to delegate less critical projects. (Of course, you have some folks who will insist that all of their projects are equally important, but they’re idiots, so we’ll ignore them.)
  • How much work will it take? Of course, you can’t begin to look at delegating a project without knowing how much effort it will require.
  • What capacity do you have? Once you know the answer to the previous question, you need to determine if there is room in your current workload to take on the project.
  • What capacity does your subordinate have? This question naturally follows the question above. You need to decide if your staff has the time for the project.
  • How long will the project take? Again, speaking generally, technical managers are more likely to delegate projects that have a long completion horizon, on the theory that they can always take back the project if needed and still hit the deadline.
  • How bad can it get? In other words, what’s the worst-case scenario? Assume the project gets totally bollixed, and then determine the implications.
  • How long will it take to fix? This question is the corollary to the previous question. Assume the project heads south, and then determine how long it will take to undo the damage.
  • What are the odds of success? This question can go either way. On the one hand, if a project seems destined for failure anyway, you might decide to delegate it, thinking that since you don’t have time for every project, you should limit your involvement to ones that have a real chance for success. On the other hand, you might decide not to delegate a project that’s likely to fail, on the theory that you might be able to make it work.
  • What skill sets are necessary for success? Unless you’re some kind of superhero, odds are that some of your projects need a skill set that’s closer to that of one of your employees than to your own.
  • Who could benefit from working on this project? Is there a subordinate who needs the experience that could be gained from working on this project? If so, that factor should enter into your decision-making process.

Make a decision, don’t drift
As I mentioned earlier, these aren’t the only questions you should ask yourself. The point is to give yourself some time to quietly consider the implications of delegating a particular task or project. Since you’re going to have to delegate some of your work anyway, the smart move is to be proactive and choose projects to delegate up front.

The only alternative is to wait until you’re completely overwhelmed, and then ask for your subordinates to bail you out. I think we can all agree that this is a delegation strategy that’s doomed to fail.
Have I left out any important questions from the list above? To add to this discussion, post your comment to this article.