Fill The Wait

Fill The Wait

A blocking wait is dead time only if you let it be. A 30s+ install, build, test, or deploy is a window to advance an independent lane.

The move

1. Recognize the wait. You dispatched a command that won't come back for a while (install, build, test, deploy, big fetch). Don't sit idle.
2. Pick an independent in-lane task. It must be:
   • In your lane (see lane-discipline).
   • Independent of the running op's output — you can't fill a wait with the task that needs the wait's result.
   • Small enough to make progress in the wait window — if the wait is 30s, pick a 30s-task; if it's 10m, you can take a real task.
   • Non-conflicting — doesn't edit the same files the running op is building/testing.
3. State it. "While the install runs, I'll instrument the training script." This makes the parallelism visible and explains the second ◼ on the board.
4. Update the board. A second ◼ for the fill task is correct here (see progress-board's backgrounded-op rule).
5. Reap the original op when it returns. Don't get so deep in the fill task that you miss the original op's completion/failure. Check its result, then decide: finish the fill task, or return to the original lane.

Good fill tasks

• Instrumenting / wiring a script that the running op doesn't touch.
• Writing docs, an OKF bundle, or a review that's independent of the build.
• A sibling SME review lane (see sme-fanout).
• Reading a sibling file to plan the next task (see match-conventions) — a read is always safe and never conflicts.

Bad fill tasks

• Anything that edits the files the running op is building or testing → race condition.
• Anything that needs the running op's output → not independent.
• A task in another agent's lane → lane-discipline violation.
• A destructive op → if it fails, you're now juggling two failures (see background-failure-triage).

When NOT to fill the wait

• The wait is short (< ~30s). The context-switch cost exceeds the gain.
• There's no independent in-lane task ready. Idling is fine; inventing work to fill a wait creates low-value churn.
• The running op is fragile and needs you to watch it (a deploy you might need to roll back).

Pair with

• progress-board — the second ◼ is the visible signal that you're filling the wait.
• cost-transparency — a 5m wait is a 5m fill window; a 30s wait isn't worth a fill task.
• background-failure-triage — if the running op fails while you fill, triage at the next boundary, don't panic-abort the fill.