You're Bad at Delegating Because Your Brain Is Lying to You
Episode 21 explains how to stomp the three brain bugs that keep you doing everything yourself.
Over the 12 years I was CEO at Boomerang, my single most consistent area for improvement was delegating. When I got a 360 review from my executive coach, all my reports said I needed to delegate more. When I brought a problem to my CEO group, the group asked me why I was even working on that problem and why it hadn’t been delegated to someone else. It came up a lot.
Since delegating the role of CEO (see what I did there?), I’ve gotten a lot better about delegating work. But I still don’t delegate enough of it, and I still don’t delegate it fully enough. And I’m not alone. Research shows that the people most likely to be bad at delegating are often the most capable at doing the job themselves. So at least I had that going for me!
Research also shows that the people who are good at doing the job and push through to become good at delegating as well end up more successful. And less busy - which is sort of the point! So this episode explains the evidence behind why getting better at delegating is important, the psychology that makes it hard, and provides some tips on how to overcome that psychology.
One last thing before we jump in: just a few months ago, delegation was a skill only managers really needed to build. But now, with ubiquitous AI assistance, almost everyone can benefit from delegating something, whether to a human or to a computer. So whether you’ve been managing a team for years or you’re brand new to managing your team of computer assistants, this post is for you.
Why delegate?
As the CEO of a productivity software company, every time I thought about delegating, I found myself seeing shortcomings (or opportunities!) in our products. If scheduling meetings was taking up a lot of my time, that was an opportunity to make better meeting scheduling software. If I was spending too much time dealing with taxes, that meant I needed automation rather than upgrading our accounting firm to one that could handle more of the work. Delegating? Nah.
But even with all the best productivity tools in the world and unlimited automations, my to-do list was infinite. Even now, with less direct reports and a smaller list of responsibilities, I can always think of something else useful that I could be doing if I only had more time. So really, there’s no way to avoid handing things off, except to do less.
Even when we make that implicit choice to do less, we’re not that good at picking the right stuff to drop. Research from HBR about a decade ago estimated that knowledge workers spend about 40% of their time on discretionary, low-satisfaction work that others could do competently. Asking the participants to write down everything they did for a week, and look at it through a lens of drop/delegate/redesign, made a huge change in what each participant worked on. They saw no productivity drop, but they freed up almost one day a week, 6 hours from desk work and 2 hours of meetings, by being intentional about dropping and delegating work that they didn’t enjoy and that others could do just as well.
Getting better at delegation makes a difference at the highest levels, too. Gallup surveyed CEOs at 143 of the Inc 500 fastest-growing companies and found that companies run by CEOs with a higher self-reported ability to delegate saw three year growth rates 112 percentage points higher than those run by lower-delegation ability CEOs. When you’re already running one of the highest growth companies in the world, that extra lift is huge! To caveat it a bit, this is obviously not peer-reviewed and growth itself may have forced the CEOs to be better at delegating, but it’s pretty convincing to me either way.
So if everyone from CEOs to individual contributors can benefit from delegation, both in a personal satisfaction and in a better-outputs way, why is it so hard to delegate?
The psychology of why smart people under-delegate
The biggest obstacle to delegation is that there are a bunch of cognitive biases that make it hard for us to objectively evaluate the quality of work. When we do the work ourselves, these cognitive biases help convince us that it’s really high quality. When others do it, they work against us, making us think that exactly the same output is worse than if we’d done it ourselves.
The first bias is called the input / effort bias. Basically, we have a mental tendency to grade work by hours spent producing it, not by the actual output itself. Researchers at Wharton Business School tried giving exactly the same presentation to two different groups of people. They found that the people who were told that making the presentation required 8.5 hours of work rated it much higher than the people who were told it required a little over half an hour to prepare. The results held even though 77% of the participants said that the preparation time shouldn’t impact their evaluation of the quality of the presentation, and even when they revealed the preparation times after the watchers had already seen the talk.
When we do work ourselves, we feel every second of the time it takes to do the work. When we delegate it to someone else, we don’t. So even if the work product is exactly the same, our brains associate the quality of that work with the time we invested in it. So doing it ourselves tends to make us think the work is higher quality, even when it isn’t.
The second bias complements input/effort bias almost perfectly. The faith in supervision bias shows us that work feels higher quality the more involved we are in supervising it. In this experiment, 282 MBA students “managed” a subordinate designing a wristwatch ad. The eventual ad that the designer created in the end was identical regardless of how they were supervised. So the only thing that changed was how involved the different groups of students were in the process - some only saw the ad at the end, and others had several checkins with the designer along the way.
The more time the students spent on the ad and the more input they had during the process, the more highly they rated the final ad. They also rated their own managerial ability and the ability of the designer more highly the more involved they were with the creative process. Even though the deliverable was exactly the same, the ads they personally worked on were the ones they considered higher quality.
Finally, a third bias, the premium for control, creeps in as well. There are a number of research papers that show that we will sacrifice expected financial rewards in exchange for having more control over the process. The most famous of these studies involved participants betting on whether they would answer a question correctly or whether their randomly selected partner would. They were able to see both questions and estimate what probabilities they would assign to themselves and to their partner based on the difficulty of the question.
Based on their probability estimates, they should have bet on themselves 56% of the time, but instead they bet on themselves 65% of the time. They sacrificed between 8-15% of their earnings by choosing to bet on themselves instead of betting on someone else, and they knew they were doing it.
There’s one last factor that’s more of a how-life-works bias than a cognitive one. In general, the first time you hand off a piece of work, it genuinely does get done worse and slower than you would have done it. The person you delegate to do the work usually hasn’t had as much experience doing the task as you have, generally doesn’t yet have as much context, and doesn’t know what you’re looking for as well as you know yourself. So the initial reaction to delegating a task is often “it’s easier to do it myself” rather than waiting to see the benefits of delegation.
It’s a lot to overcome, but the right handoff technique can help.
Commander’s Intent
“Look to the military!” feels like it’s becoming a kind of weird Less Busy Lab staple. But once again, when trying to figure out the best way to delegate, large organizations that put their lives on the line have spent a lot of time thinking about this.
One of the United States Army’s studies on Intent explored a tabletop exercise with 16 company commanders. The commanders got a full briefing and a written copy of that briefing. Then, they simulated the exercise with a curveball thrown in (for example, the bridge you’re supposed to capture is blown up, or something that was supposed to take a few days only takes a couple hours) to see how they would react. Only one in three commanders made the same choices their superior officers would have made – and all of the ones who did went back to the briefing to figure out the original intent of the mission once it was clear that the initial plan needed to change.
Based on several studies, including this one, the army implemented a set of seven elements that should be communicated when delegating command of a mission. In a business context, it’s a bit heavyweight – you don’t necessarily need to communicate as much detail when you’re changing a landing page as when you’re sending troops across a river under fire. But two of these elements are critical for any form of delegation, and the other five are situationally useful.
The two critical elements to communicate when delegating anything are the mission purpose and the end state.
You’ve probably heard of the old story where an AI goes crazy making paperclips because it thinks that’s the point of its mission. Everything turns into paperclips. People do this too. If they only know exactly what they’re supposed to do, but don’t know the overall goal or where what they’re doing fits in, they will make poor decisions when they need to make them. “Oh, you just wanted enough paperclips to clip together these 1000 documents? I thought you’d want me to make millions!”
In my own professional experience, failing to fully communicate the mission purpose once burned us badly. Our homepage was getting long-in-the-tooth, and we wanted to make it look like it was built recently instead of ten years ago. We did not explicitly discuss whether or not we wanted the content to change when we delegated the project to our then-marketing head.
The project wrapped up while I was on family leave. It went through A/B testing, complete with a new design and entirely new page content. Conversion rates went up, and it got deployed for everyone.
But when I came back, the page traffic had collapsed. We were seeing less than half of the organic traffic that we’d been getting before. The new page had dramatically different headlines and no longer ranked for several high-volume, high-intent keywords that we had previously owned. We changed the headlines back, but never fully recovered the ranking.
Failing to communicate the purpose of the mission, including clearly communicating the scope, probably cost us a million dollars in revenue.
With that in mind, it’s really important to agree on what a successful outcome looks like when delegating. It’s better yet if you can make success something measurable. For example, a trucking company setting an explicit goal of “fill each truck to 90% capacity before leaving” moved their average utilization from 65% to 90% in weeks. Once the goal was clear, the truckers figured out a way to get there. Of course, numbers can be gamed (see anyone who has tried to measure developer productivity by lines of code committed), but the focus benefit of picking a numerical goal is generally worth the risk, as long as you pick it well.
The other five elements can come in handy, but it’s easy to come up with examples where they’re not necessary. They’re all self-explanatory. Presented with landing page examples, they are:
Sequence (make sure you put analytics on the webpage before you deploy it)
Initial state (this page gets 400 visitors/month vs 4000)
Key decisions (should this page go to a self-service subscription page or should it submit a sales form?)
Anti-goals (this page update is NOT about changing the content of the page)
Constraints (we only have 5 hours of engineering time for this project)
When any of these would be high-leverage, it’s worth calling it out.
The Army‘s procedures include a step of asking subordinates to repeat the order back, to make sure that the intent has been fully understood. In a business context, that can come off as condescending. But framing it slightly differently, like “to make sure we’re aligned, what’s your understanding of the goal here?” can work. For bigger projects, asking the person who will be doing the work to write down the project brief and share it with you can be beneficial. That way, you can make sure they understand the purpose, and they can reference the documentation as the project progresses.
What to delegate?
Even if your ultimate goal is to delegate everything, you probably can’t get to that point today. So you’ll want to pick projects where delegation is likely to succeed. Here are some starting points.
The very best things to delegate are things where the person who will be doing the job in your stead is actually better at it than you are. I’m not a very good visual designer (cat gifs aside), so that was one of the very first things I looked for help with when starting the company way back in the day. The less of my pixels people saw, the better!
Low-stakes, repetitive work is also a great handoff target. You can hand off this kind of work to someone with bandwidth or, often even better, an AI. Because the work repeats, the time you spend training someone else to do the work will pay a bigger dividend in the future. And if the stakes are low, that’s usually an opportunity for leverage.
Area-of-responsibility work is also a good candidate. By that, I mean work that carries meaningful stakes, but belongs under someone else’s role. This can be mentally harder to delegate than lower stakes work or work you’re not good at, because you’ve gotten good at it yourself and it means something to have it done well. But letting other people grow into owning their full area of responsibility is one way to ultimately improve your organization’s effectiveness.
There are also some areas that are so challenging to delegate that it’s probably not worth trying. For example, if the decision maker for one of your largest customers is your old college friend, trying to pass that relationship to someone else is unlikely to be successful. It’s also hard to delegate something that fits one of your own personal superpowers. If you’re the one person at NASA who has a knack for how the propulsion system works, even if you’re promoted, you should probably not have someone else crash the space ship because their intuitions went wrong with propulsion.
Finally, you should always make the highest-stakes, most irreversible decisions in your area of responsibility yourself. You should absolutely solicit input – consulting smart people to make the right choice isn’t delegation. But if you’re betting the farm, you want to make the final call.
More delegation frameworks
The ideas around intent were what I found most compelling about how to delegate, but there are a few other well-studied frameworks and concepts that are worth thinking about.
Possibly the best-known delegation concept comes from a 1974 HBR article called Who’s Got the Monkey? Every problem can be visualized as a monkey on someone’s back. When you delegate a problem to someone else, the monkey jumps from your back to theirs.
There are many ways, however, for a monkey to climb back on to you. If you’re asked to review a draft, the monkey’s on your back. If you’re asked for input, until you provide it, there’s the monkey again.
The insight in this framework is that you can only feed so many monkeys at once. So when something you delegated returns to your back, you have to make a decision to make it a priority (feed it), or to refuse to take responsibility for it again (shoot it). “I don’t need to review this, just send it” is often the right answer if you’re already fully-loaded with monkeys.
A good way to frame how effectively you are delegating the things you intend to delegate is to look at it like a dial between 5 different levels of delegation:
Do absolutely nothing unless I ask you to specifically do it.
Ask me how to handle things as they come up.
Make a recommendation, then wait for my approval before proceeding.
Do what you think is best, but check in frequently.
Handle it; report back at our next scheduled check-in, if at all.
The goal probably should not be to push all of your delegated work to a Level 5 task. If you’re the head of the finance department, you are going to want to look at the taxes before they’re filed rather than at the next quarterly meeting even if there’s “nothing surprising” and your subordinate feels comfortable filing them!
Ideally, you’d want virtually no projects at Level 1 and limit Level 2 projects as much as practical. Otherwise, the monkey’s on your back again almost as soon as it leaves. And whatever level you’re targeting, you want to make sure that everyone has the same expectation.
Figuring out what tasks are appropriate for each level with each person is more of a craft than a science. Andy Grove, the former CEO of Intel, described his framework for figuring this out as task-relevant maturity in his book High Output Management. The right delegation level is specific to the individual’s experience and energy level related to the specific task, not their overall level of seniority. Grove categorized task competency into four buckets and made recommendations for adjusting how you delegate.
Low skill / low will (teenager at an ice cream shop): Direct and instruct. Provide step-by-step instructions, and monitor closely.
High skill / low will (experienced worker doing rote work): Engage and align. Shift from “how” to “why”; involve them in goal-setting to build ownership.
Low skill / high will (new hire): Coach and support. Set goals, offer regular feedback, allow some rope for mistakes. This is the case where “clawing back” a task when it doesn’t go smoothly the first couple of times is the most tempting. Try to resist.
High skill / high will: Delegate fully. Set outcomes together, step back, offer autonomy. This is the place where the delegation dividend becomes really high. The work can get done better than you would do it yourself, with less effort on your part.
Delegating to AI
Now that we all have access to “workers” on our computers and phones, learning how to delegate is more important than ever. Delegating to AI is broadly similar to delegating to humans, with a couple of sneaky twists.
Overall, the skills translate - providing context, providing anti-goals, and making sure you communicate the goal-behind-the-task all help AI work more effectively and efficiently, too. And there are some aspects you don’t have to worry about. Though AI may balk a bit at super high token (high-effort, multi-step) requests, you mostly don’t have to worry about it getting sleepy or not being motivated.
But there are some differences that are worth mentioning. First, AI is bad at saying “I don’t understand.” When AI fails, it fails confidently, either fabricating information altogether or making assumptions that it may not necessarily mention in its output. Providing more information in the prompt can go a long way toward making sure the assumptions are aligned. AI outputs are also harder to review. They’re always grammatically correct and seem equally high quality whether they’re based on sophisticated analysis of reputable sources or whether they’re made up from whole cloth. But even with those caveats, there are a lot of cases where delegating to AI can save a lot of time.
Tip of the week
List everything that’s on your plate for next week. Note the projects that only you could do.
From the rest, pick one task to hand off, whether to another person or to an AI, before the next episode. If you pick something interesting, let us know what you chose and how it went! questions@lessbusylab.com!
Thanks for reading and/or listening! Go forth and delegate, so you’ll have more time for podcasts and newsletters!
This post is based on Episode 21 of Less Busy Lab, a podcast of our field notes from 20 years running a productivity software company. Find this episode here, and subscribe wherever you get your podcasts!