What the research says about attention residue

Engineers, SREs, and tech leads who live in fragmented calendars: PRs opened across days, incidents that interrupt design, Slack threads that reopen mental threads you thought you closed.

This is not medical advice. If you need clinical guidance, talk to qualified professionals—here we only discuss workflow-level causes and mitigations.

In organizational psychology, Sophie Leroy and collaborators popularized the attention residue framing: moving tasks is not a pure CPU context switch; humans carry forward goals, open loops, and partial plans. Stopping mid-task can leave a cognitively expensive “appendix” running in the background.

Developers experience this in very concrete forms: you were one printf away from confirming a theory; you were mid-merge conflict; you were holding a six-variable invariant across four files. When the standup starts anyway, the code does not pause cleanly—your working memory keeps paying rent.

Software work has long hidden state: branches, caches, failing tests, half-written migrations. That state is expensive to reconstruct—see context switching and recovery for developers. Residue is the subjective side of the same coin: you are slow not because the new task is hard, but because the old task will not shut up.

Tooling makes it worse when every tab is a to-do: Slack, email, CI, dashboards, docs. Each surface is a potential reopen loop.

Laboratory and field-adjacent studies in this family generally support a cautious claim: switching is costly, and unfinished business increases the odds you are still processing the prior task while attempting the next. Effect sizes and durations vary by measurement, incentives, and task design.

Treat published numbers as directional, not as a personal stopwatch. Your team's incident severity, codebase familiarity, and review latency change the shape of the day more than any single effect-size headline.

Reload cost is the work to answer “where was I?” after you return to the same task. Residue is the work your mind still spends on Task A while you are supposedly on Task B. They interact: high residue makes reload feel longer even when the clock says you “switched back” quickly.

For planning language on minutes—not vibes—read how long to refocus after an interruption.

• Write a one-line parking brake. Before you switch, capture the next action you would have taken (“repro with empty cache”, “check migration 0147 order”). This is cheap external memory.
• Shrink WIP. Fewer concurrent epics means fewer hot threads competing for background cycles.
• Prefer closures at natural seams. End after a test run, after a commit, or after a note—avoid stopping mid-merge unless reality forces it.
• Use bounded blocks intentionally. A sprint timer does not erase residue, but it can make “finish enough to park” easier to plan—see what is a coding sprint.

• It does not prove a specific universal minute count for every engineer.
• It does not prove that any one app removes residue—only that boundaries and closures matter.
• It does not replace team design: on-call load and meeting culture dominate many weeks.

Attention residue is a useful name for a familiar drag: unfinished technical threads are expensive to park and expensive to resume. If your days feel “sticky,” start with closures and WIP before you buy another subscription.

Nedio fits as a container: one defended maker block with a visible end. It does not solve organizational interrupts—but it can make “finish enough to write the parking line” more common.