Delegating should feel uncomfortable

We know delegating is important.

There are cases where delegation is easy. This isn't about these. It's about what to do when delegating is really hard. When the task is likely a stretch, and time sensitive, and important to get right.

This is scary. It's scary because you're entrusting your reputation to someone else. And you aren’t sure you trust her ability sufficiently yet.

This is why people default to doing themselves, or resort to micromanaging. But you don’t want to do that because that’s the path to mediocrity. So how do you delegate even when it hurts?

The importance of feedback-seeking

When delegating hurts, you need to build an atmosphere where the report feels comfortable seeking feedback and showing you work in progress. There is plenty of scientific evidence that reports who seek more feedback perform better and have a clearer understanding of what's expected of them

. That makes sense to me: that gnawing feeling of uncertainty associated with delegating a task dissipates quickly when I know the report will ask for feedback, will come and discuss the thornier points of the task with me.

In contrast, the times when I had the most serious doubts about a report's ability to complete a task was when I felt like the lack of trust between us meant they wouldn't seek feedback, that they'd try and solve problems by themselves, possibly going down a dangerous avenue, and I felt unable to stop that without feeling like I was micromanaging them.

What follows is a recipe I have found to be effective in delegating tasks in a way that encourages feedback seeking without micromanaging or disempowering my report.

Task setting

When you delegate a particular task, you will typically start the process off through a one-on-one meeting with your report.

By the end of the meeting, your report should:

1. believe that the task is important
2. feel confident that she can do the task and that you will support her

I try and hit the following points:

• explain to her how the task fits into the wider organisation, both to give her the context that she needs, and to highlight the importance of the task,
• make sure she understands why the task was delegated to her specifically, and why she has the skills needed for the task,
• explain that this task is important to me, so that I will spare the time needed to support her,
• encourage her to also seek support and advice with other team members if relevant,
• work with her to clarify the boundaries of the task,
• set follow-up meetings, pitching these as opportunities to discuss the task, for her to get advice, and for me to provide support, rather than as status update meetings.

Ongoing support

You need to be available to provide ongoing support and solve problems with your report. The most effective way to do this is scheduling regular meetings, typically with a high initial cadence that drops off as the task becomes better defined.

These shouldn't be treated as status update meetings, since that will feel disempowering: the report won't feel fully in charge of getting the task done. Additionally, reporting status generally doesn't lead to anything useful since it only encourages a superficial view of the situation.

Instead, these should be set up as opportunities to brainstorm potential solutions or talk through problems together. Encourage your report to bring problems or risks and discuss these. Working through particular problems builds trust, making the report more likely to be open about potential problems.

Resist the urge to give answers or direct since that will feel disempowering. Ask open-ended questions before sharing an opinion.

Besides working on problems or risks highlighted by the report, you should also use these meetings to "taste the soup"

: ask open-ended questions about specific parts of the task to get an understanding of the thinking process. I usually break these down as:

• orientation questions that aim to assess where we are now. I typically phrase these as "how is X going?"
• assessment of past work: if I know where we are, I should have a sense of what we've done already. I think about what might have been hard in getting to where we are, and ask questions about that. E.g. "It's great that we're nearly ready to start coding. How are we going to handle authentication?" or "It's great that we have a full system design. How are we going to handle cases where we have restricted network egress?". The point is emphatically not to poke holes in the report's approach, or even to get a complete understanding. It is to gain a sense of whether the report is thinking about the right things to know how close you need to pay attention.
• asking what the next steps are. By thinking about challenges that might arise next, I can ask questions that encourage thinking future problems. This allows a discussion of future problems.

Use your experience to ask the most pertinent questions. Be curious about the solution and show that you're taking a genuine interest in the work, but respect their ownership.

You should come out of these meetings with a sense for how well the task is going and thus whether the report needs more or less support. The report should come out confident that they have the ability to push this forward, with a clearer idea for how to answer specific questions. You should both have greater trust in each other.