5 exercises — raise blockers and dependencies clearly so the team can unblock you fast, and learn to tell a true blocker from a risk.
How to flag a blocker well
"I'm blocked on X — I need Y from Z" — name the dependency and owner
"This is a risk, not a blocker yet" — distinguish urgency
"I've tried A and B; still stuck" — show you attempted it first
"Could someone with database access help after standup?" — make a clear ask
State the impact — "this blocks the release" raises the right urgency
0 / 5 completed
1 / 5
Which is the clearest way to flag a blocker?
A good blocker statement names what is blocked, what you need, and who owns it: "blocked on the payment integration — I need the API credentials from the platform team." This gives the team everything required to unblock you immediately.
"Kind of stuck" and "things aren't going great" are too vague to act on, and "I'll mention it later" defeats the purpose of standup, which exists partly to surface blockers early. Always pair the blocker with the specific dependency and its owner.
2 / 5
What is the difference between a blocker and a risk, and how should you phrase a risk?
A blocker halts your progress right now; a risk is a potential future blocker. Distinguishing them sets the right urgency: "Not blocked yet, but if the staging env isn't ready by Thursday, it'll delay testing" gives the team time to prevent the problem.
Treating them as identical either over-alarms the team or buries genuine risks. Surfacing risks early — with the condition and the consequence — lets the team act before they become blockers, which is exactly what makes standups valuable for coordination.
3 / 5
Before raising a blocker, what should you ideally be able to say?
Showing what you have already tried ("tried restarting and checking the logs; the error persists") respects your colleagues' time and helps them skip the obvious suggestions. It also demonstrates ownership before asking for help.
Raising a blocker before investigating ("haven't looked at it yet but I assume...") or expecting others to do it for you ("fix it for me") shifts your work onto the team. A brief summary of your attempts turns "I'm stuck" into a targeted, efficient request for the specific expertise you need.
4 / 5
How do you make a clear, actionable ask for help in standup?
An actionable ask specifies who, what, how long, and why it matters: "someone with prod database access pair with me for 30 minutes... it's blocking the migration." People can immediately decide if they can help and understand the urgency.
Vague asks ("help at some point", "help with everything", "Help") put the burden on others to figure out what you actually need, which usually means no one volunteers. The clearer and more bounded the request, the faster someone says yes.
5 / 5
Your blocker depends on another team that is slow to respond. What is the professional way to raise it?
Raise cross-team blockers by stating facts, the wait time, the impact, and a path forward: "waiting two days... could our lead help escalate? It's now blocking the release." This is constructive and gives someone a concrete action (escalate).
Insulting the other team ("useless and never replies") is unprofessional and unhelpful. Giving up abandons the work; waiting silently lets the delay compound. Framing it factually and asking for escalation gets the dependency moving without burning a relationship with the other team.