You ask someone to finalise a job description.
“I’ll take care of it.”
Good. You move on. Two weeks later, you ask how it’s going.
“Ah, sorry. That slipped through.”
The delay might not matter much. Perhaps publishing that job description two weeks later makes very little difference. But during those two weeks, you thought someone was working on it. You had taken it off your list. Apparently, so had they.
Nobody was doing the work, and only one of you knew that.
At first, this looks like a simple problem: someone forgot a task. People need to be more organised. Fair enough. But once you’ve had this experience a few times, your own behaviour changes. You keep a list of everything you’ve asked people to do. You check in. You send reminders. Eventually, you schedule a meeting to find out whether someone has done the thing you thought you had already handed over.
The task never really left your head. You delegated the execution and kept the job of making sure it happens.
A lot of work in an organisation consists of passing balls between people. Someone needs a decision, an answer, a piece of work. They pass it to someone else and expect something back. Or they expect the person to finish the job, so nothing needs to come back beyond “done”.
This is basic stuff. It is also surprisingly easy to get wrong.
If you take the ball, manage it
Someone who accepts a task needs to make sure it doesn’t disappear.
That doesn’t mean doing everything immediately. Sometimes you have no capacity. Sometimes the task is less important than five other things. Sometimes you don’t yet understand what’s being asked. Those can all be good reasons not to do the work.
They are not good reasons to leave the other person believing it is happening.
“I can’t take this on this week” is a useful answer. So is “I can do it, but not before the end of the month.” The other person can then decide whether that works or whether they need another solution.
“Sure, I’ll do it,” followed by quietly burying the task under twenty others, is less useful.
I understand the temptation. Saying yes feels cooperative. It is also easier than explaining that you have other priorities, particularly to someone who thinks their request should be one of them. You avoid an awkward conversation now. Unfortunately, the other person starts planning around your answer.
That is where a private capacity problem becomes someone else’s problem too.
How you keep track of your commitments is mostly up to you. A notebook, a task list, whatever works. But it needs to work on a busy day, when another ten things arrive and you’re interrupted halfway through something.
“I’ll remember” is a fairly optimistic system.
Agree on when it comes back
Not every missing ball has been forgotten. Sometimes two people have different interpretations of the same conversation.
For one person, “I’ll look at it” means this afternoon. For the other, it means after the urgent work is finished. Neither thinks there is a misunderstanding, because neither has checked.
A handoff therefore needs some shared expectation about timing. Not every small request needs a formal deadline. But both sides should have roughly the same picture of what happens next.
If I need something by Friday, I should say so. My urgency isn’t necessarily visible from your side. And if you agree to Friday, I should be able to expect either the result on Friday or a message beforehand saying it won’t be ready.
Beforehand matters.
If I hear on Wednesday that something is slipping, we may still have options. Reduce the scope. Get someone else involved. Move the next step. If I only find out after chasing you on Friday afternoon, some of those options may be gone.
Of course, difficult work is uncertain. Pretending otherwise doesn’t make anyone more professional. You can say: “I’m aiming for Friday. I’ll know after Tuesday’s test whether that’s realistic.”
That gives the other person something they can actually plan around. It is more useful than an unconditional promise you don’t have much confidence in.
And eventually, the work does need to get done. Providing excellent updates about why something remains unfinished is not quite the same as delivering it.
The person passing the ball has work to do too
So far, this is convenient for whoever delegates. The other person should organise themselves, deliver on time and communicate when something changes.
But consider the original request:
“Can you sort out that job description we discussed a while ago and get it over the line?”
Which job description? Where is the latest version? Has the role been approved? Does the text need editing, or are there still unresolved questions about what the person will do? Who needs to sign off? When should it be published?
I might have spent twenty seconds writing that message. The recipient now has to reconstruct the context or send me five questions.
I could interpret those questions as a lack of independence. But I should probably look at what I gave them first.
A more useful handoff would be:
Can you finalise this job description for the software engineering role [link] by Thursday and send it to Recruiting for publication? The role and requirements are agreed with the team. What’s left is the wording; you can make those changes without further approval. We want to publish on Friday.
Now the person knows what the task is, where to find it, what has already been decided, what they can decide themselves and when it needs to be finished.
This takes a little more effort from the sender. Usually much less than the combined effort of several rounds of clarification.
It doesn’t mean every message should become a project brief. If someone already knows the context, five words might be enough. The question is whether they have what they need to proceed.
Nor do you have to know the solution before handing something over. Finding the solution may be the task. But “work out our options and make a recommendation” is a different request from “implement the option we already chose”. Confusing those two creates quite a lot of unnecessary work.
The aim is to avoid questions that only exist because the handoff was incomplete. It is not to discourage questions altogether.
If someone notices a consequential ambiguity, I want them to raise it. I don’t want them building the wrong thing because they think working independently means never asking. But if their first question is for the link I had open while writing the message, that is on me.
Some balls don’t need to be passed
There is another way to make collaboration unnecessarily expensive: send everyone lots of small requests.
A quick question. A forwarded email. A document with “Thoughts?” attached.
Each takes very little time to send. Receiving it is different. The other person has to switch context, understand what they’re looking at and work out whether you need a decision, an answer or just someone to have seen it.
I find it tempting to send a thought as soon as it occurs to me. Then it’s out of my head. The fact that I have just put it into someone else’s is less obvious at the moment of sending.
This matters particularly when passing work upwards. Someone responsible for several teams receives questions from all of them. Your request might be entirely reasonable on its own. The sum of those reasonable requests can still fill their day.
Before sending something, it is worth asking whether you actually need that person’s involvement. Can you resolve it with the information and authority you already have? Is there a decision only they can make? Or would you mainly feel more comfortable having them confirm your answer?
Sometimes that confirmation is warranted. Sometimes you already know enough to act.
When you do need a decision, prepare it. Explain what needs deciding, which options matter and what you recommend. The recipient should not have to repeat all your work just to understand the question.
When you are only sharing information, make that clear. “For information, no action needed” tells me something that a forwarded email does not. Otherwise, I first have to determine whether there is a task hidden in it.
None of this is an argument for keeping problems away from your manager. Some balls absolutely need to go upwards. A risk outside your authority, a decision you cannot make, a conflict between priorities that you cannot resolve. Keeping those to yourself to avoid bothering someone is not helpful.
The point is to use other people’s attention deliberately. It is a limited resource, even when sending them another message is free.
There is an awkward consequence here for the person handing out work.
I want to give someone a task and stop wondering whether it still exists. But that requires them to be honest about what they can take on. Including when the answer is inconvenient for me.
If I react badly every time someone says they have no capacity, I give them a reason to say yes before they have worked out how to deliver.
I may still think my request should be their priority. Then we need to discuss what comes off their list. I would rather have that disagreement now than spend two weeks believing in work nobody is doing.