It is High Time we Finally Learn How To Delegate

One of the oldest methods to organise the division of labour is delegation. I have discussed delegation with thousands of managers. My preferred approach to inviting people to use delegation more consciously, is to let them clarify its purpose, and compare it to some of its alternatives. Delegation is a tool to commit useful contributions. A very telling alternative are instructions – including procedures, checklists, workflows etc. When asked about the advantages of delegation over instructions, I invariably get two points. First, people are more motivated when they are delegated a task. They feel ownership, a sense of responsibility, trust being given to them, and therefore self-worth. And second, they can develop their skills over time, whereas with instructions, the development stops once you know how to follow the checklist. After these two answers, the flow of suggestions usually slows down a bit. What is disconcerting about this, is one essential point: the importance of delegation in the face of today's increasing complexity is only rarely on people’s minds. 

What is the connection between delegation and the VUCA world? Let us have a look at a simple case. I have come to work with my pet monkey. Unfortunately, I am called to an important meeting, and I ask you to look after the monkey for two hours – a delegation. Let’s assume you know how to deal with monkeys, and it’s fine with you. I leave the office, and the animal is looking expetantly at you. What do you do? Do you take her outside, or stay in? If you stay in, she might get difficult to control for her need of exercise. So you take her outside. Here, many things can happen. A lorry arrives on the parking lot to deliver some goods. She gets afraid and nervous. You take her to the park instead. A group of excited small children are running around – if your monkey participates in that play, there might be some bad reactions. Therefore, you take her on the leash. Some people are walking their dogs nearby. You make sure to keep a distance. And so on…

In times of increased complexity, the advantage of delegation has an effect for the organisation as a whole. With delegation, the organisation is capable of dealing with exceptional and unpredictable cases. Contextual decisions can take place at the front.

Why is that different to instructions? Let’s have a look at instructions first. Many routine tasks, especially if they are sensitive to safety or security, are organised by instructions, and wisely so. The checklists pilots use before starting an airplane: They have just checked all these things before the last take-off two hours ago! Yes, you still follow the checklist. Or how to prepare an operating theatre for a certain type of surgery. They know that in this particular case, it is practically certain that this one instrument will not be needed! Yes, and still you are going to put it on the table, and the whole team can rely on the fact that with this type of surgery, that instrument is there. In an instruction, the executor’s obligation is to follow the instruction. If the instruction was wrong, the executor is not responsible for the bad result. This means that the capacity to deal with situations, both in choice of response, and in timeliness, lies to 100% with the instruction’s author. If a surgeon thinks that in this particular intervention, he would like to have an instrument ready which is not on the checklist, she has to tell the nurse. No nurse can be blamed for forgetting to put something on the table which was not on the checklist. What happens if we do blame them, and they need to “disobey” the checklist in order to do the job, can be seen in the case of the Cernobyl catastrophe. The checklists and procedures were so outdated that in order to operate the nuclear power plant, some of them needed to be ignored, and replaced by an experience-based local approach. The authorities back in Moscow designed a test to be run on the power plant, but the assumption of the test designers was that the reality in the power plant corresponded to the procedure they knew. A fatal misunderstanding. Instructions rely on rigidity and obedience. 

Once we move from instructions to delegation, this becomes different: Since the executor has both the responsibility for the result, and the authority to take the necessary decisions to succeed, they will put their power, knowledge, skills and common sense at the service of delivering the desired result – they will do whatever it takes to keep the monkey safe and happy. 

What you always half knew about delegation but never had the time to think through properly

At this point it is helpful to dig a bit deeper into the mechanics of delegation. There is nothing new about delegation as such, but it so happens that many people disregard these mechanics, and therefore delegate badly. As a consequence, the people on the receiving end do not like delegation, taking its bad execution for the thing itself. I would even go so far that much of today’s dislike of hierarchies actually roots in the fact that delegation is done in a faulty way. 

Most delegations happen within a chain of connected responsibilities. The person who delegates a task to us, is herself commited to a task from someone else. I have asked you to look after my monkey, because I am obliged to appear at a meeting. I have given you the task, and I no longer have it. But what about responsibility? Imagine that whilst looking after my monkey, you are called to a meeting, too, and therefore you delegate the monkey to John. You are allowed to do so, because I have not made a delegation ad personam. But now, for whatever reason, John decides to stay inside. After two hours, the monkey is very nervous, and the room is a mess. I come back, and I am not happy. Who do I complain to? Not to John, but to you, because I still hold you accountable for the task. That you have delegated its execution to someone else does not in the slightest change your obligation towards me. 

So when you delegate the task, you hand it over, and you no longer have it. But the responsibility for the result has has not been handed over, but cloned: John is responsible to you for the execution, but you are still accountable to me for the result. 

Given this situation, it is only natural that you care about the execution of your delegation. What does that mean? Think about what is happening to the monkey when John takes her outside. You know what is good for the monkey, it is only natural that you put your experience at the service of the result. The lorry comes, you open the window and remind John that the monkey is afraid, and behind the house there is a park that she usually likes. The children arrive, and you point out to him that it is better to take the monkey on the leash. The dogs arrive, and you warn him to keep a distance. You do this because you care, since you are still accountable for the result. But what happens to John? Step by step, with every intervention in the delegation, in his head the delegation transforms into an instruction. You have told him to put her on the leash? If he won’t let her off the leash for the remainder of the time, you cannot possibly blame him for that. 

Such kinds of interventions can take very subtle forms. John may ask you about how to deal with a particular problem. And since you know it well, you reply to his question. John goes off and puts your suggestion into practice, and all is well. But if the situation evolves and it is no longer sure whether your suggestion is still a good idea, he will hesitate just a bit more to deviate from what you have said, than if it had been his own idea. 

Therefore, together with the task that you delegate, you also hand over the authority to take the necessary decisions to achieve the result. At the same time, you are still fully accountable for the result – and you should keep your hands off from intervening? Truly this is a very uncomfortable situation. 

And the answer to this is: yes, it is uncomfortable. This is the price you pay for the advantage of delegation over instructions, to preserve the investment of John’s competence, creativity and wit, to deal with unexpected situations. 

The damage created by interventions is taken to the next level when we look at interventions that bypass one or several levels of hierarchy. If John is out on the parking lot, and it is me, not you, who remind, point out and warn him about the various risks, I not only destroy the delegation in John’s head and transform it into an instruction. I also damage your relationship to John. If later in the day John has an issue with the monkey, and sees both of us taking a break from our meetings, who will he talk to? Me, not you. Because he has learnt that it is me who calls the shots, me who will intervene and hold him responsible in case he does something wrong. Your authority over John is substantially broken. 

To complicate things even further, there are a few instances where it is perfectly legitimate to intervene into a delegation. The emphasis is on “legitimate”. Feeling on edge is not a legitimate reason. But legal obligations are. In additions, there are three contexts worth keeping in mind, where interventions are appropriate: 

1.     It is ok to intervene if the person is in the process of making a mistake. This is not about vague risks, or that we think our idea works better and therefore everything else is a mistake, but about an evident situation where, on stopping the execution, we can explain the consequences so that the person sees that they would have committed an error. 

2.     It is ok to intervene if their task surpasses either the competence or the authority of the person. In fact in such a case we take back the delegation. If the person deals with a client, and at one point the volume of the contract crosses the line up to which they are allowed to sign, of course we intervene. If the task looked simple, but now has become too complicated for the level of experience of the person, we take it back, and we can legitimise why. 

3.     The third reason is not always welcome, but it becomes very evident in the light of a complex environment: If a change of objectives promises a better result, it is ok to change the objectives. Take the example of a salesperson. By September a main competitor goes bankrupt, and their customers all try to find a new supplier. The salesperson may lean back and think: From now on, I will achieve my annual targets just by picking up the phone. However, if we look at it from the company’s perspective, this event has opened up a window of opportunity: There are customers out there who are very easy to convince, and for the remaining suppliers, the race is on. Once the customers are settled, we will be back to the tedious work of unsticking them from their existing contract, in order to get them to move to us. In this phase of customers on the search, the most active competitor will make a huge gain. We want people to invest as much as they can, to cancel their holidays if necessary, just this once to get as many new contracts as possible. Therefore, if we are sharp, we fundamentally increase their sales target, and we increase their bonus on the sales target exponentially. We can see with this example that there are two cornerstones of this kind of intervention. One, it must be made evident why the change is legitimate. If people think our intervention is arbitrary, we’ve destroyed the delegation, and created cynicism. Two, many systems that govern targets and bonuses, would not allow for such a change – we are back to the incompatibility of bureaucracy with a complex environment. 

Delegation and co-ordination in a self-organised environment

While delegation hits its limitations as an instrument to deal with complex environments wherever bureaucracy cuts its wings and renders it overly rigid, it can boost its ability on the other end of the spectrum. In the age of unknowable futures and emerging strategies, we can take the concept of delegation out of the hierarchical context, and use it more openly: It does not matter whether the definition of the desired result has happened top-down or bottom-up, nor whether it is of small or large granularity. A delegation is a commitment between two people to deliver a contribution, leaving adequate margin to the executor to take the necessary decisions in response to the context.

If you look at delegation this way, you get a very versatile tool. The key is that authority and responsibility is with the executing party, that’s the difference to instructions. Is the delegating party the direct line manager of the executor? Maybe, but not necessarily. Is the executor more de-central, and the delegating party more central in the organisation? Probably, but not necessarily. The only condition is that in the given form of organisation, the delegating party is actually allowed to delegate to the executor. If we are in a hierarchical organisation, the line manager needs to rely on the availability of the resources attributed to them to fulfill their task. Therefore, other people can only delegate to a person if that person’s line manager has agreed to it. If the organisation has a centre, logic demands that most delegation flows from the centre to the margin, where the execution happens. 

In this sense, delegation can happen between colleagues. In hierarchical organisations, superiors can define the space in which colleagues delegate to each other along a process. The obligation towards the superior is to act according to the defined space, while the obligation towards the colleague concerns the individual task. The most obvious examples are projects. Someone is assigned by their hierarchy to work for a project up to 30% of their time. What happens in these 30% is decided within the project management structure. A brief, or a specification passed from one colleague to the other, may be the same. The famous “internal customer” is in the better case the source of a delegation. In the worse case, it is the source of an instruction. As Dave Snowden pointed out regarding spec sheets, the lists of precise user requirements for software developments: “You make the user sign a document they don’t understand, so you can hold them responsible later if they don’t like the result.” If, instead of the spec sheet, we put delegation at the bottom of the relationship, the user enters in a dialogue about their needs in order to get a software that actually fulfills the task - the core of Agile methods. 

The concept of delegation between colleagues is the cornerstone of highly de-centralised, and dynamic organisations. A famous example is The Morning Star Company, the largest processor of tomato in the world. The company is totally self-organised, without hierarchical relations. Their network organisation is formalised in one-to-one relationships of delegation, called the Colleague Letter of Understanding, or CLOU. In essence, the CLOU includes five elements: The personal commercial mission, which defines the person’s contribution. The key activities necessary to fulfill the mission. The key measures by which the performance can be gauged. The time made available for these tasks. And the colleagues to whom the contribution is delivered, and who in consequence sign off on the CLOU from the very start.

What you get is a networked organisation. As such, the CLOU increase the capability to adapt to changing conditions, to reach out and use relevant knowledge to solve local problems. In 1990, Morning Star was able to oversee the construction of a new, 27 Million Dollar factory with a completely self-organised team of 24 people in a few months only.

In 2007, Morning Star made a big improvement when they introduced the digital CLOU, which made short term adaptions much easier. Putting the threshold as low as possible, you make sure that co-ordination actually happens with the help of the instrument, and not outside it. 

Autonomy and alignment

To summarise: Delegation is a commitment between two agents to deliver a contribution, handing responsibility for the result, and the authority to take the necessary decisions, to the executing party. As such it is a key instrument to create de-centralised autonomy. It enables an organisation to deal with exeptions and unpredictable situations. 

It may surprise to see that one of the institutions who have taken this lesson to heart is the military. A widely regarded stepping stone was the publication of the Study Power to the Edge within the Information Age Transformation Series of the Command and Control Research Program of the US Department of Defense. One of the most striking appliers of this approach was General Stanley McChrystal as head of the US Joint Forces against Al-Kaida in Iraq. He led a task force which included soldiers from the Army, Navy and Air Force, and agents of CIA, FBI, NSA and other agencies, against an extremely versatile, connected and – in terms of methods - unorthodox enemy. In such a highly complex condition, hierarchical decisions and procedures were way too slow. One of the key principles was to radically de-centralise - i.e. delegate - decisions. As soon as they did that, they realised that many of these decisions were coupled to other units. In the old system, the central command structure allowed for a co-ordination of orders and therefore actions across several units. This could happen faster and better if the de-centralised units could co-ordinate directly with the relevant counterpart. For example, someone is observing an enemy meeting point that has been raided the night before. The observer sees a car arrive, people get out, stop cold, get back in the car and speed away. The U.S. observer, 23-year old with little mission experience, contacts other operators to mobilise helicopters to intercept the car and arrest the suspects. When later the parties in the car separate, and take two different cars, the leader of the assault team orders another helicopter to follow the second car. They stop the first car, find out the people are of little importance, keep them arrested, redeploy the helicopters to arrest the person in the second car – who happens to be a senior Al Qaida member. All this within 46 minutes, and no senior officers involved. 

It is fascinating to follow McChrystal’s conclusions for senior leadership from this sort of experience. First, of course, it is a proof that the work “on the system”, to de-centralise decision-making, is adequate for the highly complex conditions, and pays off. Second, however, and in contradiction to many manager’s ignorance or fears with de-centralised organisations, there are some key tasks “in the system” which remain with central leadership. One is to facilitate strong lateral connectivity: the direct connection between units, and the creation of trust. It would not be realistic to simply expect people on the ground to find out who could be the relevant counterparts, reach out to them and form relationships which work under pressure. Therefore, it is the job of senior leadership to create occasions for this kind of connections to take place easily, and improve from there. The second task is to increase the systemic consciousness of the whole group, “the understanding of the nature of the war we are fighting”. One of the means to achieve this task was a daily, one-hour phone conference with up to 7000 participants across the globe – breaking the culture of secrecy, of passing on information on a “need to know” basis, deeply rooted in the military and secret services. What was going on during this call were not generic, top-level commands or definitions of strategy, but mostly examples and points of view from the ground. McChrystal’s job was to comment, facilitate, but most of all choose the right kind of stories to be shared. 

While this glimpse into military command draws a clear profile of the leadership tasks involved, the nature of the mission may make it a bit difficult for many of us to draw actionable conclusions for our business, or administrative contexts. This is why in my next contribution, How to Achieve Aligned Autonomy, I want to show practical methods, and business examples, of how to increase aligned autonomy in any organisation. 

This topic is part of our training on navigating complexity. Join us for the 2019 training: