You finished your part of a task three days ago. Now it needs a file from finance, an approval from a manager, or a choice from a client. The task is no longer on today’s to-do list, so it quietly slips out of view—until someone asks why nothing happened.
The problem is not always procrastination. It is that work waiting on another person occupies an awkward category: it is not actionable right now, but it still needs attention. A small waiting-on list gives that category a home. It helps you follow up at sensible intervals, explain a delay clearly, and decide when to move forward another way.
This is not a second project-management system. It is a short personal control panel for dependencies: the handful of things that cannot progress until someone else responds, approves, supplies, or decides.
Why ordinary task lists lose blocked work
A conventional task list asks, “What can I do next?” That is useful, but it does not answer, “What must I remember to check on?” If you leave a blocked task on the list, you repeatedly read an item you cannot complete. If you mark it done or archive it, you may not remember it at all.
Email and chat are poor substitutes. A request may be buried in a busy thread, split across multiple messages, or mixed with unrelated conversation. Searching later tells you what happened, but it does not reliably tell you what needs a follow-up today.
A waiting-on list changes the question. Instead of treating the next action as “finish the report,” it records the real next action: “check whether Jordan sent the revised figures on Thursday.” That is an action you control.
Blocked work is still work to manage. The goal is not to chase people constantly; it is to make the next check deliberate rather than accidental.
Keep the list small enough to use
A waiting-on list becomes useless when it turns into a duplicate of every project board and inbox. Add an item only when all three conditions apply:
- You have made a clear request or identified a specific dependency.
- Someone else must act, decide, or provide information before the work can move forward normally.
- You would need to remember to check back if no response arrives.
Do not add requests that are resolved in the same conversation, vague hopes such as “maybe they will have ideas,” or routine automated processes that already notify you when complete. The list is for dependencies where silence would create a problem.
Record five details, not a whole history
Use a note, a simple spreadsheet, a task app, or a paper page—whatever you will open during your daily planning. Each entry needs enough context to make a good decision without reopening every message.
| Field | What to write | Why it matters |
|---|---|---|
| Outcome | The deliverable or decision being unblocked | Keeps the item tied to a result, not merely a message. |
| Person or team | Who is expected to act | Prevents uncertainty about ownership. |
| Request and date | What you asked for and when | Lets you follow up with accurate context. |
| Check date | The date you will review or follow up | Turns waiting into a scheduled responsibility. |
| Fallback | What you can do if no answer arrives | Stops a dependency from becoming an endless loop. |
For example, an entry might read: Quarterly deck—design review from Morgan—asked for approval of slides 6–9 on Tuesday—check Friday morning—if no response, send the draft marked “pending design review” to the project lead for a timing decision.
The fallback is especially valuable. It does not have to be dramatic. It may be “use last month’s numbers temporarily,” “remove the optional section,” “ask whether another reviewer can cover,” or “tell the requester the deadline needs a decision.” Its purpose is to reveal that waiting has a cost and that you have choices.
Choose the check date based on consequences, not impatience
Do not make every follow-up due the next morning. People may be in meetings, handling urgent work, or working through a queue. A follow-up cadence should reflect the deadline, the effort required, and how much warning the other person received.
Work backward from the real deadline
If you need an answer by Thursday afternoon to complete a deliverable on Friday, your list should include more than one moment to act. You might send the original request early enough for a response, check in before the deadline becomes critical, and reserve time for your fallback.
By contrast, if the information is useful but not time-sensitive, a later check is often more respectful and more efficient. The point is not to create a universal number of days. It is to decide the timing while you can think calmly, rather than when the deadline is already in danger.
Match the follow-up to the kind of dependency
- A quick factual answer: A concise reminder can be enough, especially if your work is paused.
- A review or approval: State what needs reviewing, where it is, and the latest point at which feedback can still be used.
- A decision with tradeoffs: Summarize the choices and the consequence of no decision. This reduces the effort required to respond.
- Work from a busy specialist: Ask about timing or an alternate route rather than assuming the request can be completed immediately.
These distinctions matter because “Just following up” often makes the recipient do extra detective work. A useful follow-up makes the needed response easy to identify.
Write a follow-up that moves the work forward
A good follow-up is brief, but it should not be cryptic. Include the original purpose, the specific thing you need, and the practical timing. Avoid apologizing excessively for a reasonable request, but also avoid implying that silence is a personal failure.
For instance:
Hi Sam—checking back on the vendor comparison for the onboarding project. I need your choice between options A and B before I can prepare the final recommendation. If you can reply by Wednesday, I can keep the Friday review on track. If that timing no longer works, please let me know and I’ll adjust the plan.
This works because it restores context, names one action, and offers a route for communicating a delay. It does not require Sam to reread a long thread to understand why the answer matters.
Do not keep sending the same reminder
If the first follow-up gets no response, change the question. Repeating “Any update?” is easy to write but rarely clarifies the obstacle. Try one of these instead:
- “Is there information you still need from me to make this decision?”
- “Would a shorter review of just the highlighted section be more workable?”
- “Should I ask another person to approve this while you are unavailable?”
- “If I do not hear back by tomorrow, should I proceed with the current version or pause the release?”
That approach respects the possibility that the blocker is unclear, not ignored. It also makes escalation a decision about the work rather than a complaint about a person.
Review the list at two different speeds
A waiting-on list needs a light daily glance and a deeper weekly cleanup.
During daily planning, look only for entries whose check date is today or overdue. Send the follow-up, update the date, or take the fallback action. This should take minutes, not an extended inbox session.
Once a week, scan the full list for items that have become stale. Ask:
- Is this still needed, or has the project changed?
- Is the named person truly the right owner?
- Has the deadline moved without the list being updated?
- Have I been waiting when I could complete a different portion of the work?
- Does this need a clearer decision from the project owner?
Close completed items promptly. Also close canceled requests. An old item left open creates false urgency and makes you trust the list less.
Separate a dependency from a relationship problem
Sometimes one person repeatedly delays work, but a waiting-on list is not a private scorecard. Keep entries factual: what was requested, when, and what the project needs next. Avoid notes about motives or personality.
If a pattern is affecting deadlines, use the record to describe the process problem clearly: which handoffs tend to stall, what warning time is needed, and what alternate coverage would help. This is more constructive than arriving with a general impression that someone is unresponsive.
It is also important to notice when the dependency is yours. If your request lacked a deadline, a source document, decision criteria, or a clear owner, improve the request before treating the lack of response as a follow-up issue.
Common mistakes that make the system noisy
Putting every sent message on the list
This creates a monitoring burden larger than the work itself. Track only messages that block a meaningful next step or require a promised response.
Using a check date with no purpose
“Follow up Monday” is incomplete if Monday is too late to protect the deadline. Pair the date with a reason: obtain approval, choose an alternate path, update stakeholders, or release a partial version.
Assuming a reply means the dependency is finished
A response such as “I’ll look tomorrow” is useful information, not completion. Update the check date. Do not close the item until you have the needed answer, file, approval, or explicit decision.
Escalating automatically
Escalation can be appropriate when a deadline, customer commitment, safety issue, or major project risk is involved. But it should not be the default second message. First make the ask clear, check whether the recipient has a constraint, and consider an agreed fallback where possible.
Set up your first list in ten minutes
- Open your active projects and recent messages.
- Write down only the items currently blocked by a named person or team.
- For each one, add the original request date and one specific check date.
- Write a one-line fallback for the entries with meaningful deadlines.
- Place the list where you do daily planning, not in a separate system you rarely open.
Start with the one item that would embarrass you most if it went silent for another week. Give it a check date and a fallback today. Once blocked work has a visible next action, it stops relying on your memory—and becomes much easier to manage calmly.
Ad