Lean delegation
If you Google ‘levels of delegation’, you’ll notice two things:
- Lots of people have written about levels of delegation.
- Nobody agrees how many levels there actually are.
This reminds me a little bit of the seven-minute abs hitchhiker guy from the movie There’s Something About Mary.
But anyhoo.
The point of these levels (whether there are 5 or 12) is to get you to think explicitly about what it is that you’re delegating, and therefore how you expect the delegatee (is that even a word?) to report back.
So, level 1 is something like “I expect you to follow these exact mechanical steps and not to diverge from them. Tell me when you have finished.”
And the highest level is usually something like “Here is a company objective I would like you to achieve. It’s up to you how you do it. I trust you completely, so you don’t even need to tell me anything about what happened.”
Typically, you usually want something towards the latter, but not too far, at a level that’s appropriate for the situation.
As a new manager, I learned a little too slowly that erring towards a slightly higher level than I was comfortable with is the sweet spot. Doing this gives the delegatee a chance to surprise you. At the very least they’ll learn something.
Lean software advocates often remind us that we should be aligning around learning outcomes in product teams, rather than around features (which are assumed solutions, goes the logic). This is basically the same principle behind keeping the level of delegation as high as possible.
As a tech lead, delegating very little of the technical problem solving work - or delegating it at a very low level - is tech leadership on easy mode. At least to start with.
Holding on to this work quickly creates a technical leadership silo. The team become dependent on the lead to make all the decisions. This scales poorly in one team. But it scales very poorly when the team splits into two or more because of growth. Suddenly the silo is also a bottleneck.
The challenge is to start sharing and communicating work in terms of problems, hypotheses and learning outcomes early on. This may feel weird and awkward, especially where the team aren’t used to it, or the technical work is more focused on a ‘platform’ or ‘system’, and seems far away from user needs.
But doing this is a form of healthy investment, of the ‘give a person a fish…’ variety.
If you give a team a bunch of features to build in a prescribed way, they’ll learn very little about the product they’re building, its users, or indeed product development generally.
But if you give them an objective, license to explore that objective in any way they wish within some constraints, they may surprise you.
All the best,
– Jim
