The Art of Delegating
In 2006, I got my first taste of leadership as a warehouse manager at a furniture store. Since then I’ve served multiple times as a team lead, a founder, a CEO, and a board member.
In other words, I have had a lot of opportunities to think about how to delegate.
I made a lot of mistakes in the beginning, because I didn’t have anyone showing me a better way.
Today, 18 years later, I have finally found a system that works for me.
It’s a system based on three frameworks that I’ve learned from three great leaders. Today I want to tell you about each of these frameworks and how they fit together.
Let’s dig in!
Delegating the mission
Niclas Sandin is a CEO who deserves more credit than he gets. He is kind and humble and, above all else, a master delegator.
When I worked at BookBeat as an Android consultant I noticed he did something that I noticed had a huge effect on the whole organization.
Every chance he got he talked about:
- Where the company was going
- How we would get there
- Why we were going there now,
- And how the different departments fit into the big picture.
And I really do mean every chance he got.
If my memory serves it was every single all-hands. Even if he wasn’t the person who called the meeting and even if he didn’t have anything else to say, he would at least take five minutes to talk about the company mission and roadmap.
“But that’s not delegating”, you say. “That’s just presenting!”
I disagree.
When delegating you want to delegate problems, not tasks. Delegating the whole company mission is taking this to the extreme.
Talking about it is only half of the story, though. What makes it work is holding people accountable (without punishing!).
Being open about what didn’t go as expected, builds trust. Especially when you’re the one missing a target.
And it’s not enough to do it once. You need to do it 100 times. And a 100 times more over many years.
But just delegating the mission is not enough. Which brings us to the next framework.
Directly responsible Individual
You’ve probably heard of this Steve Jobs framework before.
One job, one person responsible. That’s it!
You’d be surprised at how rare it is to see it implemented, though.
There seems to be a movement towards collective responsibility. Teams owning tasks etc.
I think that is nonsense. If everyone is responsible, nobody is responsible.
I think what people get mixed up is the idea that having a single responsible individual is the same as having a single person executing.
This is not what I’m talking about.
For example, at Baby Journey we had a role called Feature Lead. This was a rotating role where one person was responsible for the delivery of a feature.
More often than not we had 2 or more people working on the same feature.
This brought clarity to the team, but also to people outside of the team. There was never any confusion about who the point of contact was.
As a side effect, it turned out to be a great way to build leaders. Every time you appoint a Directly Responsible Individual (or Feature Lead) you appoint a leader, they need to delegate in turn to get the things done.
The thing to watch out for though is to hold people accountable without punishing them when things go wrong. Blameless, not nameless is a principle that I like to use.
This is the best way I’ve found to make people feel safe to raise issues before they become critical. If they don’t, you’ll end up with a lot of firefighting instead.
As great as this framework is, we’re still dealing with individuals. We can’t delegate the same job in the same way to two different people and expect the same result.
Which brings us to the third and final framework.
Task Relevant Maturity
High Output Management is one of my all time favorite books. And Andy Grove's delegation framework is one of the best ones I’ve seen.
Put plainly, it is about matching the level of delegation to the level of experience the person has with this specific task you are delegating.
Sounds simple! But again, the devil is in the details.
Let’s look at two examples.
When delegating to a junior developer we need to delegate a clearly specified task.
Forget about “delegating problems.”
We need to provide strict instructions for exactly what to build and exactly how to build it.
They will still make mistakes. That is ok. That’s how they learn. But it means we need to give them lots of feedback every step of the way.
Contrast this with delegating something to an experienced VP of Sales.
It would be madness to give them detailed instructions on how to build a sales team. The reason we hired them is that they’ve done it many times before!
And if we are there to give them feedback on every email and phone call, they will say we’re micromanaging and quit.
Instead we need to delegate the problem (increase sales). Guiding is done using KPIs (or OKRs or whatever you prefer). And feedback will be delivered based on those.
This sounds obvious.
So far so good.
But what happens when you hire a senior developer who has never worked under the requirements on documentation that comes with building a medical device?
Or a sales manager who is good at hiring sales reps, but has never worked in your industry before?
I prefer to err on the side of being too involved here. Better to give too much feedback too often than too little too late. There is less chance of disappointment that way.
And as you keep delegating more work you’ll have a lot of opportunities to adjust.
Tying it all together
Make sure everyone is on the same page with the mission, make one person responsible for each task, and adapt to the person you’re delegating to.
Those three frameworks form a whole that has served me well for the past few years.
But I want to make it clear that I wouldn’t have come here without the help of others. And I am far from fully learned.
On that note, if you think this is helpful or, better yet, if you disagree with something, just hit reply and let’s get smarter together!
