How to Delegate Effectively by Luca Rossi
How to Delegate Effectively đ€ - by Luca Rossi #
Excerpt #
Practical advice to do it well.
There is a saying about management that goes: just hire the best people and get out of the way.
But get out of what, exactly?
The problem with such advice is that it assumes that delegation is binary: you either let people do the whole thing, or you will step onto their toes and prevent them from reaching their full potential.
The real world is, of course, more nuanced than this.
The best managers I know donât simply choose to delegate something: they design how delegation works like they would with a process, or a system.
Delegation is often portrayed as a simple choice, while it is, in fact, a skill. And a tough one.
There is no standard playbook for delegating stuff, because each situation is unique, based on project and people:
đš Project â each project has peculiar goals, constraints, and requirements.
đâïž People â each person has their own set of skills, strengths, and weaknesses.
This article wants to be a primer on how to delegate tasks effectively.
As with many management topics, this is part science, part art. The goal of this piece is to illustrate solid principles and techniques, to help you find your own style.
We will cover:
đȘŽ Benefits of delegation â why you should replace yourself continuously.
đ What you should delegate â spoiler: itâs more than you think.
đ€Â How to delegate effectively â the three key elements.
âĄïž How to get started â a simple process to get the ball rolling.
đĄÂ Tips and mental models â memorable ideas and techniques you can use.
Letâs go!
Hey đ this is Luca! Welcome to a new âšÂ weekly edition ⚠of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
To receive all the full articles and support Refactoring, consider subscribing đ
Become a better tech leader today âš
You can also learn more about the benefits of a paid plan.
Without delegation, teams simply cannot grow their output â both in quantity and quality.
Delegation enables the distribution of tasks across more people. When you hire and onboard someone, you delegate tasks to them in order to:
invest more time/skills on such tasks, and
free up someone elseâs time, to be spent on something else
Without this, you literally cannot scale.
Delegation doesnât only increase output, it also generates more value out of people, both for delegators and delegates.
Delegators â optimize the use of their time, routing it to tasks where they can bring the most value.
Delegates â grow professionally by taking on challenging tasks. Delegation is a form of sponsorship, which is a key engine for growth.
One of the most popular approaches to delegation is the Eisenhower matrix, which buckets your tasks into four quadrants, based on two coordinates: urgency and importance.
The matrix advices to address tasks in various ways based on the quadrant they are in, and, in particular, it suggests delegating those that are urgent + not important.
[
The original Eisenhower matrix â not always a realistic approach.
Now, while such advice has merits, personally I have found it hard to follow in real life, for two reasons:
Urgent tasks â are often hard to delegate. Delegation is a long-term play; in the short-term it may require more time/effort than doing the thing yourself.
Non-important tasks â are ok, but they are often trivial, so if you only delegate those, you are limiting peopleâs growth. It doesnât help that non-important tasks are also often small, which makes the ROI of delegation dubious.
Emanuele Blanco, Director of Engineering at Wise, weighed in on this:
One framework which helped me in deciding what to delegate is the Eisenhower Matrix - with a catch that I reflect a bit on what’s “less important” and whether that really needs to be done, or not. Otherwise â especially if you delegate to people who report to you â you risk to delegate mostly mundane tasks, which can be demotivating for the folks on the receiving side.
Hovhannes Guylan, Senior EM at Avantida by e2open, also adds:
When a task takes you up to 5 minutes to handle by yourself, it’s challenging to build the habit of involving other people or passing it to them. In the short-term, it will take others several hours, and quality of work will be lower than what a more experienced person can do.
So, I feel like Eisenhower Matrix is just tactical advice â incomplete at best.
Instead, there are three angles I use to look at things from a more strategic perspective. Ask yourself these questions:
đ Unique value â Where is your time spent best? What is the unique value you bring to the table? Are you spending enough time on it?
đ Skills â Are there people better equipped than you at handling some of your tasks?
đ± Growth â Are there people who are eager to learn how to do some of the things you do?
My rule of thumb is: if at least two out of these three items drive you away from a task, you should probably delegate it.
As you see, these have nothing to do with urgency / importance â but that doesnât mean those have no effect on delegation. In fact, I have found that you can draw a path on the Eisenhower matrix, that goes from the easiest + least valuable to delegate, to the hardest + most valuable.
[
The âpath of enlightenmentâ of delegation
đ„ Not urgent + not important â despite what the matrix says, you canât always delete these. Conversely, they are the safest and easiest to delegate, because of little pressure on timing and output.
đ„ Not important + urgent â you need some structure already in place to delegate these in a timely fashion, but you can still do so with little expectations on quality.
đ„ Important + not urgent â the heart of good delegation. You will establish what success looks like, how communication happens (more on that later) and who needs to be involved.
đ Important + urgent â the apex of delegation. When you are able to delegate these safely, you know you made it.
At this point you may also ask the opposite question: is there something you should never delegate?
My answer is no.
I believe the healthiest mindset for a professional in a growing team is to replace yourself continuously â and to be skeptical of things that you can only do yourself.
This stands true whether you are a manager or an IC.
As a manager â your output is the output of your team. But such output being equal, probably the less you work you do the better you are doing!
As an IC â you have less access to delegation, but you can still look to remove work via more software, automation, and processes.
In a way, good delegation is like writing good software. You take something you know well and communicate it in a way that is clear, unambiguous, and effective for someone else to execute.
When this someone else is a person â not a computer â there are three main things you should nail: purpose, outcome, and communication.
Letâs see all three.
Purpose means: why we are doing this.
This is incredibly important for motivation (see Drive below đ), but it also helps to get better results. In fact, when people are aligned on purpose, they take more initiative, propose alternative routes, and itâs easier for them to have more impact.
This is especially important when you are delegating mundane tasks, as Emanuele points out:
It’s important to set the Purpose angle right:
Why this needs to be done?
What may potentially happen if this doesn’t happen?
How does this help us in achieving our long term goals?
In my experience, spending some time in making sure people are aligned and understand the reasons behind what they do goes a long way â even when they have to perform (like all of us, sometimes!) less exciting tasks.
You need to describe the outcome you want for this project. In particular, you need to explain what success looks like. Sometimes it is easier to do so via inversion, by listing all the ways something would fail instead.
You should not, however, turn this into a step-by-step guide.
Itâs a fine line, but you should focus on the what, rather than the how, to create space for people to develop their own solutions.
Focus on what you want to achieve, rather than how you would do it.
This is where you explain how the person should interact with you.
Thatâs because, again, delegation is not binary, and for any given task you may hand off only a part of what needs to be done.
This is especially true for decision making. Based on the kind of initiative you expect from the delegate, there might be various levels:
Delegate comes up with a short list of solutions â and you decide the best.
Delegate comes up with a short list of solutions and suggests the best one â and you sign it off.
Delegate decides what the best solution is and goes for it autonomously.
In my experience, you can and should always go for at least (2).
In any case, you should state in advance how the communication should flow between you and the delegate, and how you expect to be involved (and not to be).
A useful tool to visualize the relationship between stakeholders is the RACI Matrix (or RACI chain). This framework considers four major types of responsibilities for a given task:
đšÂ Responsible â those who actually do the job. There must be at least one responsible person for each task.
đ Accountable â those who ultimately sign off on the job and are answerable for it. They typically provide requirements and do the final review. There is at most one accountable person for each task.
đ€Â Consulted â those whose opinions are sought but do not work directly on the job. They might be domain experts or customers of the product.
đŁÂ Informed â those who are kept up-to-date on the status of the job. Communication with them is one-way, and might happen only at the completion of the task.
What kind of stakeholder will you be for the task you are delegating?
[
More ideas about structuring communication in a team đ
Based on this, Ben Chiverton, Director of Engineering at Calastone, designed 10 levels of delegation and makes them explicit for each task đ
When I started to reflect on how effectively I was delegating ~1 year ago (hint - I wasn’t very good!), I found the âlevels of delegationâ below a good benchmark.
Your involvement > their freedom
Wait to be told, do exactly as I say, follow these instructions precisely.
Look into this and tell me the situation, I’ll decide.
Look into this and tell me the situation. Decide together.
Tell me the situation and what you need from me. Decide together.
Give me your analysis. I’ll say if you can go ahead.
Your involvement < their freedom
Decide and let me know. Wait for my go ahead.
Decide and let me know, go ahead unless I say not to.
Decide and take action, let me know what you did and what happened.
Decide and take action, need not check back with me.
Decide and manage this situation. It’s your responsibility now.
Finally, even if you donât want to be prescriptive with instructions, you can still be helpful by sharing more context about the task at hand.
Lara Hogan, executive coach, uses these three questions to come up with useful info:
What big lessons have you learned from doing this type of project in the past?
What interested parties, or people with helpful info, should your teammate be sure to talk to?
What are the big, but unobvious, pitfalls to avoid?
If you feel like you could delegate something, but you are not sure where to start, it is useful to consider that delegation is made of two separate things:
Documenting what needs to be done
Managing the relationship with the person who does it
When you unbundle these, things become a lot less scary â and here is the good news: doing (1) is easy, and it is pretty helpful even without (2).
Basically, you can delegate things to yourself.
Write down instructions for your tasks assuming you totally forgot how to do them. For many of those, this may not be far from the truth â think of reports you create on a monthly basis, or recurring hiring routines.
Such instructions are often called SOPs ( Standard Operating Procedures) and there is a large body of literature on how to create them well.
You can write them in prose, or, even more easily, record the process with Loom or Scribe.
Having SOPs ready makes delegation 10x easier. You should not simply assign them to someone else, as they are too prescriptive, but you can use them as a starting point to discuss the task at hand, collect suggestions, and eventually let the new assignee come up with their own process.
A lot of research went into this article. Here are three more ideas and resources that helped shape my thoughts:
Tom Sharp, professional coach, shared this awesome delegation tactic in the Refactoring community, taken from his personal experience.
I quote him đ
Many years ago, I realized that I was answering too many emails from my own team. And that I was typing too many words per answer.
I figured that my team could not grow any further, because I just couldn’t handle more than 70 emails per day from them. It took too much of my time.
That’s when I came up with the idea of Binary Emails. I just told them to not email me any longer, unless it was a Binary Email.
What I didn’t realize in the beginning was that this was going to be a very effective way to upgrade my team â a lot đ Everything changed from that simple tip.
Two years later I told them that they couldn’t email me anymore at all. I wanted them to collect all questions about practical stuff (planning, finances, details) to discuss with me on Monday morning, when everybody that reported to me got 20 minutes of my time.
I was so happy at lunch every Monday, because all the details were out of the way and I could focus on the creative, interesting stuff. Together with my team, we still worked together. They just couldn’t bring anything practical to the table apart from our Monday morning meeting.
Oh, and the most important thing: during those practical meetings, I still wanted to hear mostly Binary Questions. This is the problem. This is my proposal. Is that okay?
My team leaders still have those practical meetings with me, every three weeks or so. And they still ask Binary Questions. Works great!
This classic article by HBR explores delegation by reflecting on the various types of management time and how you can optimize them.
As a manager, having the monkey on your back is a metaphor for having the initiative on yourself. You are the one who has to take the next step â the ball is in your court.
You should minimize the time monkeys are on your back, and figure out how to return them asap to your reports.
I loved this article by Lara Hogan. It is a practical, but thorough take on good delegation. It also includes a useful Project Delegation Template.
The template condenses the heart of delegation into three areas you should cover, by using these prompts:
I will support you byâŠ
You should reach out to me whenâŠ
This will be a success whenâŠ
Thatâs it for today! You will also find this and the attached resources in the Communication & Stakeholders topic in the Refactoring Library.
Go to the Refactoring Library đïž
Check out this video to see how the Library works.
This article couldnât be possible without the great conversations that have happened in the community. I love sharing the upcoming articles in advance and bouncing ideas off with 400+ tech leaders!
[
It is the best part of Refactoring â you should join it if you havenât already.
Check out the welcome video to learn more.
See you next week đ
Sincerely,
Luca