I’ve always struggled with delegation, and as I started to work as EM and then Principal developer, struggling with delegation can affect my personal and team performance. The stakes are high.

I don’t think I am alone in this. I’ve worked with many managers and leaders who also struggled with delegation.

What failed delegation looks like

I have noticed two ways of failed delegation: the first one is what I would call “passing the buck” in which the person delegating something gives you a problem to solve that’s theirs, along with the responsibility and accountability without any support. The other type of failed delegation is not giving you full autonomy so the person delegates something for you to do but then changes it to whatever they think is best. It is the second type that I’ll write about in this article

Why is hard to delegate and accept someone else’s solution?

When you delegate and delegate properly, what you are delegating is the responsibility of solving the problem or carrying out the task, but the accountability stays with you: if that task has a bad outcome you’ll have to own it. Taking ownership of something that another person is doing is scary.

That’s why many people who delegate actually don’t fully delegate the responsibility and they still get involved in how to solve something or try to steer you into the way they would do it, sometimes to the extreme of overriding what you decided to do for what they think was the best solution since the beginning. That is demotivating, and suffocating and ultimately, leads to disconnection from the person to the team.

How to fully delegate responsibility without feeling out of control

The secret behind fully delegating responsibility is trust. You can’t delegate responsibility without trusting the other person won’t let you down.

Trusting is accepting other’s solutions without having to agree with it

I think that phrase gives you a perfect way to approach delegation of responsibility without feeling without control over the outcome: focus on your concerns rather than the specific solution.

Say you’re delegating someone a project to build a dashboard for the users. When you receive the project you start thinking about how the dashboard will behave on mobile devices, how the data is going to be loaded to minimize waiting time for the users, how the dashboard is going to recover from errors loading the data, and so on.

A terrible way of delegating this project is to say “here’s this project for you. It’s very important that the user can use the dashboard on mobile devices so maybe you should build it this way it’s also very important to load this part of the dashboard as soon as possible because it shows critical information so you should load the data that way…”. You’re taking away any agency that person may have had to think about how to solve the problems.

Instead, a good way of delegating that project is to say “here’s this project for you. Take some time to think about how you want to approach it, and let’s talk”. when you talk, two things could happen: the other person lists the same concerns you had and details how to approach them (win-win!) or the person doesn’t list some or none of the concerns. At that point, what you do is you ask questions: have you considered how this will behave on mobile devices, how do you think we should load the data to ensure this and that part of the dashboard is rendered ASAP, how are you thinking of handling errors?

Why does this work?

What you’ve done with those questions is very important: you haven’t taken away their responsibility, they still have to solve those problems, but you’ve laid out the expectations, a solution that doesn’t address those concerns is not good enough, and by waiting for them to come to you with their proposed solution before asking those question you’ve given them the opportunity to think of them themselves instead of you doing it for them! And as a bonus, you’ve shown them how you think about these kinds of projects and how you analyze them.

Now, it’s safe to let go of the implementation. If the chosen way of solving the problem addresses all of your concerns in a way that satisfies you, then the implementation is not important (from your point of you).

Conclusion

If you struggle with delegation, try to evaluate which type of failed delegation you tend to do and try to understand the underlying motive. If it’s about not being in control of the outcome, I seriously recommend trying out the method I described before. It genuinely helped me become a better leader by letting other people grow instead of suffocating them.