Identify the blocker, not just the delay
A blocker is something that prevents a specific piece of work from moving forward. It may be a missing client decision, unavailable access, conflicting requirements, a dependency on another task, or a technical problem. A task that is merely taking longer than expected is not necessarily blocked: the person doing it may still have a useful next action.
Describe the blockage in terms of work and impact. Instead of “We are waiting on the client,” write “We cannot finalize the homepage layout until the client chooses one of two navigation options.” That description identifies both the missing input and the task it affects. It also helps the team see whether other work can continue while the decision is pending.
Record the owner, the next action, and the date by which the issue needs attention. A simple project board or shared document is enough. The goal is not to create a complicated reporting process; it is to keep a stalled task from becoming invisible.
Try the actions within your control
Before escalating, check what you can resolve without changing an agreed scope or making someone else’s decision. Confirm that the requirement is actually missing, look for an answer in existing project notes, and ask the person closest to the work a precise question. If a file will not open, for example, verify the link and permissions before treating it as a wider project issue.
Look for a safe workaround. A designer waiting for final copy might continue with a clearly labeled placeholder, provided the layout can be revised without significant rework. A developer waiting for approval to connect a payment system might instead work on a separate, approved feature. Make the assumption or workaround visible so no one mistakes provisional work for an approved decision.
Give these steps a reasonable time limit based on the task’s urgency. Spending hours investigating a small issue may be worthwhile if it avoids substantial rework; waiting until the day a deliverable is due is rarely helpful when another person must respond. The question is not whether you have tried everything, but whether you have tried the sensible actions you are authorized to take.
Recognize when escalation is the useful next step
Escalation means bringing an issue to someone who can provide a decision, resource, permission, or change of plan. It is not an admission of failure. Escalate when the blocker is outside your authority, when a workaround would conflict with an agreement, or when the likely delay will affect a commitment. Also escalate if the same unanswered request keeps returning or if different stakeholders give incompatible instructions.
Timing matters. If a missing approval could affect Friday’s handoff, raise it while there is still room to choose another path, not after the handoff has failed. For a less urgent issue, an agreed project check-in may be sufficient. Use the project’s communication norms where possible, but make the impact and response needed easy to spot.
Choose the right recipient. A teammate can often answer a technical question, while a project owner may need to reorder work. A client contact may need to approve a trade-off in scope, cost, or delivery expectations. When you are unsure who owns the decision, ask the project lead to identify the decision-maker rather than sending the same vague request to everyone.
Escalate with context and options
A useful escalation is brief but complete: state what is blocked, what you have checked, what happens if it remains unresolved, and what decision you need by when. For example: “We cannot finish the homepage layout until the navigation option is selected. We reviewed the approved brief, which lists both options. If we receive a choice by Tuesday afternoon, we can keep the planned review on track. Would you prefer option A or B?”
Where possible, include a recommendation and its trade-off. You might suggest proceeding with option A because it fits the existing page structure, while noting that changing it later could require revisions. Do not present an assumption as approval. If neither option is acceptable, make it easy for the decision-maker to propose another path.
Match the channel to the consequences. A short written message works for many routine decisions and creates a record. A call may help when the options are complex or a deadline is close; follow it with a written summary of the decision, owner, and next step. Keep the language focused on the work rather than assigning blame.
Close the loop and improve the process
Once the decision arrives, update the task and tell affected people what changes. If the response does not fully remove the blocker, ask a follow-up question promptly. If no response arrives by the stated time, explain the practical consequence and propose a revised sequence or schedule rather than silently letting the original plan stand.
After delivery, look for patterns. Repeated access problems may call for a setup checklist; frequent approval delays may mean decisions need earlier deadlines or a named backup approver. Not every blocker can be prevented, especially when work depends on other people. A consistent habit of defining the issue, taking reasonable action, and escalating with clear options makes those interruptions easier to manage.
