Skip to content

Reporting Blockers & Asking for Help

Getting stuck is normal. What separates someone a team trusts with ownership from someone who quietly drains a senior's day is how they ask for help — and whether they ask at all.

When this matters

The moment you notice you can't move forward without more information, a decision, or access you don't have. Also the moment you're tempted to sit on a problem because asking feels like admitting failure — that instinct is usually wrong, and the cost of staying silent almost always compounds.

The practice

Run the COURT test first. Before you ask anyone anything, sort the blocker into one of two courts: is this your court — something you can resolve yourself by trying another angle, testing more, or checking the docs — or is it someone else's court — a real decision that needs authority or context you don't have (scope, priority, an ambiguous requirement, "which of two reasonable readings is right")? Most things that feel like blockers are actually your court.

Escalate political, not technical. Being stuck, or a problem being hard, is never by itself a reason to hand it to someone else — the right response to technical difficulty is to raise your own rigor: try a different approach, write a smaller test to isolate the problem, double-check your assumptions, read one more layer down. Save an actual escalation for genuine scope/rule/ ambiguity questions — a decision only someone with more authority or more context can make.

State your assumptions before you ask. If you're uncertain about what's being asked of you — as opposed to how to do it — say so out loud rather than silently picking an interpretation and hoping it's right. Surfacing "I read this two ways, which did you mean?" early is cheap; discovering you built the wrong thing later is not.

Interrupt for real blockers, batch the rest. If you genuinely cannot make any further progress until someone answers, raise it now — don't sit on a true blocker to avoid bothering anyone. But if it's a question or observation that doesn't stop your current work, don't interrupt for it — note it and fold it into your next regular status update instead (see Communication & Status Updates' Risks/asks line).

Make the ask answerable in one line. "I'm stuck" forces the other person to do the diagnostic work you should have done. Name the one decision you need, show what you already tried so nobody re-treads it, and offer your own recommendation — a concrete ask with options is something a busy person can resolve in a sentence.

Name an owner. Every real ask should go to a specific person who can actually make the call — not into a channel and hope someone notices.

Checklist

  • Is this actually a decision only someone else can make — or can I resolve it myself by trying harder, testing more, or picking the sensible reading and saying so?
  • Have I named the one decision I need, in a single sentence — not a vague "I'm stuck"?
  • Did I say what I already tried, so the reader isn't repeating my work?
  • Did I offer options and my own recommendation, not just the problem?
  • Is this a genuine blocker (interrupt now) or a non-blocking question (batch into the next update)?
  • Did I address it to a specific owner?

Template

Blocked on: <the one thing stopping you>

What I tried:
- <attempt 1>
- <attempt 2>

The decision I need:
<one sentence — the actual choice someone else has to make>

Options:
1. <option A> — <tradeoff>
2. <option B> — <tradeoff>
My recommendation: <which one, and why, in one line>

Owner: <who this needs to go to>

Adapted from

  • SE's heartbeat-protocol skill — the COURT split: operator court for genuine scope/rule/ ambiguity decisions (a mandatory, one-line ASK naming a concrete question, addressed to an owner) versus system court for things that resolve themselves without a human decision.
  • role-runtime/docs/CONSTITUTION.md (Court annex) — "operator court is for political decisions, not technical ones"; technical difficulty is answered by raising your own rigor, never by escalating.
  • SE's coding-guardrails skill — state your assumptions out loud, and ask rather than guess when a request has more than one reasonable reading.

Practice it

Ask the onboarding-tutor: "I'm stuck on <my current blocker> — help me work out whether this is my court or someone else's, and if it's a real ask, draft it with the blocker template."