Delegating vs. Dumping: Where Do You Draw the Line?

A few weeks ago, I found myself caught in the middle of a classic workplace trap.

We had to double-check the special pricing lists assigned to our VIP customers.
It wasn’t a large list of customers, maybe around 10% of our base, but these were high-value clients with long-standing relationships, and mistakes on their pricing could damage both trust and revenue.

The task first landed with our Branch Manager, which made sense since it touched operations. But soon, he passed it on to the Sales Manager, arguing that “sales owns customer pricing.” A few days later, the Sales Manager forwarded the task to me with a casual note:
“You know the system better, can you just sort this out?”

No instructions.
No context.
No support.
Just… a task dropped in my lap.

Honestly? My first reaction was to do the same, dump it on one of my team members.
But then I stopped.
I thought: “If I want this done right, and I want to model how tasks should be handed off, then I can’t just pass the problem down the chain.”

So instead of dumping it again, I decided to take ownership.
If I were to delegate it properly, I’d need to provide full context, detailed guidelines, and make myself available for questions, especially since this task involves money and client trust.

And since that support would take as much time as just doing it myself, I rolled up my sleeves and did it.


✅ Key Takeaways:

  • Dumping is pushing a problem away.
    Delegating is setting someone up for success.
  • If you’re not transferring context, expectations, and support, you’re not delegating , you’re offloading.
  • As a manager or team lead, your job isn’t just to get things off your plate. It’s to build a system of trust and clarity.

💬 Have you ever felt a task was dumped on you without support or clarity? How did you handle it? What’s your rule for drawing the line between delegating and dumping?

Leave a comment