Everyone Says They're Not Blocked. The Project Still Is.

We were shipping a billing page built around a payment webhook: charge succeeds, charge fails, or the card gets flagged for manual review. Frontend owned the checkout UI. Backend owned the webhook handler and the event contract, the exact JSON shape that would tell the frontend what actually happened to a charge. QA owned the end-to-end path that needed both sides to agree on that shape before anything could be tested against something real.

Standup sounded clean.

Frontend: "Not blocked. Polishing the form and error states against mocks." Backend: "Not blocked. Cleaning up retry logic for failed webhook deliveries and adding more logging." QA: "Not blocked. Writing cases for success, decline, and double-charge."

Nobody raised a hand. Calendars were full. Tickets moved. The ship date still slipped another day. Then it slipped again.

Two different meanings of "not blocked"

On a small team, "any blockers?" usually means are you personally stuck right now?

That question misses two layers at once.

First: people can honestly say they are not blocked because they still have work. Frontend can polish against mocks. Backend can tidy retries without finishing the event shape. QA can write scenarios for a handshake that does not exist yet. Locally true. Release still waiting.

Second: the wait is cross-role. Frontend needs a stable payment event. Backend needs frontend to stop assuming fields that will change. QA needs both. That edge does not show up when each person reports their own ticket. There is no standup subject named "the webhook contract."

So you get a room full of "I'm fine" while the project is not.

What dependency visibility actually means

Dependency visibility is not another personal board. It is whether you can see the edge: who is waiting on whom, and whether that wait moved since yesterday.

For the billing page, that edge was one line in a spec: the exact fields in the webhook payload, and what backend would send when a charge failed versus got flagged for review. Until backend locked that shape, frontend was building against a guess and QA was writing tests for a contract that did not exist yet.

Without dependency visibility, you infer the whole project from personal status. With it, you can ask a different first question: did the cross-role edge move?

I have written before about busy standups and a stuck critical path. That post was about activity sounding like progress. This one is adjacent but sharper: people can be unblocked as individuals and still leave the release stuck on a handoff nobody owns in the meeting.

Why boards and standups miss the edge

Boards optimize for ticket owners. Standup scripts optimize for personal status. Cross-role edges often have no single owner in that script, so they never become a sentence someone is responsible for saying out loud.

Frontend reports UI. Backend reports infra polish. QA reports prep. Each update is honest. Nobody is lying. The missing line is "the payment event contract is still open, and everything that ships still hangs on it."

I have watched this at other jobs. Design waits on eng. Eng waits on a partner API. QA waits on both. Every standup stays green because everyone finds adjacent work: design polishes a flow around fields the API hasn't confirmed, eng wraps an endpoint that isn't final, QA drafts a test plan for a contract that keeps moving. Everyone reports real progress on their own slice. Nobody reports that the one thing gating the release, the partner API response shape, hasn't moved in a week.

Looking at the handoff

What changed for me was not a better "any blockers?" ritual. It was keeping the graph open while people talked.

On a dependency graph, the stuck edge is visible whether or not anyone volunteers it. Our webhook contract task had one comment on it, four days old: "need to confirm idempotency key format with the payments provider." Nothing since. That single line said more about the ship date than three green standups put together.

You can start with one question: did the webhook contract move? If no, the polish and the draft cases are context, not proof the release moved. Dependency-aware sprint planning only helps here because the schedule is built on those edges, not on who sounded freest in standup.

Ravel does not replace the conversation. It keeps the handoff visible so "not blocked" stops being the only signal in the room.

What I ask now

Next standup on a graph-shaped release, I start with the cross-role edges, then hear personal updates.

If the handoff moved, the busy work matters and I want it. If it did not, we talk about that edge before we congratulate ourselves for polishing around it.

If you have a ritual that catches "nobody is blocked / the project still is" without a graph, I want to hear it. Named owner for the handoff? Explicit edge review at the top of standup? Hope and Slack?

We're building this at theravel.app. Take a look, or tell me what you use instead.