Delegation and trust

Getting delegation right is about making sure everyone feels good about the process. Only if everyone is committed and bought in will the best outcomes happen. Here are some tips to build confidence and trust, and help both sides avoid anxiety and frustration.

When to delegate

The ideal case for delegating a task is when you know someone else can handle the task at least as well as you. Unfortunately, the reality is that sometimes you aren’t sure if the other person can handle it. Sometimes you even know they won’t do as good a job as you would do. What do you do in these cases? My personal philosophy is to err on the side of delegating anyway: most managers and leaders have more to do than they can handle, and most people are capable of a lot when given the right chance. Of course, you don’t want to take this too far, and the less ready someone is to manage the project, the more important it is for you to support them.

Even with lots of support, though, handing off a project to someone who may or may not be ready is a risk, so you’ll need a way to make sure you can step in if needed. If things go really bad, you’ll need to cancel or take over the project yourself. But both those options can be really demoralizing and wasteful, so you want to avoid them if at all possible. (See my post on mistakes you shouldn’t let your reports make for more on when to step in.)

Make sure you see the first signs of trouble

To avoid having a project completely unravel, you’ll want to know the moment there’s a problem since it gets harder and harder to fix things the longer they are broken. However, many people don’t like to share bad news, and are worried that their manager will think they messed up if they don’t paint a rosy picture.

I always remind people that I’m here to help if something goes wrong, but I’ve found this doesn’t sink in for everyone. What seems more helpful is setting up a specific update structure that includes what’s going well, what’s not going well, and if the project is still on track to meet the original timelines. Asking for regular updates in this format seems to make it easier for people to share. Perhaps because it reminds them that problems are normal and just part of a complete update, rather than something exceptional they need to feel ashamed of.

It never hurts to get some independent verification about progress from others if you can, but making the person leading the project comfortable is the best way to get the info straight from the horse’s mouth.

Be clear about the expected outcome, timelines and milestones

This is delegation 101, but it’s worth repeating: make sure the person you delegate to fully understands the expectations. What are the deliverables? When do they need to be complete? What regular updates should they give so you can feel confident the project is on track? Who else needs to be in the loop?¹ This all needs to be clear from the beginning. I’ve had to rescue more than one project that went off the rails because the original person delegating wasn’t fully clear about expectations.

The worst projects are the ones where one person feels like it was a success and the other thinks it was a failure. If you agree on the definition of success from the beginning, you won’t end up in that situation.

Create escalation rules

In addition to regular check-ins, I like to create what I call “escalation rules”. These are triggers that indicate to the project leader when it’s time to escalate to me for help. Usually, this includes:

• If an initial estimate on price or timeline has to be revised.
• If a new, significant risk is discovered.
• If a critical decision needs to be made.

Even if you have regular progress-report meetings, setting escalation rules reminds everyone what parts of the project you need to be looped in on. I also like to reassure my reports that I am there to help them in these situations, not take over, and the sooner they identify problems the sooner I can help.

Don’t make them guess what you care about

One thing to be especially mindful of is that we often care about certain parts of the project more than others without realizing it. Try to be self-aware about this and share your concerns out loud. For example, if I’m asking someone to propose a new org structure, I might think through the problem a bit myself and think about why I’m looking at it a certain way – maybe I know two people work particularly well (or poorly) together, or maybe it’s important to me to stay close to certain teams. Thinking that through helps me to articulate these concerns to the person I’m delegating to.

If you forget this step, you might get frustrated when the project lands differently from how you hoped, or you might end up needing to jump in to course correct – neither of which makes for a successful project because they leave at least one party feeling demoralized.

Let the other person make the decision

Sometimes delegating means you’ve already decided what to do and how to do it, you just need someone else to execute. This may seem like an ideal situation because you can hand off your plans to someone and know exactly the steps they are going to take and how things will pan out. Unfortunately, this situation tends not to work out very well for two reasons. The first is that no one else is going to be as bought into your plans as you are. The other is that nothing ever goes perfectly to plan. When plans change and it still feels like your plan, it can be hard to let others make changes to it.

The solution is to let the person you are delegating to decide how to proceed. Tell them what you need them to accomplish, but let them own the how. Asking someone to make a decision and carry it out is a powerful gesture that both shows your trust in the other person and helps get buy-in, because people are more invested in carrying out decisions they make than decisions someone else makes.

Of course, for this to work, they need to know how to make the decision themselves, and that may not be possible: they may be new, they may lack the necessary context, etc. In these cases, I find it’s helpful to split the difference – telling them the decision I’ve made, but asking them for their input, or leaving as much as I can undecided. eg:

• “Here’s how I’ve thought about this so far, and I think this is the right approach, but I’m still not sure about X”.
• “I’ve ruled out X, Y and Z, but I’m not sure of the right way forward”.
• “My first instinct was to do X, but what do you think?”²

My previous article on Autonomy and Clarity in Leadership Styles may be helpful when deciding how (and how much) to delegate decision making.

Notes

1. I like to use the DACI framework for establishing who needs to be in the loop, but a framework isn’t as important as remembering to take a few moments to consider who is impacted by the project, and be clear about whose responsibility it is to keep the stakeholders up to date. ↩

2. If any of these feel like “incepting” your boss, so they think they came up with your idea, I agree. Incepting works well both ways because it gets everyone bought into the same idea. People feel more strongly about an idea if they think they came up with it. ↩