Say it early and say it with evidence. A good blocked message states what you are trying to do, what you tried, what exactly is in the way, and what you need. Engineers who flag blockers this way look more capable, not less, because they protect the timeline and respect other people's time.
What people tell me
When I get stuck at work, I usually keep trying for a long time before saying anything, sometimes days, because I do not want people to think I cannot handle my tasks. Then the deadline gets close and I have to admit I am behind, which feels even worse. I want to know when and how to tell people I am blocked without looking incompetent.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Being blocked is normal. Hiding it is what damages trust.
- Use a time box: once you have made honest progress for a set time and are still stuck, say so.
- Structure the message: goal, what you tried, the exact blocker, what you need.
- Separate being stuck on a hard problem from being blocked by someone else. Both deserve early mention.
- Follow up with what solved it, so people see the loop close.
Hiding the blocker is the real risk
Nearly every engineer I talk to has a version of this story. They got stuck, did not want to look weak, kept trying quietly, and then had to deliver bad news right before the deadline. The irony is that the silence did far more damage to their reputation than asking would have.
From a lead's point of view, being blocked is completely normal. Every engineer is blocked several times a week: by unclear requirements, missing access, another team's API, a bug that makes no sense. What matters is how quickly the team learns about it, because that decides whether it costs an hour or a sprint.
Know when to speak up
Use a simple rule so the decision is not emotional:
| Type of blocker | When to raise it |
|---|---|
| Waiting on access, credentials or another team | Immediately, because nobody can solve it by trying harder |
| Unclear requirement or conflicting instructions | As soon as you notice, before building the wrong thing |
| Technical problem you are investigating | After a fixed time box, for example one to two hours of honest effort |
| Anything that will affect a deadline | The moment you suspect it, not when you are certain |
The last row is the one people ignore most. "This might slip" on Tuesday is useful. "This has slipped" on Friday is a problem.
A message structure that works
Good blocked messages have four parts:
- Goal: what you are trying to do.
- Progress: what you tried and what you learned.
- Blocker: exactly what is in the way.
- Ask: what would unblock you, and by when it matters.
For example:
I am adding the refund status to the orders page. I have the UI and API changes working locally. I am blocked because the payments service returns 403 for the refunds endpoint from our staging environment. I checked our service credentials and they match the docs. Could someone with access to the payments config confirm whether our service is allowed to call that endpoint? I can keep working on tests until then, but I will need it by Thursday to stay on schedule.
Nobody reads that and thinks you cannot solve problems. They see someone who has done the work, narrowed the issue and is protecting the timeline.
Compare it with:
The refunds thing is not working, can anyone help?
Same problem, very different impression.
Stuck versus blocked
It helps to separate these in your own head:
- Stuck means the problem is yours to solve, but you have not found the way yet. Asking for a second pair of eyes after your time box is sensible. Bring your hypothesis and evidence.
- Blocked means something outside your control is in the way. Raise it immediately, and work on something else in the meantime.
Saying which one it is helps people respond. "I am stuck on why this query is slow, can I get fifteen minutes with someone who knows the indexes?" is a different request from "I am blocked on database access."
Where to say it
- In stand-up or the team's update thread, briefly, so everyone knows.
- Directly to the person who can help, with the full message.
- To your lead, if it affects a deadline or needs a decision.
Public channels are usually better than private messages for technical questions, because others may know the answer or have the same problem. It also makes your progress visible.
Keep moving while you wait
Being blocked on one part rarely means you have nothing to do. Mention what you will work on meanwhile: writing tests, handling edge cases, updating documentation, or starting the next task. It shows you are managing your time, not waiting to be rescued.
Close the loop
When the blocker is resolved, say so and share what fixed it:
Resolved: the staging service needed the refunds scope added. Added a note to the setup docs so the next person does not hit this.
This tells the team the risk is gone and often prevents the same problem for someone else. Over time, people learn that when you raise something, it is real, and that when you fix it, it stays fixed. That is what trust looks like.
If you are still stuck
Read The Habits That Make an Engineer Worth Routing Work Through and What Actually Changes in Your First Two Years as an Engineer. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.