This is a guest article from Simon Harris from Logical Model.
Long ago I found being delegated to was often a confusing process. Later I found guidance in a number of sources on how to delegate clearly. It turned out that if you take the right factors into account it can be quite easy to delegate effectively (in my team’s opinions as well as mine!). It is that tangle of right factors that makes it easy to get delegation wrong too.
Let’s explore then “What are the keys to getting it right”?
First, understand that delegation is a dialogue. A two-way transaction.
Second, that the content of the transaction changes with the combined competency and character of the people involved.
Third, that it’s a whole conversation from initiating the delegation through to agreeing when obligations have been discharged.
This combination of factors leads to some situational variations in the dialogues.
How To Delegate 101: From Both Sides of the ‘Transaction’
As delegator you have a duty to:
- Be clear about what you want – there’s more details on the pitfalls below
- Provide the resources, support and environment for the delegatee’s success
- Make the reporting and escalation path clear
- Be responsive to reports and escalations.
As recipient of the delegation you have a duty to:
- Confirm the performance criteria are mutually understood and agreed
- Provide the skill and will to turn the resources into the required result – more below
- Know how to assess status, report it and escalate issues appropriately
The above is nice for a text book. The real world always gets in the way. Understanding how to handle the variations is easier when we have a default approach for the ideal situation.
The above defines the duties; below I’ll add each party’s rights and the ‘how to’ steps. Mostly but not entirely by remaining within the cosy world of the ideal.
Be Clear on Requirements and Confirm Performance Criteria
Requirements matched to agreed performance measurement criteria are a pair (or the same thing stated twice). They are the opposite ends of one conversation.
Life is easier when the requirements are complete, clear, realistic and stable from before delegation starts. Life doesn’t always match the ideal though. When requirements are evolving or unclear then that affects the delivery life-cycle best suited to needs. Delivery life-cycles are a bit beyond our scope here, but I’ll touch on them below to give at least enough to allow you to look for relevant guidance.
The exchange of requirement and measurement criteria starts with the delegator who must be able to state the end result that they require. There are two ways to define what is to be done:
- Either: State what you want achieved (Output or deliverable or product etc) in which case omit instruction about actions to be taken unless they are constraint. You don’t have to know how to achieve the result in this case but your delegatee does have to know (or discover) how to achieve it.
- Or: State what you want done (behaviour, action or service etc) in which case recognise that the end of the delegation is the actions taken whether they yield the result you imagined or not! In this case you do have to be an expert but your delegatee can be a complete beginner.
It is best not to mix the two approaches. Specifying results or specifying actions works best. However, blurring of boundaries is more real-world in most circumstances. We will address it below.
Understand the Context for Success
When delegating well – whichever party is the expert (and it could be both or neither) – we must consider and account for the interaction of dependant factors.
For example, by considering if duration is fixed for a variable scope and skill level, or if duration is variable based on fixed scope and capability (this choice is the core of the difference between different delivery life-cycles).