Sometimes the Executive Should Do the Work

Isn’t that the usual leadership advice that starts following you around, the moment you get a bigger title?

“Delegate the work. Empower the team. Get out of them weeds, dude!”

It’s a call to elevate your thinking and spend your time on strategy, as opposed to execution.

Super good advice, folks… except for when it isn’t. Except for when it’s no good, very bad advice. And that’s when it has a leader, or an ‘executive,’ doing more hands-on work than they expected to be doing at this point in their careers.

They aren’t sitting back and reviewing the presentation… they’re building it. That dashboard idea they have, they’re pulling together in PowerBI with the sources they want to see in one place. Some of them write frameworks, others rework campaign architecture. Ultimately, they find themselves getting deep enough in to the details that, at times, they catch themselves wondering if they’re leading the work or just, you know, doing it. With a more expensive title.

It’s an instinct, or an assumption, that makes a lot of execs uncomfortable. “We’re supposed to be above that now!” But I'm increasingly convinced there's an important distinction between doing the work because nobody else can and doing the work because nobody else knows what good looks like yet.

Those are different. Big time different. Both problems, though.

When you walk into a new organization, inherit a new team, or try to change how an existing function operates, delegation is literally a shortcut. It’s easy to tell someone you want a better dashboard. Or that the story and messaging need to be clearer. And everyone will just nod and nod and nod. Then they'll go build the thing they think you meant. Usually based on the standards, habits and expectations that existed before you arrived.

That's not their fault. The exec hasn’t created a new standard yet. Sometimes? Well… sometimes leadership requires building “Version One.”

(Not because you’re smarter or no one is capable, and definitely not because you should spend the next three years personally adjusting PowerPoint margins at 11:47 p.m.)

You build Version One because an example can communicate a standard faster than a dozen meetings can.

“Here's what I mean by an executive dashboard. Here's how I want us to tell the story. Here's what belongs in an executive conversation. Oh… and here's the 60% of material that doesn't.”

You know what I’m really saying…

“Here's what ‘good’ looks like.”

The important thing that needs to happen here at this inflection point, then, is that you as a leader have to stop building it. Bear with me, this is the part we often miss… If Version One established the standard, then Versions Two until Forever are testing whether or not you’ve codified that standard. And then someone else should own it.

Otherwise, what begins as leadership slowly devolves into dependency. By reworking or rewriting or shifting that margin and alignment under the subhead on that slide actually teaches everyone that quality arrives at the end of the process, when they personally intervene.

High priced bottleneck. Death on culture.

I want to build a new framework for this… no fancy name or graphic for it, just…

Build. Codify. Transfer. Inspect.

1)         Build the first version when the organization needs an exemplar.

2)         Codify what made it good so the standard doesn't live exclusively inside your head.

3)         Transfer ownership to the person who should actually run it.

4)         Then inspect the output. Not to reclaim the work, but to reinforce the standard. (That distinction matters.)

Maybe that's a more useful way to think about delegation at the executive level. The goal isn't to do less work simply because your title got bigger, it’s to do the highest-leverage work required at that moment. The trick is knowing whether you're creating an exemplar or creating a dependency. Because executives should absolutely roll up their sleeves, they just shouldn't permanently own the sleeves.