Every interruption costs far more than the interruption itself. That's the counterintuitive part, and it's why a day that felt "only a little disrupted" can produce almost no real engineering. The research on how long it takes to get back into deep work should change how any leader structures their team's day.
Key Takeaways
- After an interruption, returning to the original task takes on the order of 23 to 25 minutes (Mark, González & Harris, UC Irvine).
- Interruptions are especially disruptive to software work, hitting code comprehension, writing, and review (Duke/Vanderbilt, ICSE 2024).
- People compensate by working faster, but at the cost of more stress and errors (Microsoft Research).
- Protecting focus is one of the cheapest, highest-return moves there is.
The 23-Minute Tax
Gloria Mark and colleagues at UC Irvine ran the definitive studies on interrupted work. Their 2005 study found that when interrupted tasks were resumed, it took on the order of 23 to 25 minutes to get back to them, and people rarely went straight back; they detoured through other tasks first (Mark, González & Harris, 2005). The widely-quoted "23 minutes 15 seconds" comes from this line of research.
Her follow-on work with Microsoft Research found people do complete interrupted tasks, often faster, but pay for it with measurably higher stress, frustration, and effort (Microsoft Research). Speed bought with stress isn't a win.
Why It's Worse for Engineers
Software work is especially fragile to interruption because it depends on holding a lot of state in your head: the call stack, the data flow, the three things you were about to check. A recent study of interruptions during software engineering specifically, from researchers at Duke and Vanderbilt, documented how much they disrupt code comprehension, writing, and review (ICSE 2024). Coding state is expensive to reconstruct, so an interruption can cost a developer well beyond the 23-minute average before they're genuinely back in.
String a few Slack pings, a meeting, and a "quick question" through a morning and you've erased most of the deep work it could have held, even though none of the individual interruptions felt expensive.
| Interruptions in a morning | Deep work remaining |
|---|---|
| A few, scattered | Little to none |
| Batched / clustered | Most of it preserved |
A Concrete Version
An engineer sits down at 9am with a hard four-hour problem. At 9:40 a "quick question" in Slack, 15 minutes to answer and re-focus. At 10:30 a standup, then 20 minutes to climb back in. At 11:15 someone taps them for a "two-minute" thing. By lunch they've been interrupted three times, spent maybe 40 minutes on the interruptions themselves, and lost the other two-plus hours to rebuilding context. The hard problem is barely touched, and if you asked them, they'd say "it was a normal morning."
The Honest Counterpoint
Zero interruptions isn't the goal, and it's not achievable. Some interruptions are the job: an incident, a teammate genuinely blocked, a time-sensitive call. A team that treats every ping as a violation becomes slow and unresponsive in the ways that matter. The point isn't a monastery. It's that interruptions are far more expensive than they feel, so the default should be async and batched, with real-time reserved for things that genuinely can't wait. Protect the focus; don't fetishize it.
Protecting Focus
The fixes are cheap and mostly cultural. Default to async so a question doesn't demand an instant answer, the core of the async-first approach. Cluster meetings instead of scattering them, the same logic as protecting maker time. And normalize real focus blocks. This is also a quiet edge of well-run distributed teams: with the right timezone overlap, you get collaboration when it's needed and long, uninterrupted focus stretches the rest of the time. See available engineers.
Frequently Asked Questions
How long does it take to refocus after an interruption?
UC Irvine research found about 23 minutes on average to return to the original task. For developers the rebuild can run longer, because the coding state a task depends on is expensive to reconstruct, as a Duke/Vanderbilt study of interruptions during software work documents.
Are interruptions really that costly?
Yes. The lost time is the context rebuild, not the interruption itself. A few scattered interruptions can erase most of a morning's deep work, even when each one felt trivial.
How do I protect my engineers' focus?
Default to async communication, cluster meetings instead of scattering them, and normalize uninterrupted focus blocks. Reserve real-time only for things that genuinely can't wait.
The Bottom Line
Context switching is a tax charged on every interruption: at least the 23-minute average to get back, and longer for engineers rebuilding deep coding state. It compounds fast and invisibly. Protecting focus with async defaults, clustered meetings, and real focus time is one of the highest-return, lowest-cost moves an engineering leader can make.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
