It seems delegation is one of the things we find most difficult to master as we climb the corporate ladder. During our early careers much of our success is measured by our outputs, the things we actually produce ourselves, whether they be projects completed, academic papers published, lectures prepared and delivered or, in manufacturing, widgets produced. As we progress into management and leadership, our success is measured by the success of the group of people we manage. So why is it often so difficult to delegate responsibilities to others in our team?

One reason may be perfectionism. When we believe that no-one but we ourselves can can be trusted to do a job properly, we may be unwilling to delegate, in case things go wrong. But how will anyone else ever learn if we don’t trust them to try? That doesn’t mean we breathe down their necks and micro-manage them either. When you delegate responsibility, you must also delegate authority, but if you are to do so effectively, you must set clear guidelines and put in place clear and well understood reporting and feedback mechanisms.

Another may reason may be fear of not being seen as achieving things ourselves. However, the more strategic our role, the less we should actually be doing and the more we should be thinking ahead, planning, and supporting others in carrying out the the tasks our work group needs to complete.

Sharing power is a means of developing and motivating people. By analysing the qualities needed to bring a particular task or project to successful completion you should be able to choose an employee with the skills, strengths and interests needed to succeed. You are literally setting that person up for success, with all the benefits to their self-esteem that brings. Delegation can be a key development tool.

When you delegate, make sure that both you and the person to whom you are delegating have:

  • mutual clarity about what the project involves
  • mutual clarity about what is expected in the form of outcomes or deliverables
  • mutual clarity about the level of autonomy you are giving
  • mutual clarity about time scales and reporting mechanisms
  • mutual clarity about priorities

Bill Gates said “Develop your people to do their jobs better than you can. Transfer your skills to them. This is exciting, but it can be threatening to a manager who worries that he is training his replacement. Smart managers like to see their employees increase their responsibilities because it frees the managers to tackle new or undone tasks”

I hope you’re a smart manager. You have the future in your hands.

A slightly different angle on delegation

In this Harvard Business Review article Stephen Bungay describes the tendency of managers to do their staff’s jobs for them, a practice which can be very tempting and which is often dressed up as being helpful, or getting someone started. But think before you interfere – by doing so you risk your employee’s growth through solving their own problems and by concentrating too much on details where others have experience and expertise, you risk impairing your own top level thinking.


Memo to the Boss: Don’t Do My Job For Me!
by Stephen Bungay  |   1:00 PM February 18, 2013

In August 1942, General Montgomery arrived in North Africa to take command of the British 8th Army. Within a few days he began replacing the senior officers. One of his new corps commanders was Brian Horrocks, who had last seen action in France in 1940 as commander of an infantry battalion, after which he had been promoted quickly to leadership of a Division.

Montgomery put Horrocks in charge of stopping Rommel’s last offensive in what has become known as the Battle of Alam Halfa. The British defenses held and Rommel was forced to withdraw. Horrocks was understandably pleased with himself until a liaison officer from 8th Army headquarters brought a letter from Montgomery. It began:

“Well done — but you must remember that you are now a corps commander and not a divisional commander…”

It went on to list four or five mistakes Horrocks had made, mainly around interfering with the tasks of his subordinates. As Horrocks thought about it, he realized that Montgomery was right. So he rang him up and said, “Thank you very much.” Horrocks went on to become one of the most successful generals of the war.

Fast forward to 2012.

I was running a workshop with the executive team running the R&D function of a highly successful Danish company. They were talented and doing well, but wanted to raise their game.

We devoted one session to what they called ‘innovation briefs’. These documents define what R&D projects they want to carry out, assign responsibility for them, and give direction to the next level down: the project managers. The team had brought along a couple of real ones so that we could improve them.

The briefs had a lot of good features. They gave full reasons for embarking on the project, the user need, the value created, the fit with the portfolio, and a technical specification of the product, all on one page. The first thing that struck me though, was that the typeface was very small and there was a lot of technical detail about the end product, as if the product already existed in these executives’ minds and the job of the project team was simply to build it, rather than use their creativity to come up with an innovative design.

I kept those thoughts to myself. Instead, I kicked off by reminding everyone of Prussian Field Marshal Helmuth von Moltke’s definition of a good directive: it should tell people only what they need to know in order to fulfill the intention. ‘Suppose you were the project manager,’ I said. ‘Which elements of this document would be the most and which the least helpful in allowing you to do a great job?’

Before long there was a consensus that a lot of the detail was not very helpful. It obscured what was really important and limited creativity. There were technical problems to be solved, but the brief specified a set of solutions. What if the project team were to come up with alternatives? Were they to be rejected?

I threw in another question from the project manager’s point of view. ‘What choices do you think you will face during the project?’ I made up an example: ‘According to this, the new product has to create superior user value and be ready in 18 months. Suppose the project team were to come to you in 15 months’ time and say that they could enhance the value by a further 20%, but it would take another 6 months. What would you want them to do: create a better product or hit the deadline?’

At first they were split down the middle. After 15 minutes of arguing, the matter was resolved: they would go for hitting the deadline. The timing was critical. Someone commented that they had not been clear about that themselves before having the discussion.

It was time for a break before dinner. I promised to continue this session the following morning. When we met at the bar an hour later, three of the group were missing. They were already working on a new version. They turned up for dessert with an air of exultation.

The following morning we compared their effort with the original. The new one was a fraction of the length. Everyone preferred it, but there were some questions about the content. So we set to work. An hour or so later, it had changed again and everyone was happy with it. Someone said it was the best one they had ever produced.

It was good for two reasons: it no longer specified details that the project team could decide on for themselves during the project; and it added some additional information on issues that had needed, but not hitherto received, resolution by the executives. Like Brian Horrocks 70 years before, they had been so busy doing their subordinates’ jobs that they had not properly done their own.

It’s a mistake that’s all too common. In some companies everyone is doing the jobs of the level below. As a result no-one actually does the top job. Once you see what’s going on, fixing the problem is not difficult, though it can take some work — work well worth doing.