FREE online courses on The Art of Delegation - Basics of Delegating - Basics of Delegating

 

Basics of Delegating

 

The hallmark of good supervision is effective delegation. Delegation is when supervisors give responsibility and authority to subordinates to complete a task. Effective delegation develops people who are ultimately more fulfilled and productive. Managers become more fulfilled and productive themselves as they learn to count on their staffs and are freed up to attend to more strategic issues.

 

Delegation is often very difficult for new supervisors, particularly if they have had to scramble to start the nonprofit or start a major new service themselves. Many managers want to remain comfortable, making the same decisions they have always made. They believe they can do a better job themselves. They don't want to risk losing any of their power and stature (ironically, they do lose these if they don't learn to delegate effectively). Often, they don't want to risk giving authority to subordinates in case they fail and impair the organization.

 

Objective

 

The objective of delegation is to get the job done by someone else. Not just the simple tasks of reading instructions and turning a lever, but also the decision making and changes which depend upon new information. With delegation, your staff has the authority to react to situations without referring back to you.

 

If you tell the janitor to empty the bins on Tuesdays and Fridays, the bins will be emptied on Tuesdays and Fridays. If the bins overflow on Wednesday, they will be emptied on Friday. If instead you said to empty the bins as often as necessary, the janitor would decide how often and adapt to special circumstances. You might suggest a regular schedule (teach the janitor a little personal time management), but by leaving the decision up to the janitor you will apply his/her local knowledge to the problem. Consider this frankly: do you want to be an expert on bin emptying, can you construct an instruction to cover all possible contingencies? If not, delegate to someone who gets paid for it.

 

To enable someone else to do the job for you, you must ensure that:

 

• they know what you want
• they have the authority to achieve it
• they know how to do it.

 

These all depend upon communicating clearly the nature of the task, the extent of their discretion, and the sources of relevant information and knowledge.

 

Information

 

Such a system can only operate successfully if the decision-makers (your staff) have full and rapid access to the relevant information. This means that you must establish a system to enable the flow of information. This must at least include regular exchanges between your staff so that each is aware of what the others are doing. It should also include briefings by you on the information which you have received in your role as manager; since if you need to know this information to do your job, your staff will need to know also if they are to do your (delegated) job for you.

 

One of the main claims being made for computerized information distribution is that it facilitates the rapid dissemination of information. Some protagonists even suggest that such systems will instigate changes in managerial power sharing rather than merely support them: that the "enknowledged" workforce will rise up, assume control and innovate spontaneously. You may not believe this vision, but you should understand the premise. If a manager restricts access to information, then only he/she is able to make decisions which rely upon that information; once that access is opened to many others, they too can make decisions - and challenge those of the manager according to additional criteria. The manager who fears this challenge will never delegate effectively; the manager who recognizes that the staff may have additional experience and knowledge (and so may enhance the decision-making process) will welcome their input; delegation ensures that the staff will practice decision-making and will feel that their views are welcome.

 

Effective control

 

One of the main phobias about delegation is that by giving others authority, a manager loses control. This need not be the case. If you train your staff to apply the same criteria as you would yourself (by example and full explanations) then they will be exercising your control on you behalf. And since they will witness many more situations over which control may be exercised (you can't be in several places at once) then that control is exercised more diversely and more rapidly than you could exercise it by yourself. In engineering terms: if maintaining control is truly your concern, then you should distribute the control mechanisms to enable parallel and autonomous processing.

 

Staggered Development

 

To understand delegation, you really have to think about people. Delegation cannot be viewed as an abstract technique, it depends upon individuals and individual needs. Let us take a lowly member of staff who has little or no knowledge about the job which needs to be done.

 

Do you say: "Peter, I want a draft tender for contract of the new Hydro Powerstation on my desk by Friday"? No. Do you say: "Peter, Jennifer used to do the tenders for me. Spend about an hour with her going over how she did them and try compiling one for the new Hydro Powerstation. She will help you for this one, but do come to me if she is busy with a client. I want a draft by Friday so that I can look over it with you"? Possibly.

 

The key is to delegate gradually. If you present someone with a task which is daunting, one with which he/she does not feel able to cope, then the task will not be done and your staff will be severely demotivated. Instead you should build-up gradually; first a small task leading to a little development, then another small task which builds upon the first; when that is achieved, add another stage; and so on. This is the difference between asking people to scale a sheer wall, and providing them with a staircase. Each task delegated should have enough complexity to stretch that member of staff - but only a little.

 

Peter needs to feel confident. He needs to believe that he will actually be able to achieve the task which has been given to him. This means that either he must have the sufficient knowledge, or he must know where to get it or where to get help. So, you must enable access to the necessary knowledge. If you hold that knowledge, make sure that Peter feels able to come to you; if someone else holds the knowledge, make sure that they are prepared for Peter to come to them. Only if Peter is sure that support is available will he feel confident enough to undertake a new job.

 

You need to feel confident in Peter: this means keeping an eye on him. It would be fatal to cast Peter adrift and expect him to make it to the shore: keep an eye on him, and a lifebelt handy. It is also a mistake to keep wandering up to Peter at odd moments and asking for progress reports: he will soon feel persecuted. Instead you must agree beforehand how often and when you actually need information and decide the reporting schedule at the onset. Peter will then expect these encounters and even feel encouraged by your continuing support; you will be able to check upon progress and even spur it on a little.

 

When you do talk to Peter about the project, you should avoid making decisions of which Peter is capable himself. The whole idea is for Peter to learn to take over and so he must be encouraged to do so. Of course, with you there to check his decisions, Peter will feel freer to do so. If Peter is wrong - tell him, and explain very carefully why. If Peter is nearly right - congratulate him, and suggest possible modifications; but, of course, leave Peter to decide. Finally, unless your solution has significant merits over Peter's, take his: it costs you little, yet rewards him much.

 

Constrained Availability

 

There is a danger with "open access" that you become too involved with the task you had hoped to delegate. One successful strategy to avoid this is to formalize the manner in which these conversation takes place. One formalism is to allow only fixed, regular encounters (except for emergencies) so that Peter has to think about issues and questions before raising them; you might even insist that he draw-up an agenda. A second formalism is to refuse to make a decision unless Peter has provided you with a clear statement of alternatives, pros and cons, and his recommendation. This is my favorite. It allows Peter to rehearse the full authority of decision making while secure in the knowledge that you will be there to check the outcome. Further, the insistence upon evaluation of alternatives promotes good decision making practices. If Peter is right, then Peter's confidence increases - if you disagree with Peter, he learns something new (provided you explain your criteria) and so his knowledge increases. Whichever way, he benefits; and the analysis is provided for you.

 

Outcomes and Failure

 

Let us consider your undoubtedly high standards. When you delegate a job, it does not have to be done as well as you could do it (given time), but only as well as necessary: never judge the outcome by what you expect you would do (it is difficult to be objective about that), but rather by fitness for purpose. When you delegate a task, agree then upon the criteria and standards by which the outcome will be judged.

 

You must enable failure. With appropriate monitoring, you should be able to catch mistakes before they are catastrophic; if not, then the failure is yours. You are the manager, you decided that Peter could cope, you gave him enough rope to hang himself, you are at fault. Now that that is cleared up, let us return to Peter. Suppose Peter gets something wrong; what do you want to happen?

 

Firstly, you want it fixed. Since Peter made the mistake, it is likely that he will need some input to develop a solution: so Peter must feel safe in approaching you with the problem. Thus you must deal primarily with the solution rather than the cause (look forward, not backwards). The most desirable outcome is that Peter provides the solution.

 

Once that is dealt with, you can analyze the cause. Do not fudge the issue; if Peter did something wrong say so, but only is very specific terms. Avoid general attacks on his parents: "were you born this stupid?", and look to the actual event or circumstance which led to the error: "you did not take account of X in your decision". Your objectives are to ensure that Peter:

 

• understands the problem
• feels confident enough to resume
• implements some procedure to prevent recurrence.

 

The safest ethos to cultivate is one where Peter actually looks for and anticipates mistakes. If you wish to promote such behavior, you should always praise Peter for his prompt and wise action in spotting and dealing with the errors rather that castigate him for causing them. Here the emphasis is placed upon checking/testing/monitoring of ideas. Thus you never criticize Peter for finding an error, only for not having safeguards in place.