Delegate

Every month or so, I go for a walk and think about my teams' work from a specific point of view. I look for things I would have done differently, and I start to worry if I can't find at least a few. If I agree with everything they've done, chances are I'm too close to the team and both of the following things are happening:

  • Some initiatives are going wrong but I can't see it. I'm too involved in everything to see the big picture.
  • I'm not leaving the team enough space to get off the script and get something wrong. Often this means I'm not delegating enough.

Good leadership isn't about building a team that always gets it right: it's about helping people find a way to learn from their mistakes. What you want is responsible freedom. Let people do whatever they think is best to achieve the outcomes you agreed upon. Then hold them accountable by what outcomes they produce and not by how they produce them. This approach helps you more than anyone else. It makes your team grow faster and you can delegate more and more to them.

Delegating is harder to practice if you only see it as a tool to get things done. Getting something done yourself often has a faster turnaround than delegating it to someone else. I have struggled with this and I know of many leaders who also found this challenging. What helped me overcome this challenge is looking at delegation primarily as a mentoring technique. The idea is to know what kind of activity serves better the person you're delegating to. Don't delegate just to get more things done. It's a wasted opportunity.

Delegating also needs balance. There is a risk of delegating too much and losing contact with the everyday reality of the people you work with. Every now and then, I choose a non-trivial (but also non-critical) task for myself to make sure I'm still in contact with what the "doing part" of the job looks like. The outcome of this activity can be surprising. If you always stick to your usual role, you may discover problems about the day-to-day operations that both you and your teams have trouble seeing. A real-world example I've run into more than once is build pipeline times:

  • It's not a given that you, as a leader, know how long it takes to build a system if you don't work with it every day.
  • Build times often degrade so slowly over time. The team may not realise how much worse it got.

When you run into such a problem, use it as a collective learning opportunity. Don't fix it yourself or, worse, ask someone to fix the problem. Make it a conversation, help yourself and the team to see how you got there and what's the best course of action.