Quick answers
- What is a blocker at work?
- Anything that stops you from completing a task—a missing dependency, access, decision, or technical issue.
- How do I report a blocker?
- State what's blocking you, why it matters, and what you've already tried or requested.
- When should I escalate a blocker?
- When you've waited longer than expected or when the blocker risks the sprint or deadline.
What it is
In agile and engineering workflows, a blocker is an impediment—a dependency, a bug, a missing decision, or a lack of access. Standups and status updates often include a "blockers" section. The goal is to state the blocker, its impact, and what you've tried so the team can help.
Why it matters
Unclear blocker descriptions delay resolution. Saying "I'm stuck" doesn't help. Saying "I'm blocked on the auth service—we need a staging token and I've asked DevOps" gives the team a clear path. Good blocker communication builds trust and speeds up delivery.
Instead of → Say
| Instead of | Say |
|---|---|
| I'm stuck | I'm blocked on the deployment—I need access to the production keys |
| Something is broken | The CI pipeline is failing on the new test suite |
| I can't continue | I'm waiting on the design approval before I can implement the flow |
| I don't have the thing | I need the API schema from the backend team to finish the integration |
| There's a problem | The staging environment is down—I've pinged infra |
Example dialogue
Manager: Any blockers this week?
You: I'm blocked on the payment integration. Stripe's test mode works, but we need production credentials. I've filled out the access request and tagged the team lead.
Manager: How long have you been waiting?
You: Two days. I can switch to the fraud detection task in the meantime if that helps.
Manager: Let me follow up with them. Anything else?
You: No, that's the only blocker.
Common mistakes
- Being vague—"something is wrong" doesn't help
- Waiting too long to raise a blocker
- Not mentioning what you've already tried
- Burying the blocker at the end of a long update
- Assuming others know the context
Frequently asked questions
- When should I raise a blocker?
- As soon as it prevents you from making progress. Don't wait for the next standup if you're blocked for more than a few hours.
- How do I explain a technical blocker to non-technical people?
- Use plain language: "The system that handles payments isn't set up for our environment yet. I've requested access and I'm waiting on approval."
- What if I'm blocked by another person?
- Be factual: "I'm waiting on the API design from [name/team]. I've sent a follow-up." Avoid sounding accusatory.
- Should I suggest a solution when raising a blocker?
- If you have ideas, share them: "I'm blocked on X. I've tried Y. One option is Z—should I proceed?" It shows ownership.
- What if the blocker is my fault?
- Own it: "I'm blocked because I need to fix the migration script first. I'll have it done by tomorrow." Transparency builds trust.
Ready to practice?
Start practicing with our available scenarios and get instant feedback.
Start practicing