Delegating in a way that doesn't suck

I suspect that most people who've been working in tech long enough have been told at some point that they need to "learn to delegate." This phrase is frustrating - why do people say this like it's learnable but refuse to teach it? Why can nobody explain the desired outcomes other than "you aren't doing the work"? And why is it that so much of the delegation that we see day to day, that we might use as a pattern for our interactions with others, just out-right sucks?

I can't answer those questions, but I can talk about what I'm looking to do when I delegate, and break down why I put so much value on doing this well. From here on out, I may refer to the person you're delegating to as the doer; without them, the thing is not done.

Make sure it's suitable

Before we get started, let's make sure the task is a good candidate for delegating. You can't be uniquely positioned to do the work, and it has to be large enough to justify the context cost of handing it off to someone. Most 30 minute tasks aren't worth delegating unless they can be negotiated (more on this later) quickly during the course of an existing process or meeting. Standup, sprint planning / retro, and ops meetings form a time where delegation of small tasks can be worthwhile. Since everyone present has the context provided by the meeting, the cost of handing off a task should be low.

So your task is something others can do and it's large enough to justify off-loading. Great!

You don't know why you're delegating

The first step is to know why you're delegating. Your initial response will almost certainly be some variation of "I'm too busy" because of how common it is to hear this, but let's take a moment and be very honest with ourselves. This list includes many questions to prompt your thinking, but don't feel compelled to "answer" these questions by immediately or radically changing tools or process. The goal is to reflect.

Is the other work you have work that you consider more important? If so, does this task need done now? Can you file it in your bug tracker and deal with it later?
- It may be that the work requires context that's ephemeral; a lot of ops work falls into this category. Logs might have a short retention period, or the specific details of an incident aren't captured anywhere but in a person's recollection. If your ops loop (from cutting a ticket to triage and assignment to completion) is either long or painful, you'll find you have more of these.
- You may be working on something that requires large amounts of concentration, and cannot afford the distraction of this task. Is this the nature of the work, or have you structured it in a way that it is not easily put down and picked back up? Does your team distribute these interruptions in an equitable fashion?
- It may be that this work is not career-advancing for you, and you struggle to consider it important because of that. Is it career-advancing for someone else? See if they'll be your doer. If it isn't career-advancing for anyone, does your team have a standard way of handling that?
- You may not consider this work important because it's strictly to prove something to satisfy some stakeholder. Is satisfying that stakeholder part of your job? Is it important? In the future, can you provide ways that stakeholder can prove this to themselves? Is there someone you can appeal to that can prove this on your behalf with the tools or documentation you've built? Or does your relationship to this stakeholder need re-negotiated entirely?
Is there a gap in your skillset? Should you fix it, or accept it? It's okay to accept there are things you will always need help with, but if this skill would be useful for you to have, consider joining the doer and taking notes or creating a runbook instead of delegating.
- As an aside, I firmly believe that managers of technical people should be able to pull metrics, analytics, and logs themselves. If your job is to speak to the health or status of your service or your progress on a deliverable, it is irresponsible to require another person.
Is it not your job? If a task falls clearly outside your responsibility, but the person responsible for it is near, this is a great opportunity for delegating. However, follow the rest of the post's advice; if you are thinking of it as delegating, there is already some expectation or process that has, hopefully temporarily, made you the owner of the task.

This is a (non-adversarial) negotiation

This is important - if the task you're delegating is fully non-negotiable, you are doing this whole process wrong, and this is doubly true if you have organizational power over the doer. Non-negotiated delegation is a great way to burn trust, frustrate your coworkers, and build a culture of defensiveness. You should expect and actively encourage the doer to consider things like:

Is there a deadline on this? Is it firm or flexible, and near or far?
Will this prevent the doer from doing some other thing they've committed to?
Is someone else better situated to do this work? Is there an opportunity to pair program or cross-train so more people are comfortable with this sort of task?
Is there an escape hatch or process better suited to this than delegation?
- Managers often build a reputation for ambushing people in 1-on-1 contexts with large amounts of urgent work. Do not be this manager. Pre-empt hard stakeholder questions about deliverables and ops, bargain for time when committing to things so you can control the flow of incoming work, say no when you can, and generally aim to do the work of task assignment in a procedural, documented way, in plain sight of your team.
Does the doer have the context they need for this task? Specifically why and for whom?

Work to meet them in the middle whenever possible. A lower-ambiguity task being asked for in a way where the doer can set the parameters is a task they'll dread less, start sooner, and finish faster.

Delegate with empathy

Some of you will be delegating to your peers; some of you will be delegating to people who report to you (and who you have organizational power over). Sometimes you'll be delegating within your organization; other times, you will be attempting to delegate outside it. These relationships will determine how you frame these conversations, but an important through-line is empathy.

The doer is busy. They know they're busy. You need to start by empathizing with that, but further, you need to know what motivates them, what pressures they're under, what concessions you can easily make for them, and if this task doesn't get done, if they suffer, benefit, or are wholly unaffected. With those pieces, you should be able to pitch the work to them in an entirely honest and earnest way. If you'd like to see what I mean in practice, feel free to flip to the bottom of the post.

Judiciousness, advantage, and autonomy

Think of the time it takes you, personally, to delegate one task to one person. What's that figure? Think about it for a moment.

Outside of a meeting intended for work assignment, it usually takes me 5 to 30 minutes. This covers identifying that the task should be delegated, thinking of which doer(s) would be a good fit, thinking about how to bring it up to them, then doing so and negotiating with them.

Does that sound like far too long? Possibly - and this cost is a large part of why I don't aim to delegate sub-30-minute tasks outside of existing process. But I'm hoping to get three things from this:

Controlling the rate of incoming, out-of-band requests. If I become the limiting factor on delegation, then tasks have to come in through standard channels (tickets, triage, roadmapping). My team is already fully saturated on work, and it's important work. A team that takes work in through routine, non-urgent processes is typically faster, more productive, and more focused.
Handing off sufficient context and information that the doer is faster and makes better decisions than if I had simply funneled the requester to them. I think of this as delegating with advantage; my goal is for the time I spend handing a task off to reduce the time it takes to complete by that much or more, and to increase the odds of good outcomes. Every stakeholder with a request will insist it's the most important thing, and that there are no possible concessions to what they want. By establishing why and for whom this task exists, you arm the doer to make good decisions.
Delegating in a high-context, personal way empowers the doer to make decisions without you. I hope for this to feel empowering and lead to doers feeling comfortable acting with high autonomy.

Practical delegation

Urgent bug in a feature release candidate as a manager

I'm planning on releasing a feature in a little over a week, but a stakeholder identified an important bug today. I verified the bug myself because the stakeholder has mis-reported before, and I would like to get ahead of this discussion reaching further if there is not a bug. In doing so, I learn some important context. I reached out to the on-call, since this is work they would typically do; while negotiating, they mention that they're underwater on patching tasks that are also time critical, but that they have a planned release on Thursday that they're budgeting time for, and could easily fold a hotfix into it. It's near the end of the work-day on Monday, and I decide the best doer to approach is the developer who built the feature. Unfortunately, they work in another time-zone, and it's past work hours for them. Confident (from the context of investigating) that the bug is unlikely to take longer than a day to fix, I draft a scheduled Slack message, preferring an informal medium that won't alert them immediately.

[Scheduled message for tomorrow, 9am doer's time]

Hey!

I was just talking to $STAKEHOLDER, and they let me know that they found a bug in the $FEATURE rolling out week after next. It looks like the UI incorrectly persists some state if the user selects the $FEATURE panel and fills out any fields, and this causes validation errors pre-form submission if they de-enable $FEATURE.

Could you take a look and put up a PR? I don't expect it to take longer than a day or so, and $ONCALL is holding the Thursday deployment for a hotfix. Let me know if it looks like more work than expected, if this conflicts with other tasks, or if anyone reaches out directly and seems particularly concerned.

Thanks!

Why's this good?

I know this person has a strong sense of pride in their work; I don't need to pitch fixing the bug.
I learned a reasonable bit about the bug and ensured the context (and requester) was passed on.
This establishes the distinctly medium urgency of the task. Less than a day of work, able to be done over the next 3 days, is not urgent enough to take an action that might send them a push notification after hours. It is, however, urgent enough that I should schedule it now, and not rely on remembering it tomorrow.
Since this developer reports to me, and is less likely to bring up reasons this is difficult for them unprompted, I make sure they know that they can bring up concerns.
I'm not worried about this, but, knowing that this could snowball into a headache, I leave them a prompt to let me know if anyone reaches out to them about it so I can make sure they understand the release plan.

I'm working on an upcoming feature, and I scoped and estimated some time ago. I'm a little behind my estimates, and worried about delivery. I talked to my manager who recommended I reach out to a doer, a peer of mine with the same job title, and delegate. I'm not particularly comfortable with this, especially since the current tasks are routine and, frankly, shit-work. I decide to send a Slack message, preferring an informal medium and the ability to put my thoughts together coherently ahead of time.

[Slack message]

Hey - was just talking to $MANAGER about $FEATURE.

I'm behind my estimates and $MANAGER recommended I reach out to you and ask if you could chip in for about two weeks to close out TASK-129 and TASK-142. They should be easily worked in parallel with my tickets, and the feature's already merged to main and behind the feature flag $FEATURE. If you have higher priority tasks, let $MANAGER know, and we'll figure something else out. Just message me if you have questions about the feature or tickets!

Oh, and if you're still free to help me out after these two, TASK-144 is an interesting distributed systems problem. If you're interested, I can clean the ticket description up and hand it off anytime!

So what about this?

I know this person likes being helpful and also is looking for promotable work that demonstrates they can reason with and build distributed systems. The pitch is for help, and for a good (promotable, fun) work item once the project is on track again.
I make it clear how the request came to the doer: I asked their manager, and they balanced the importance of current work items.
I present an escape hatch: the doer is invited to tell their manager if they think this is a bad decision.
I give enough context that the doer could get started immediately, with relatively low starting ambiguity. The docs are in the tickets named, the state of the work is clear, the feature flag is included, and it's stated that there won't be collisions.

Satisfying a shareholder expectation as a manager

An external team watches a particular metric my (and similar) services emit. It's a very rough proxy for health, but not a good one, and my team has built an ops process on better health indicators. Regardless, they reach out every now and then because they're concerned about the metric they're watching, and want an explanation for it. I am busy with other things, and want to delegate this. One of the more junior members of the team is currently onboarding to our oncall process. After a meeting, I snag them for a short conversation.

[Conversation]

Hey, there's a team that's chartered with ensuring high service availability, and they're asking for us to investigate an issue that they saw in a weekly ops meeting today. I think it's a good opportunity for you to practice your ops skills in a low pressure situation; do you think you could fit it in today?

So, normally we'd have an alarm and a high-severity ticket for an ops incident, but the metric they're watching is one that we typically don't alarm on. We've asked them to change metrics, but they're uninterested.

I strongly suspect there's nothing wrong, but we do need to investigate these. You'll want to make sure that our metrics (and their corresponding alarms) looked good during that interval in case any are misconfigured, and then confirm that the root cause is the same as the usual issue that caused us to abandon this metric. There's a runbook with examples, the $ONCALL can help you find it and with any questions you have during the log dive. Oh, and please send it to me when you're done!

This time:

I pitch it as a learning opportunity - it is!
I make sure the doer understands why this doesn't follow our standard flow. The historical context that we went down our own path and have our own alarms is important.
There's little ambiguity about where to start - there's a runbook, and someone to ask.
Because the doer is relatively new to this, I redirect them back to me so I can confirm any findings. I would often point a more experienced doer at the stakeholder directly.

In conclusion...

May this prompt you to think deeper, and, hopefully, serve as the pattern for delegation that I wished I had had when I was first told to "learn to delegate."