Delegating a Result is Better Than Delegating Tasks

Early in my career, I was often told about the importance of delegation. It seemed obvious — if you're responsible for more tasks than you can handle, delegation is the only option.

Given that I was often accountable for delivering large projects, I made an effort to absorb the advice from my mentors, the training I received, and the books I read. However, most of the guidance focused on what to avoid, rather than how to delegate effectively.

For instance, I was advised to avoid micromanaging, but there was little instruction on how to manage effectively at a higher level. Another example I remember was being warned against "seagulling" — where you delegate a task and, if it's not completed to your satisfaction, swoop in at the last moment to finish it yourself (like a seagull stealing your last chip). Again, I didn't receive much practical advice on how to ensure a job was done well without resorting to micromanagement.

What no one explained to me was that delegation can occur in two distinct ways.

The first and most common method is to decide how a goal should be broken down into tasks and then delegate those tasks to someone on your team. Progress is typically measured by tracking which tasks are completed or by calculating a "percentage complete" for long-term projects.

For much of my career, this was the only model I knew. It's how work was delegated to me as well. A small team, which I rarely met, had already made a series of decisions about the "things" I needed to deliver in order to achieve a business outcome. Unless I specifically requested to read the business case, I wasn't privy to the "why" behind the project.

This model was frustrating. I often delivered the "things" I was asked to deliver, but there was a growing list of complaints from the people who had to use the system. To make matters worse, my own team lacked belief in the "things" they were delivering. They could already see that the outcomes were unlikely to be well received.

In my search for a solution, I discovered a second option — one that involves delegating responsibility for the broader business outcome, or the "business benefit," rather than simply delegating tasks.

Let's consider an example. I was hired to deliver a "call centre replacement system," which offers a great way to explore the benefits of this second method of delegation.

Notice that a "call centre system" is a "thing" — not a "benefit" or a "why." This distinction is key because many people consider the system itself to be the "result," but in reality, it's just a proxy for the actual business result. We could deliver the system and still fail to meet the sponsors' expectations, as the system is only meant to achieve a specific result.

Having recognised this pattern, one of my conditions for accepting the role was that the deliverables would be restated as a single, clear outcome. It didn't take long to agree on this. I've described some tips for successfully stating project goals in my article, 5 Tips for Successfully Stating Project Goals.

We settled on the goal: "Reduce the average call handling time by 50%."

This is a much clearer and more focused goal. Let's look at it through the lens of delegation.

There's solid research and growing consensus on the importance of motivation for high-performing teams. My own experience supports this: motivation is the single most important factor in building high-performance teams.

The key drivers of motivation are transparency, trust, and autonomy.

When someone breaks down their goals into specific tasks for me to complete, they are implicitly saying, "I don't trust you to do this yourself." Additionally, they're not being transparent about the reasons behind the call centre system replacement, which reduces my team's autonomy in finding better and more cost-effective ways to achieve the same result (shorter call times) more quickly.

There's a powerful philosophy in the Toyota Production System (aka Lean Manufacturing) that states: "The people closest to the information should make the decisions requiring that information."

Breaking down the business case into tasks and handing them off to a team a year later is essentially the opposite of this approach. The issue is that the people making those decisions aren't practitioners of the call centre or the technologies involved in building the solution. No wonder so many projects fail when approached this way.

Similarly, when a team of non-practitioners gives my team a "technical architecture" to follow, they're saying, "I don't trust you to manage the long-term technical interests of the company."

I liken this approach to putting a swimmer in concrete boots before their attempt at crossing the English Channel.

Simon Sinek, in his famous talk Start with Why – How Great Leaders Inspire Action, emphasises that it's impossible to motivate a team unless there's complete transparency and ownership of the "why" — which, in project terms, is the "benefit" or outcome.

How can a team deliver on an outcome like "reduce call time" if their objective is simply "replace the system"?

I've used this example to illustrate how I was impacted by this shift in delegation, but it didn't take long for me to realise I was repeating the same mistakes with my own team.

In the late 1990s, I made a conscious decision to delegate outcomes rather than tasks for any project larger than one person. Since then, I've applied this approach to more than 150 projects.

Here are some of the key benefits:

From the sponsor's perspective: The goal is achieved more effectively, at lower cost, and in less time. My rule of thumb is a "50% saving in time and money," and I have many examples where we've delivered previously failed projects for less than 10% of the original budget. What's particularly interesting is that these projects were all halted mid-flight, typically before 50% of the budget had been spent. This is largely because we avoided wasting time and resources breaking down tasks before delegating them. The rest of the success comes from a more motivated team delivering greater productivity.

From the manager's perspective: Project management becomes at least 90% easier. I'm not responsible for breaking down the big goal into smaller tasks. Instead, I leave that to the team because I trust them, and I've been transparent about the "why" or the outcome. One powerful aspect of this approach is that the goal remains consistent. For instance, the team first suggested (and committed to) reducing call handling time by 50% for one call centre agent. Then the goal was to achieve the same reduction for 5% of the call centre, 15%, 50%, and so on. The goal remained the same, but the scope changed. This simplicity is incredibly powerful.

For team members: They enjoy being trusted to deliver a solution they've developed in direct consultation with call centre agents. They get to see the positive impact of their work when agents express their satisfaction. These moments — where agents say, "Wow!" after a change is made — are deeply rewarding and help foster a unique team culture. I've seen teams work late into the night, making quick changes just to get that "wow" response from agents. This initiative was driven by the team, not me. They knew I would support them, but the decision was theirs.

For managers: The benefits extend beyond the team. A motivated team is a happy team, and this satisfaction is infectious. You build loyalty and engagement, not just within the team but across projects and organisations over time. I've had contractors and employees reach out to me within days of starting a new role, lamenting what they missed about the project we just completed.

I highly recommend this approach to delegation. Give it a try and see for yourself. You won't look back. :)

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.