Dead air with a countdown attached
You start a deploy, an upload, an export, or a full CI run. For the next few minutes or the next two hours the machine is busy and you are not. Two things are true about that gap and they pull against each other: it ends at a roughly predictable time, and it demands your attention the instant it does.
That combination is what makes machine waits go wrong. The gap feels like permission to drift, so twenty minutes later there is neither a build result nor progress on anything else. Or you overcorrect, start something genuinely demanding, and cannot put it down when the pipeline turns red.
Waits on people work differently, because there is no completion sound and no estimate worth trusting. Those are covered in what counts as productive work while waiting. This article is only about machines.
Rank the work that fits a machine wait
Decide before you press the button, not after. The ranking is by switching cost, because the machine will interrupt you and you want that interruption to be cheap.
Best: same project, no new context. Write the commit message or the release note. Update the ticket with what you just shipped. Sketch the next test case. Add alt text. Tidy a folder you already have open. You stay inside the same mental model, so returning to the result costs nothing.
Good: admin that was already going to happen. Send the invoice you had planned. Confirm a meeting time. File a receipt. Answer the one message that needs a single line. These are cheap to abandon mid-sentence.
Fine: prepare the verification. Open the health check page, find the log query, pick the frames of the export you intend to inspect. This is the most underrated option, because it makes the moment of completion productive instead of chaotic.
Also fine: rest. A ten-minute wait does not have to become output.
Bad: anything with no pause point. A second deep task in another codebase, a refactor, a research thread, a redesign of yesterday's slides. When the build fails you will either ignore the failure or lose the thread you just built.
The mechanism that makes this work is a short written list, made before the process starts. Two or three items, matched to the expected duration. For a two-minute compile, stand up. For a ten-minute deploy, update the ticket and draft the change note. Without the list, attention goes looking for entertainment and finds it immediately.
Do not trust the estimate exactly. Progress bars stall and CI queues grow. Choose work you can stop at the end of a sentence, and keep the completion signal somewhere you will actually notice it.
A two-hour build, handled properly
A feature branch merges and the full pipeline takes roughly a hundred minutes. Recent runs, not the best run ever, are what you plan against.
13:15. Push and start the run. Before switching away, write the verification step: "check the migration job log, then load the checkout page on staging." Track the run as background work on the dashboard with a reminder rather than an open pipeline tab.
13:20 to 14:10. One real block on the release notes for tomorrow's deploy. This is the ideal long-wait task because it uses the context you already have and pauses at any paragraph.
14:10 to 14:20. Break, away from the screen. Glance at the pipeline once on the way back, not four times before that.
14:20 to 14:50. Admin batch: two invoice lines, a calendar decline, a short review reply. Nothing that takes more than fifteen minutes.
14:50 to 15:00. Reread the acceptance checks on the ticket and prepare the staging screenshots folder so review is one click.
15:00. Run finishes. Verify immediately, using the step written at 13:15. If it is green, open the pull request. If a job failed, read the first failure and classify it: code, flaky test, or infrastructure. Fix only a code failure belonging to this branch. An infrastructure outage is a blocker for the handoff, not a project for the rest of the afternoon.
The point is not the specific tasks. It is that nothing in the timeline needed more than a sentence of warning to abandon at 15:00.
What never goes in a waiting window
- A task that will still be open when the process finishes.
- Anything that takes you physically away with no alert, so a failed run sits unnoticed for an hour.
- Three long processes stacked deliberately so you never have to focus at all.
- Treating a green notification as success. The smallest relevant check, done immediately, keeps the original context available if something is wrong.
- Opening chat "just while I wait." That is where the accidental second project comes from.
If machine waits are part of most days, keep a short reusable menu beside the daily plan (daily work plan). Five to eight recurring options are plenty, and any item that keeps growing into real work comes off the list. It is a menu, not a backlog, and its job is to stop an impulsive inbox visit while leaving you free to respond the moment the machine needs you.
Waits fit into the wider day shape in how to structure a remote workday. If the thread keeps snapping after every wait, the cue you left behind was too weak: why remote workers need a clear next action.