To capture blockers in async work, write down three things every time: what is blocked, who owns the unblock, and the current status. Put those three into a record you can query later, not a chat message that scrolls away by lunch. A blocker that lives only in a thread is a blocker nobody can find again, which means it quietly becomes a blocker nobody fixes.
The problem with async blockers is not that people fail to mention them. People mention them constantly. The problem is where they land. A blocker typed into a busy channel gets two reactions, then sinks under the next forty messages. By the time someone asks "wait, are we still stuck on the API keys," the original message is impossible to find and nobody is sure who was supposed to handle it.
What does it mean to capture a blocker?
Capturing a blocker means turning a passing comment into a structured record with three fixed fields: the blocker itself, the owner of the unblock, and the status. A blocker is anything stopping work from moving forward, like a missing credential, an unanswered question, or a dependency on another team. Capturing it well means a stranger could read the record in a month and know exactly what was stuck and who was on the hook to clear it.
The difference between mentioning and capturing is whether the information survives. A mention is a message. A captured blocker is a record with a name on it. When you mention a blocker, you are hoping the right person saw it. When you capture one, you have made it findable on purpose, so the answer to "what is blocking the launch" is a query, not an archaeology project.
Why do blockers vanish in chat?
Chat is built for flow, not for retrieval. Each message is meant to be read once, in the moment, and then make room for the next one. A blocker has a long life, sometimes days or weeks, but the message announcing it has the lifespan of a goldfish.
There is also the ownership gap. When you post "we're blocked on the vendor contract" into a channel, you have named the blocker but not the owner. Everyone assumes someone else has it. Diffusion of responsibility does the rest, and the blocker sits there because it belongs to no one in particular. The fix is to make the owner part of the record itself, so there is always a named person to ask.
The third reason is status. A blocker moves from new, to in progress, to cleared, and a chat message captures only the moment it was posted. Three days later the message still says "blocked," even if the thing got fixed, so nobody trusts it. A record that carries a live status is worth far more than a frozen sentence from Tuesday.
How do you capture a blocker so you can find it later?
Record the same three fields every single time, and put them somewhere a person can later query by plain question rather than by scrolling.
The blocker is the what. State it concretely. "Blocked on staging access for the new contractor" beats "blocked on access stuff." A vague blocker is almost as useless as no blocker, because the next reader still has to go ask what it meant.
The owner is the who. This is the person responsible for clearing it, which is not always the person who hit the wall. If you are blocked because Finance has not approved a tool, the owner of the unblock is whoever can get Finance moving, and that name belongs in the record. Naming a single owner is the same discipline behind good async handoffs: one person carries the thread so it does not get dropped between two assumptions.
The status is the where-are-we. New, working on it, or cleared. Keep it current, because a blocker record that lies about its own status is worse than no record, since people will trust it and be wrong.
What's the difference between mentioning a blocker and declaring one?
Mentioning a blocker leaves it as searchable text. Declaring one turns it into an answer a person stands behind. This distinction sits at the center of how StandIn handles blockers, and it is worth slowing down on.
StandIn auto-indexes your work, which makes your updates, commits, and notes discoverable and pointable. That handles the finding problem: the system knows where your blocker lives. But indexing alone does not make a blocker trustworthy, because indexed text is just text someone might have typed in passing. Declaring is the separate, human step where you vouch for the blocker as real and current.
That is why a declared blocker answers questions that a chat message cannot. Ask the record "what is blocking the payments release," and you get the blocker, the named owner, and the status, sourced to the person who stood behind it. Ask about a blocker nobody declared, and the honest answer is "no record," which tells you the question is still open rather than handing you a stale guess. The refusal is information. You can see the full path from indexing to declaring in how StandIn works.
Chat message vs. a captured blocker record
| What you need | Blocker in chat | Captured blocker record |
|---|---|---|
| Find it next week | Scroll and search | Ask a plain question |
| Know who owns the unblock | Often unclear | A named owner on the record |
| Trust the status | Frozen at post time | Current and declared |
| Ask "what's blocking X" | Reread threads | Get a sourced answer |
| When nothing is recorded | Silence or a guess | A clear "no record" |
The right column is not a tidier inbox. It is the difference between a team that can answer "are we still stuck on this" in seconds and one that argues from memory.
How does this help across time zones?
Async teams feel blocker loss the hardest, because the person who hit the wall is often asleep when the person who can clear it logs on. If the blocker lives in a captured record, the second person reads the what, the who, and the status, and acts without waiting for an overlap window. No standup needed, no "ping me when you're up."
It also protects you when people leave or rotate off a project. A blocker someone carried in their head walks out with them. A declared blocker stays put, owner and status intact, so the next person inherits the real state of the work. That durability is the quiet payoff of capturing blockers properly: the record outlives the conversation, and the team stops solving the same stuck problem twice.
Frequently Asked Questions
What are the three things to record for every blocker?
The blocker itself, the person who owns the unblock, and the current status. Those three fields make a blocker findable, owned, and trustworthy long after the original conversation is gone.
Why isn't posting a blocker in Slack enough?
A chat message scrolls away, names no clear owner, and freezes the status at the moment you posted it. A captured record stays findable, carries a named owner, and keeps the status current.
Does StandIn report blockers for me automatically?
It indexes your work so blockers are discoverable, but it only treats a blocker as an answer when you declare it. It never invents a blocker or its status on your behalf, and it says "no record" when nothing was declared.
Who should be the owner of a blocker?
The person who can actually clear it, which is not always the person who got stuck. If you are blocked by another team's approval, the owner is whoever can move that approval forward.
How do I keep a blocker's status from going stale?
Update the status on the record, not in a new message, so there is one place that tells the truth. New, in progress, and cleared are usually enough, as long as you keep it current.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.