How to Report a Blocker in a Standup in English
Learn the English phrasing for flagging a blocker during a daily standup clearly and concisely, including how to ask for help without sounding like you're making excuses.
Reporting a blocker well in a standup is a small but high-frequency skill — you do it often, in front of the whole team, usually with thirty seconds to make yourself clear. Vague blockers (“I’m kind of stuck on something”) waste everyone’s time; specific ones get you help fast and make you look competent, not behind.
Key Vocabulary
Naming the blocker specifically — stating exactly what is stopping your progress, rather than a general statement that something isn’t working, so listeners can immediately tell if they can help. “I named the blocker specifically: the staging database is returning a permissions error when I try to run migrations, and I don’t have access to fix the IAM policy myself.”
Stating what you’ve already tried — briefly mentioning the steps you’ve taken to solve it yourself, so the team knows you’re not asking them to do your first-pass debugging for you. “I stated what I’d already tried: I checked the IAM console myself and confirmed my role doesn’t have the migrate permission, so I don’t think this is something I can self-serve.”
Naming who or what you need — being explicit about who can unblock you, or what decision needs to be made, rather than leaving it to the team to figure out. “I named exactly who I needed: I asked if anyone on the platform team could grant temporary migrate access, or point me to who can.”
Estimating the impact — briefly noting what the blocker affects, such as a deadline or dependent task, so the team can judge urgency. “I estimated the impact: if this isn’t resolved by tomorrow, the API work that depends on it will also slip.”
Common Phrases
- “I’m blocked on [specific thing] — I need [specific person/access/decision] to move forward.”
- “I’ve already tried [X] and [Y], but I still can’t get past this.”
- “This is blocking [related task], so I’d like to resolve it today if possible.”
- “Could someone from [team] help me with this after standup?”
- “I’ll follow up with [name] directly after this — just flagging it here in case anyone has context.”
Example Sentences
A clear, specific blocker report: “I’m blocked on the payments integration — the sandbox API key we were given returns a 401 on every request. I’ve double-checked the key and confirmed it matches what’s in the docs, so I think it’s an account-side issue. Can someone connect me with our contact at the payment provider?”
A blocker with impact stated: “Quick blocker: the design specs for the settings page haven’t been finalized yet, which is holding up the frontend work. Not urgent today, but if it’s not resolved by Thursday, it’ll push the sprint deadline.”
Following up on a blocker from the previous day: “Following up on yesterday’s blocker — it’s resolved now, thanks to [name] for the quick help. I’m unblocked and back on track.”
Asking for a decision rather than a technical fix: “I’m blocked, but not technically — I need someone to decide whether we support the old API version or not, because the implementation is different depending on the answer.”
Professional Tips
- Name the blocker specifically — “I’m stuck” tells the team nothing; “the staging DB rejects my migration with a permissions error” tells them everything.
- Briefly state what you’ve already tried, so the team knows you’re asking for help, not for someone to redo your first debugging pass.
- Always name who or what you need, even if it’s just “anyone with context” — a blocker with no clear next step often stays unresolved for days.
- If the blocker has a deadline impact, say so — it helps the team prioritize whether to jump in immediately or after standup.
- Follow up publicly once a blocker is resolved — it closes the loop and credits whoever helped.
Practice Exercise
- Write a 20-second blocker report for a hypothetical failing test you can’t diagnose, including what you’ve already tried.
- Draft a sentence stating the impact of a blocker on a deadline.
- Write a one-sentence follow-up thanking a colleague after a blocker is resolved.
Navigating Nuances: Phrasing Blockers for Non-Native Speakers
Reporting a blocker effectively in a standup isn’t just about stating the problem; it’s about communicating that problem clearly and proactively, demonstrating ownership while requesting support. For those whose first language isn’t English, this can feel particularly challenging because subtle shifts in phrasing carry significant weight in professional communication. Let’s look at some common pitfalls and how to reframe them. A frequent mistake is using overly apologetic language – phrases like “I’m really sorry, but…” immediately imply fault and can be perceived negatively. Instead, focus on the impact of the blocker rather than your feelings about it. Another area where confusion often arises is around requesting assistance. Simply saying “I need help” can sound passive or even like you’re avoiding responsibility. More sophisticated phrasing demonstrates you’ve considered options and are seeking guidance to move forward. Finally, be mindful of technical jargon – while everyone on the team likely understands terms like “regression” or “build failure,” clarifying these terms briefly for colleagues who might not be as familiar can demonstrate respect and ensure clear understanding.
Consider this scenario: You’re reviewing a pull request submitted by Sarah. She includes a comment saying, “This is broken.” While technically accurate, it doesn’t provide enough context. A better response would be, “Sarah, I see the build failed after your changes. Could you please elaborate on what specifically triggered the failure? Knowing the error message or steps to reproduce would help me quickly understand and address the issue.” Notice how this phrasing avoids blaming (“broken”) and immediately seeks clarification, framing the situation as a shared problem needing a solution. Alternatively, imagine you’re preparing for your daily standup. Instead of saying “I’m blocked because I can’t get access to the database,” which sounds like an excuse, you could say, “I’m currently blocked on deploying this feature due to a temporary unavailability in the staging environment. The team is investigating and we anticipate resolution within the hour.” This highlights the reason for the delay – the unavailability – and demonstrates that action is being taken.
Thinking about Slack conversations too, it’s vital to frame your needs clearly. A message like “I’m stuck” isn’t helpful. Instead, try: “Hi team, I’ve encountered an unexpected error during testing (error code XYZ) while implementing the user authentication flow. I’ve tried troubleshooting steps A and B, but haven’t been able to resolve it yet. Could someone with experience in this area take a look when they have a moment?” This provides specific details about the problem, shows you’ve attempted solutions, and politely requests assistance. Remember, proactive communication is key – don’t wait until a blocker significantly impacts your work; address it promptly and clearly.
Focusing on clear, concise language and demonstrating a solution-oriented mindset will dramatically improve how your blockers are perceived and understood by your colleagues. Practice phrasing your needs in this way, and you’ll quickly find yourself communicating effectively and confidently in any professional setting.