How to Delegate Effectively as Your Responsibility Grows

Editorial note: I originally published this on the Hit Subscribe blog.

I’m gearing up, like some kind of power washer, to spray new productized services into our operations group so they can SOP those services at scale.  And because I’m doing that, this seemed like a good moment to draw on my experience, both in leadership roles and as a management consultant, and lay out a blueprint for internal delegation.

I debated musing about this over on DaedTech, especially since programmers uniquely struggle when asked to delegate (for reasons I’ll get into in a bit).  But then I figured you marketers out there reading likely also have challenges when flipping from individual contributor (IC) to team leader in a growing organization.  So whether you’d have offered a penny or not, here are my thoughts on delegation.

Delegation as a Function of Org Chart

Let me start by explaining how successful delegators at each level of the org chart delegate to their direct reports, in broad strokes.

• Executives: “You are accountable for this organizational goal.  Your deliverable to me is a plan and overseeing execution of that plan.”
• Middle Management: “You are accountable for successfully executing this plan.  Your deliverable to me is judgement-based execution of the plan in a fluid environment.”
• Supervisors: “You are accountable for these KPIs.  Your deliverable to me is executing the tasks that generate the KPIs.”

Now, let’s look at how ICs (and unsuccessful supervisors) tend to delegate.

• ICs: “You are accountable for nothing.  Your deliverable to me is an execution of tasks to my exact specification.”

At the risk of restating the obvious, let’s pause here and observe something.  Successful delegation involves both tasks and accountability.  Unsuccessful delegation cedes only tasks and retains a vice grip on all accountability.

I don’t pay you to think!

Appropriate Situations for Each Model

All of the above flavors of delegation have appropriate uses, including the IC one.  But I really only want to focus on appropriate uses for the supervisor and IC cases.  I’m not aiming to train executives and middle managers at the moment.

When IC-Style Delegation Makes Sense

Let’s start with the counterintuitive one.  When is soul-crushing IC delegation actually appropriate?  Well, pretty frequently, actually.  Especially when you consider that this style of delegation usually takes the form of extremely detailed documentation.

• When you’ll have no contact with an inexperienced task executor (e.g., the instruction manual for a microwave).
• A high-stakes task rarely executed (e.g. offboarding a senior employee).
• Situations with an endless stream of turnover in the executing role.
• When you’re dictating tasks to a savant that takes everything extremely literally, like, say, a programmer programming a computer.

One pattern I want to call out here is that all of these situations are suboptimal, in a philosophical sense.  Well, except the programming one, which I just threw in to demonstrate why programmers struggle so much to learn to delegate to humans: they’ve spent an entire career learning how to be bad at it.

In all of the other cases here and in general, the delegation to a human is occurring only because automating or eliminating the task has yet to occur or isn’t practical.  Why have error-prone humans execute high-stakes, well-defined tasks?  Why have endless turnover?  And why pay people if you don’t want them to think?

In an organization, this style of delegation is almost invariably a placeholder until someone improves things.

When Supervisor Delegation Makes Sense

Generally speaking, if you’re in a management role, you should default to supervisor-style delegation.  Treat any IC-style delegation as suspect.

To make this more tangible, supervisor delegation makes sense with any direct reports you have.  If someone is going to be answering to you for any sustained period of time, they should have goals (at the least, the KPIs you hand them) and not simply an endless punch list of tasks.  But even more broadly, this is how you will (or should) work with a lot of vendors and even with people just doing transient tasks for you in various situations.

Productive delegation involves agreeing on a “what” and leaving the “how” up to the other party.  So any situation where you need to scale and/or free up your time, and the sky won’t fall without your input on “how,” is appropriate for supervisor delegation.

The Pain of IC Delegation

Up to this point all I’ve offered is a taxonomy and the assertion that one approach is better for most situations.  I can understand if you’re unconvinced.  So let me talk explicitly not just about the problems with pervasive IC-style delegation, but the pain that novice managers feel when they do it.

Scale Will Crush You

I’ve been coy about it up to this point, but for the ease of explanation, let’s call IC-style delegation by another, more familiar term: micromanagement.

As the (micro) manager, you essentially act as a collaborator on all work that enters your orbit.  So as a team of one, you can handle the workload of one person.  As a team of three, however, you can handle the workload of, well, not three.  Remember, you’re collaborating heavily on everything your two reports are doing, so you’re assigning multiple people to every task the outside world assumes is being done by a single person.

Micromanagers can usually make this work with a few reports, but the effort becomes Sisyphean as the team grows.  At this point, you’ll either come around to supervisor delegation or you’ll burn out.

Innovation and Change Are Terrifying

Let’s return briefly to the idea of a microwave instruction manual.  Extremely detailed runbooks are a common artifact of micromanagement, and they serve to calcify your group.

The microwave instruction manual makes sense because the target audience is an inexperienced microwave operator that is in no position to ask questions of the manufacturer.  But imagine that instead of a document that you use once or twice and then toss or keep around for reference, it served as official governance for all microwave operation.

You tell your report to microwave leftover mashed potatoes, and they come back to you sheepishly and say they can’t because that’s not in the manual.  What do you do at this point?  Add to the manual, of course, then hand it back to them.

Imagine how tiresome this becomes every time you want to reheat food.  Eventually, tired of adding to the 9,000-page microwave instruction manual, you’re going to get irrationally and disproportionately upset anytime someone comes home with a takeout meal from a new restaurant.

In the moment, that may seem perfectly sensible to you, but it won’t seem sensible to anyone else in your organization, including your boss.

You’ll Get Frustrated with Permanent Juniority

And the rest of the world notwithstanding, won’t you get annoyed with this?  Imagine having a team of people that asked you how to use the microwave every single time they microwaved something.

If every variance in food type, amount, age, and room temperature resulted in you communicating to them that they couldn’t operate the microwave without your guidance, they would develop a sense of learned helplessness.  And sure, you may be the foremost microwaving expert, but at some point, “Can’t you figure this out yourself?” is going to start to creep into your internal monologue.  The problem is, you’re creating an environment where the answer to that question is “nope.”

You’ll Author Bad Results

And for all your efforts at control, you’ll still wind up presiding over bad results.  Your team’s output will be worse than what you yourself would do.  But it’ll also be worse than what they, themselves would do.

Unless you’re dictating cookie-cutter, unchanging, predictable processes a la assembly lines, someone will need to bring judgement to bear.  In a knowledge work context, this will happen constantly.  For one person to orchestrate that and retain all of the judgement requires voluminous process to deal with all of the conditionals and decision logic.

And asking human beings to faithfully execute lengthy, complex tasks by rote is asking for inevitable failure.  People operating in good faith will not remember everything or be able to follow along flawlessly with page 45, section 2B.  If you don’t believe me, ask yourself whether every taxpayer in the US manages to correctly and exactly file their own taxes every year.

But what makes matters worse is that you can only preside over this for so long before the faith of your reports, especially talented ones, stops being “good.”  Eventually you will also find that people maliciously comply with your inherently flawed, detailed instructions on how to do everything.

Talented People Will Quit

Oh, and speaking of talented people, they’ll all quit…unless they simply start to ignore you, and you respond by throttling back on the details.

In any case, micromanagement is virtual assurance that the only people who stay on are those who are happy (or relatively less unhappy) to just shrug and say, “Whatever, you’re the boss. Literally any thinking at all is above my paygrade.”

How to Self-Assess Your Delegation Style

I could probably go on here, but hopefully that’s enough.  I want to shift to talking about how to self-assess.  How do you recognize when you’re doing IC delegation (or that you’re about to, if you’ve just recently been put in charge)?

I’ll offer up some heuristics in list form that suggest you’re in the micromanagement weeds.

• When you delegate work to people, the delegation takes the form of a lot of numbered lists of steps.
• Most of your runbooks and verbal instructions spend far more time on “how” than “what” and probably never talk at all about “why.”
• If I asked you “What decisions are your reports empowered to make?” you would stare at me blankly.
• You hear about any and everything unusual that happens in the form of “What should we do?”
• You orchestrate, in detail, interaction protocols among your reports.
• You’re constantly updating documentation that your reports practically live in to do their jobs.
• You view an increase in the workload of people reporting to you as an increase in your workload.
• When asked how you know if your reports are having success, you’ll talk about their prompt task completion rate rather than the value or outcomes they deliver.
• If you’re honest with yourself, you’ll realize you evaluate people on the basis of how reliably they do exactly what you would have done.

If you find yourself nodding along with a lot of these, you’re probably struggling to delegate effectively or you will start to in the near future.

Moving Towards Effective, Scalable Delegation

So, what should you do about it?  Here are my recommendations, ironically, in numbered order for implementation.

1. “I Wouldn’t Have Done That, and That’s Okay”

I’m not listing these in order to micromanage you but rather because I think there are some logical prerequisites.  The very first thing you need to do is accept that people reporting to you will not do exactly what you would do.  And not only is that okay—it’s for the best.

It’s easy to think, especially if you’ve enjoyed a successful run as an IC that led to promotion, you owe your leadership role to having unlocked optimal task execution.  You’re the boss because you’re the best programmer or content writer.  Ergo, it’s your job to soak your reports in your approach to craft until they become you.

Nah.  First of all, you’re probably overestimating how much that contributed to your success, and secondly, you’re definitely overestimating how much it matters if people do things differently than you or, God forbid, ever so slightly less efficiently.  The wild inefficiency of micromanagement will more than offset any ostensible gains realized by forcing your “better” way on everyone.

So make peace with it.  Your reports will do things and you will think “that’s not what I would have done.”  Let it go.

2. Differentiate the What and How in Everything You Hand Off

When you’re about to hand off a task or a process, take stock of the “what” you’re asking as well as the “how.”

Specifically, go through everything you’re about to say or email or whatever. Ask whether each component is defining what you want done or defining how to do it.  “I want a blog post about delegation” is pretty what-y, but “I want you to write a blog post about delegation in the classic WordPress editor because I’m going to make a bunch of changes to it and I hate using Gutenberg” is getting pretty how-y, what with all of your red pen and UX preferences.

In the beginning, you don’t really even need to slap your own hand when you’re in how-land.  Just become aware of it.

3. Start Defining Success Criteria and Explaining Why It’s Valuable

Looking back at the example I just gave, there is a “why” of sorts in there.  But the why is “I, your boss, personally don’t like using this editor when I’m micromanaging.”  That’s such a bad why you’d probably stop yourself before saying it out loud if you’re serious about kicking the micromanagement habit.

Instead, as you’re hopefully handing off the what (a blog post) and not how, start to define success criteria.  That inevitably leads to a conversation of why do it in the first place.

“We’re doing a blog post about delegation to give everyone food for thought in advance of the organization staffing and training for new roles.  So it’s a success if all of the relevant folks read it and come with questions and ideas to the kickoff meeting.”

Notice that we’re not talking about red pens and editors anymore but rather about the enablement of business scaling.  Crucially, this lets the hypothetical person that I’m delegating to work however they’d be most productive (maybe markdown in some desktop editor for all I know), and even come up with alternative ideas that I didn’t have.  “Why do that as a blog post? Maybe an internal webinar would be more effective.”

4. Define Safe Failure Zones

Now that you’ve laid the philosophical groundwork for giving people some freedom to figure out how to do what you’re asking them, you need to think about how much freedom is safe.  They are going to do things differently than you, and sometimes they’re going to get things wrong.

To stop neurotically trying to prevent mistakes, you need to create situations where mistakes are okay.

If you stop telling people what WordPress editor to use, or even how to draft posts, people will use different things. That will probably result in formatting mistakes when pasting things in.  Is that the end of the world?

Who knows.  Maybe.  If it is, then all you need to do to create a safe failure zone around this process is have someone assume the role of “formatting sanity checker” and own responsibility for hitting publish.

Now you can let people draft in whatever technology they want and make mistakes.  When they do, the formatting checker can point it out and no harm done, and no creative freedom restricted.

If enough people make the same formatting mistake, then maybe you think about some kind of policy or announcement.  Or maybe you just figure out how to make that mistake impossible to make.

5. Set Caps on Requirements

Piggy-backing on the last section, let’s say you make an announcement about this common mistake.  And then maybe there are a few others, so you start a document with rules and sanity checks for uploading drafts to make life easier for the formatting checker.

Have a cap on how much stuff goes in that document.

If you’re asking everyone doing a process to remember one thing, that’s a no-brainer.  If it’s a handful of things or even a dozen, you’re still in reasonable ask territory.

But if you find yourself adding item 74 to the draft uploading checklist, stop it.  Nobody is going to remember all of that and people will inevitably make mistakes.

When your processes and policies start to place too much cognitive burden on your reports, it’s time to rethink your processes and policies wholesale.  Get out of the “how” weeds and go back to the what and the why. Brainstorm different ways to approach the problem.

6. Favor Reference Material Over Runbooks

Documentation is a tricky thing.  Insufficient documentation is a nightmare for people trying to self-serve.  Too much documentation creates a massive natural drag against needed change.

As a heuristic for navigation, I recommend thinking of the documentation you create as reference materials, rather than instructions.  As a simplistic example, I’ll call back to the microwave.

The instruction manual is explicitly aimed at the novice and is really almost a form of self-serve training documentation.  This is appropriate for a new microwave owner but not for someone who has learned a bit about the appliance.

At this point, a far more useful kind of documentation is a reference cheat sheet with microwave settings for common foods.  It’s handy to know that I should microwave mashed potatoes for two minutes on high at a glance.  But a simple table with that information would suffice, rather than a chapter in the instruction manual for every type of food.

Distill the helpful information for people in a way that enables them, rather than orders them around.  They know how to punch the buttons.

7. Favor Checklists Over Instructions

In a similar vein, I would favor checklists over instructions for explicit requirements.  Subtly, instructions are “how” and checklists are more “what.”

For instance, a checklist about a blog post might have things like “I optimized for the target keyword” or “I added a call to action at the bottom.”  That doesn’t speak at all to how one optimizes for a keyword or includes a CTA.  Instead it puts the onus of knowing that on the person you’re delegating to.

If that person knows full well how to do both of those things, then the checklist just acts as a vehicle for self-imposed quality control, which is great.  If they don’t know, the checklist acts as a good inflection point for evaluating whether the person might need more training or whether the process needs modification.

But starting with a checklist prevents premature bureaucratization.

8. Explicitly Differentiate Training from Standing Instructions

Speaking of training, make it clear when you’re supplying training and training materials versus when you’re giving them general instructions.

If you have some detailed, screenshot-heavy stuff, this can make for great training and onboarding.  But if you’re dumping that same stuff on people with the expectation that they’ll memorize it and follow it precisely indefinitely, that makes for, well, something else.  That makes for IC-style micromanagement.

After an initial training and onboarding phase, people don’t need instructions or even reference material in the same level of detail.  Make it clear what the purpose of the materials is.

9. Ask Them Why Not

The last bit of guidance that I’ll offer is a hack I’ve developed over the years.  It seems awkward or even aggressive at first, but bear with me.

When someone reporting to you asks what they should do about something or how to handle something, reply with “Why are you asking me this?”

Now the next thing you say should be “I’m asking this literally, not to suggest you’re wrong for asking.”  Because that’s what you’re doing.

When people reporting to you ask you what to do, it’s generally one of two things: an empowerment gap or a confidence gap.  An empowerment gap means you haven’t empowered them to decide what to do next, and you should aim to eliminate any empowerment gaps you don’t want in place.  For instance, below a certain revenue-at-risk threshold, I empower account managers to do whatever they think would make a client happy.  This actually resulted some years back out of this exact exercise.

If, on the other hand, you have a confidence gap, it means your report doesn’t know enough to make the decision or is worried about the responsibility.  This is a more nuanced situation than simply deciding whether or not to empower them, but you can usually effectively address it by making a point to arm them with more knowledge.

In either of these situations, this “why are you asking me” exercise is an explicit, iterative path towards delegating more and more decisions.

Hire Good People and Trust Them

I’ll close this out on a philosophical note.  Suboptimal delegation results from inexperience, but moving away from it often languishes because of fear.

What if I give them responsibility and they do the wrong thing?  What if I give them freedom and they goldbrick?  Or what if they make me look bad?

Relax.

In my experience, the overwhelming majority of people operate in good faith and will pleasantly surprise you when you trust and empower them, particularly at the supervisor delegation level.  And with the occasional person who doesn’t, having a solid delegation approach exposes those shortcomings in ways that micromanagement never could.

You don’t need to go through life with white knuckles if you have people reporting to you.  They won’t do things the way you would, and they’ll definitely make the wrong call from time to time.  And your life will be so much better for it.

Interested in More Content Like This?

I’m Erik, and I approved this rant…which was easy to do since I wrote it.  If you happened to enjoy this, I’ve recently created a Substack where I curate all of the marketing related content I create on different sites.

Totally free, permanently non-monetized, and you’re welcome to sign up.  Click here or fill out the form below: