Recognize when a question has become a blocker
Every creative project includes questions. A blocker is a question or dependency that prevents you from making meaningful progress on an agreed task. You might be waiting for approval on a design direction, access to a shared folder, a decision about scope or feedback needed before you can revise a draft. The distinction matters: a minor uncertainty may be something you can note and work around, while a blocker needs someone else’s attention.
Look at the next concrete step, not just your overall workload. If you cannot take that step without an answer, identify who or what you depend on. Then consider what happens if the answer arrives later: will a handoff slip, will someone redo work, or will the team have fewer options? You do not need to predict an exact delay. Naming the likely effect is enough to show why the issue deserves attention.
Share what you know before the problem grows
It can feel tempting to wait until you have tried every possible fix. A short, early update is usually more useful than a complete explanation delivered after a deadline is at risk. First, do a reasonable check: review the project brief, look at the latest decision record and try a straightforward workaround if it is safe to do so. Avoid spending a long stretch investigating a dependency that only another person can resolve.
When you raise the blocker, separate facts from assumptions. For example: “I can’t export the final graphics because I don’t have access to the approved asset folder. I checked the project permissions and the shared links I have. If access is granted, I can continue with the export.” This tells a collaborator what has happened without implying that anyone is at fault. If you are unsure whether an issue will affect delivery, say so and explain what you need to confirm.
Make the request easy to act on
A useful blocker message answers five questions: What task is affected? What is stopping it? What have you already tried? What help or decision do you need? When do you need it to protect the next step? Keep the message brief enough to scan, but include links or file names that help the recipient find the relevant work. “I’m stuck” signals a problem; “Could you confirm which of the two approved headlines to use?” gives someone an action.
Choose the person most able to help. A project lead may need to decide between two directions, while a teammate who manages files may be able to fix an access issue. If you do not know who owns the decision, ask your main contact to point you to the right person rather than sending the same vague request to everyone. Use the team’s usual project channel or task record so the answer remains visible to people who depend on it.
Make urgency specific rather than dramatic. You could say, “I need the headline decision before I lay out the remaining pages; otherwise I’ll pause that part and continue with the image selections.” This gives others a reason to respond and shows how you will use your time in the meantime. If a delivery commitment is already at risk, state that plainly and ask whether the team wants to change the priority, scope or handoff plan.
Keep moving without hiding the risk
While waiting, identify work that does not depend on the answer. A student team might prepare presentation notes while a collaborator confirms the prototype flow. A freelancer might organize export settings while a client reviews copy. A small design team might document the two viable options so a lead can decide quickly. These actions reduce idle time, but they should not conceal the blocker or turn an unapproved assumption into a final decision.
Record the issue where the team tracks work. A compact note can include the affected task, the owner of the next action, the requested decision and the current status. If the answer does not arrive when needed, follow up in the same thread with the consequence: what is now paused, what can still proceed and whether the planned handoff needs to change. This creates a shared view of the work rather than relying on someone to remember a private conversation.
Close the loop after the blocker is resolved
Once you have an answer, acknowledge it and state your next step: “Thanks, I’ll use headline B and share the revised layout for review.” Update the task record if the decision changes the brief, the deliverable or the review plan. That small step prevents a teammate from working from an older assumption.
After delivery, notice whether the blocker points to a repeatable improvement. If missing access slowed several tasks, add an access check to the project kickoff. If unclear approvals caused rework, name a decision owner in the next brief. Raising a blocker early is not a sign that you cannot handle the work. It is a way to give collaborators the information they need to help—and to keep the project honest about what can happen next.
