A short guide on delegation
Delegation is a quite important task in the life of a leader. In this article, we will present how to carry out delegation and which levels it has.
The delegation itself
We call ‘delegation’ the activity whereby a task, a group of tasks, or the role of making a technical, operative or administrative decision is given to another person or party – purposely, in an organized way.
The topic of delegation is not strictly related to agility, but it can be a significant topic in an already agile environment or in an environment moving into that direction. The inherent challenges are apparent as well. In most organisations one of the awaited benefits of agility is an increased level of independence for development teams, meaning they are self-organising, capable of taking more responsibility and can take over certain decisions from management. This is a realistic expectation, but it must be made clear that just as any kind of change, this is also a progression which needs to be handled consciously.
The trap of two-level delegation
The biggest mistake we have encountered in this area is that some leaders view delegation as a binary option. “It is either my decision or the team’s”. They don’t think about it in terms of a transition.
So the leader steps up to the team and proudly presents that from this point on, this is their responsibility, they are free to make bold decisions. But no bold decisions arise from the team. Instead of being motivated and enjoying their newly gained empowerment, they feel insecure and try to push the decision back to management.
There can be multiple causes for lack of success, such as
• the immaturity of the team: they don’t know how to handle the new situation;
• a lack of information: they are capable of making the decision, but not all conditions are known to them;
• previous bad experience: this can be a series of past decisions which lead to problems or past cases of proposals which were rejected or even worse, ignored. Maybe for valid reasons, but if improperly communicated, it could have left a lasting bad impact on the team.
We see the solution in:
• considering delegation as a process
• assessing the adequate level in the given situation
• working actively in strengthening the organisation according to the level of delegation, in order to enable the delegate to complete the task
For this, we usually recommend and use the so called Delegation Board, Delegation Poker techniques, which are well-known as part of Management 3.0.
The material behind the link is very clear and easy to use, but we summarize the levels here as well for easier understanding:
Tell: The decision is made by the leader who informs the team of his/her conclusion.
Sell: The decision is made by the leader, who “sells” it to the team.
Consult: The decision is made by the leader, but she asks for the opinion of the team beforehand.
Agree: The decision is the result of a joint effort of the leader and the team.
Advise: The decision is made by the team, but the leader gives advice.
Inquire: The decision is made by the team and they inform the leader about the decision and their reasoning afterwards.
Delegate: The decision is made by the team and they don’t even have to inform the leader about it.
Delegation Poker cards, source:
Let’s use our own agile trainings as an example of this technique. The trainer delegates some decisions to the participants with varying levels of delegation:
• Timing of exercises: Tell. Our trainings contain exercises which have a fix place in the agenda and there are some which are decided by trainer dynamically. For both cases, the trainer is making the decision: “now we continue with an exercise”.
• Lunch time: Sell. As we have to prearrange it with the venue, it is our decision. However, at the beginning of the training we discuss it with the participants and “sell” them that the lunch break will start at noon.
• Breaks: Consult. We have an idea at what points of the training is it advisable to have breaks. We decide on the timing and length of the break by building on that knowledge but also taking the needs of the participants into consideration.
• Start of the training: Agree. If the training lasts for more than one day, we discuss the start time for the second day at the end of the first day. The duration is fix, if we start earlier, we will finish earlier. (Usually our proposed time of 9:00 to 5:00 stays.)
• Forming groups: Advise. Participants form groups during simulation games. We give some advice such as to keep the gender ratio the same for both groups, but the decision is theirs.
• Assigning roles during an exercise: Inquire. For exercises when for example appointing a Scrum Master is needed, usually the team appoints the role. However, naturally we need to know the results, as the appointed role will have different responsibilities and tasks in the exercise.
• And finally, the decision about which chair each participant sits on is completely up to the individual. This is the Delegate level.
The topic of delegation is nearly not as clear and obvious as one would expect. But with proper preparations and theoretical knowledge (for example with the help of our Advanced Scrum Master training) it is possible to create a well-defined, clear and manageable delegation culture in our organisation.