Like many relatively new managers, I have trouble handing things over. Instead, I do too many things myself, or - worse yet - they are delayed. However, if a manager wants to increase his leverage, then delegation - which means not doing everything yourself - is an indispensable tool which I want to highlight a bit more. Like I said, I am not a delegation expert by experience, so I write this post as much for myself as for readers out there who might find it useful.
In the excellent classic High Output Management, former Intel president Andrew Grove defines a manager’s output as the output of his organization plus the output of the neighboring organizations under his influence. If a manager wants to increase this output, he will have to either work longer hours - which has a natural upper bound - or increase his leverage. Delegation, if done well, is one of the best ways to increase leverage and influence, which is why Grove calls delegation “an essential aspect of management”.
What to delegate?
What kind of task should we delegate? Before we try to answer this question, let us consider an important warning that Grove gives us about delegation:
Delegation [of a task] without follow-through is abdication. […] Even after you delegate it, you are still responsible for its accomplishment, and monitoring the delegated task is the only practical way for you to ensure a result.
This means, you cannot just delegate a task out of sight and forget about it. You still have the responsibility for it. Therefore, you need some way of checking if there is progress, and if the end result meets the expectations. You will be able to do this best with tasks that you know well, so you should preferably delegate those things that you are familiar with.
For example, let us assume a piece of code has to be refactored to match your standards. Because you have done it multiple times, you could very well do it yourself. Let us also assume that, at the same time, you have to come up with the next stage for your department’s organizational structure, and there are dozens of unknowns down that road, and no clear approach that guarantees success.
So, you have two things you should be doing, and the option to delegate one of them. In this situation, you should delegate the refactoring to somebody else, and do the organizational planning yourself. For the refactoring, you know what to expect, so you will be able to assess progress by reviewing code and by talking to the delegatee once in a while. You will also be able to judge the end result. For the organizational development, progress is hard to assess, and it is also not totally clear if a given end result is good or not.
I might be taking a wild guess here, but I assume most (former) software developers would prefer the refactoring task to the organizational planning task. Andy Grove writes that it goes “against your emotional grain” to delegate the refactoring task in this situation, and yet you should do it.
In his Manager’s FAQ, Henry Ward gives similar advice: “Delegate the work you want to do.” He goes on: “It is funny how managers rationalize giving employees shitty work as a benefit to them.” Of course, only delegating shitty work sets a bad example to your people and to managers in your area of influence, so don’t do it that way.
Besides it just being plain wrong, Henry gives another, very compelling reason for his (and Andy Grove’s) advice. The work you want to do is probably the work you are good at and familiar with. If you delegate this work to somebody else, what will remain for you? Right, difficult work that you are not good at and not familiar with. Sometimes, you will even have to find the work you should do next, and to find new ways of creating value for the company.
This pushes you out of your comfort zone. You will learn and grow. And exactly this is one of the best reasons for delegating: Delegate to fuel your own growth. In Henry’s words:
“You will struggle, suffer, and learn. That is where growth comes from.”
But the reward you get is not “just” your own growth. By delegating new tasks to your employees, you will see them grow and succeed, as well. This is the psychological oxygen of good coaches, so if your heart does not rejoice at this thought, then you should probably not manage people.
One last thing: To keep yourself from burning out by never doing what you love doing, keep some “nice” tasks to yourself. Don’t sacrifice all your maker time. However, don’t pick time-critical tasks or tasks where you might end up blocking your team, or becoming a bottleneck.
Who to delegate to?
When choosing somebody to delegate to, you should consider the following aspects:
- Capability: Does the person have the knowledge and skills to perform the task? If no: Can you provide short-term training? Or is the knowledge/skill gap small enough that the learning can happen while the task is being executed?
- Willingness: Can the person identify with the task? Will it be fun, challenging, and interesting for her? Does she have the self-confidence to tackle it?
- Capacity: Does the person have the time and resources to take on another task? If no: Can you redefine priorities or transfer tasks to somebody else so that there will be enough capacity?
Regarding capability: Sometimes, you will have to take a leap of faith, because you might have been working with that person only for a short time, and cannot assess all their strengths and weaknesses perfectly. However, I encourage you to take that leap of faith, and I bet you will be in for some nice surprises. With experience, you will also become better at assessing people’s talents.
The willingness to take over a new task might not always be there right away. Sure, they will do it because they can sense that you, their boss, would like them to. But you can tell they are hesitant, and not completely convinced yet. Most people are wary of change: “Hm, a new assignment… It might be a trap!” Some might simply be surprised, and don’t know how they should react: “Who, me? Really?”
Others might fear that the new assignment is too difficult for them, and that they are not ready for it yet. In those cases, provide encouragement and explain why you are convinced that this person is the right one. Emphasize the strengths you see in your employee.
The previous aspects of creating willingness were about the employee. Now, let us pay attention to the task itself. In the optimal case, the corporate goal, the manager’s goal, and the employee’s goal match, and all benefit from the delegation. For example, if the task allows the employee to get involved with a new technology or product she has been interested in, that will be a huge plus.
If you follow the advice of the “What to delegate?” section, i.e., delegate work you want to do, you should have no problems describing the task in an attractive way. Ideally, it should be challenging to your employee. This is how Marcus Buckingham puts it in The One Thing You Need to Know:
“Having detailed the outcomes you want, tell him how hard it’s going to be to achieve them. Emphasize their scope, their complexity, their “no one has ever pulled this off before” quality. Do whatever you can to get his attention and make him take his challenge seriously.”
In addition to the aspect of challenge, do not forget to emphasize how important this task is to you. Even if the task itself is unpleasant, people will do it a lot more readily if they know that there is a purpose to it: “Untangling this part of the code will finally allow us to extract it into its own package, and reuse it in other projects. This will unblock several other teams, so I really need this finally done.” Sentences like these can do a lot for an employee’s motivation.
How to delegate?
So, you have chosen a task, and you have chosen a person to delegate to. What is next? First of all, there is an important requirement that, again, Andy Grove teaches us: You and your employee must have the same information background, and the same ideas about how to operate. If this is not the case, you will have to prescribe the exact steps, get deeply involved, and supervise closely. Meddling and micromanagement will be the result. Always keep in mind: It is the manager’s responsibility to reach the goal, but it is the employee’s responsibility to figure out the steps that lead to the goal.
Micromanagement will be bad for both persons involved. For you, because it will not save you any time, and your managerial leverage will be accordingly low. And for your employee, because she will feel disempowered and frustrated by your constant intervening. Therefore, you should be sure that there is a common understanding of the context and the high-level way and culture of solving problems. You can use questions to check for this understanding.
Also, if you are delegating something you would rather do yourself, you have to be very conscious about this. Force yourself to stay out of the execution, unless you can see things moving into a dangerous direction. As mentioned above, meddling will lead to low managerial leverage and to frustration. Your employee might not take the exact sequence of steps you would take. In that case, bite your tongue. You can still discuss alternative strategies in a review meeting.
Being able to notice dangerous developments requires monitoring. As the delegator, it is your duty to monitor the execution. Remember Andy Grove’s quote from above: “Monitoring the delegated task is the only practical way for you to ensure a result.” Moreover, monitoring is not meddling, but necessary.
It comes in various forms. If you delegate a coding task, you can review the checked-in code every day, or let your developer walk you through his ideas. If you delegate an organizational task, a regular status conversation is probably a good idea. Agree on the mode and the frequency of these status checks at the very start, so that the employee knows what to expect. Try to be as little directive as possible, while also offering support.
If you have the feeling that your employee is forgetting something, ask questions accordingly. For example, if she should organize a conference and you have not heard anything about the conference Web site yet, then ask a simple question like: “What are your plans on the conference Web site?” It’s not rocket science to come up with this question, but you have to ask it. Otherwise, if the Web site is forgotten about, it will be your fault as much as hers.
It’s done! Your employee has completed the task, and the goal has - hopefully - been reached. Now, what remains is to provide feedback. Your employee will want to know how she did, and if she met your expectations.
In any case, thank your employee for her work. If you are happy with the outcome, give praise. Buckingham gives some interesting advice on the kind of praise:
“Should you praise him for his hard work or for his unique strengths? Always the latter. Tell him he succeeded because his strengths carried the day. Even if other, external factors played a significant role in his success, still explain his success as a function of his strengths. It doesn’t matter if this assessment is, in part, an illusion, because it is an illusion that will serve to create a better reality.”
This part of the delegation process especially is about the personal growth of the employee. Being aware of one’s strengths is an important part of any personal growth process.
On the other hand, if things did not go so well, discuss the reasons why that was. Give feedback on what should be done differently next time. In both cases - no matter if success or failure - talking about alternative approaches can further sharpen the understanding of the task.
Delegation, if done properly, is a wonderful thing. You free up some of your own time. You increase your managerial leverage. You grow, because you have to push yourself to find new ways to create value. Your employee grows, because she gets to work on a new kind of challenge and can prove herself. Therefore: Stop doing everything yourself. Let go of some control, and watch magic happen!
This blog post took me about 5 hours of work, including image research.