Multitasking costs you 40% of your productivity. You've heard this. It shows up in productivity blogs, corporate wellness slides, and at least one manager's opening remark before every all-hands. It's usually attributed, vaguely, to 'a study.' The study exists. It just doesn't say that.
This matters more than a fact-checking footnote, because the number gets used to make decisions. A team lead who believes interruption costs a flat 40% will reach for a blanket 'no Slack before noon' policy and call the problem solved. The actual research supports something narrower and more useful: the cost isn't a fixed tax on your day, it's a function of how often you switch, how unfamiliar the thing you're switching into is, and whether the task you left behind was finished or not. Get those three variables right and the real research tells you a lot more than a made-up percentage ever could. Much of the judgment software engineering demands shows up as process design, which is what the XenGrowth practice publishes on.
What the actual 2001 study measured
Rubinstein, Meyer and Evans ran four lab experiments having young adults switch between pairs of tasks — classifying geometric shapes under different rules, or solving arithmetic problems using different operations. Every switch cost time. The size of that cost depended on two things: how complex the rule was, and how familiar the person was with the task they were switching into. Switching into a familiar, simple task cost almost nothing. Switching into a complex, unfamiliar one cost more.
The paper's own description of the cost is 'a few tenths of a second' per switch. Nowhere in the results section does a 40% figure appear. What does appear, in a separate APA public page summarizing the research for a general audience, is lead author David Meyer's own spoken estimate that repeated task-switching 'can cost as much as 40 percent of someone's productive time.' That's a real expert's real approximation. It is not the study's measured result, and treating it as one lets a soft estimate wear the authority of a hard number.
Claim | What was actually measured | Source |
|---|---|---|
'Multitasking costs 40% productivity' | Never measured — a spoken estimate from one researcher, later published on an APA public page | APA 'Multitasking: Switching costs' |
Task-switching has a real, measurable cost | A few tenths of a second per switch, scaling with complexity and unfamiliarity | Rubinstein, Meyer & Evans, 2001 |
Interrupted work is slower | The opposite: interrupted subjects finished faster, with no drop in error rate or quality | Mark, Gudith & Klocke, 2008 |
Interrupted work is free once speed and quality hold up | No — significantly higher stress, frustration, time pressure and effort, after just 20 minutes | Mark, Gudith & Klocke, 2008 |
The study that measured the real trade-off
Seven years later, Gloria Mark, Daniela Gudith and Ulrich Klocke ran a lab study that gets closer to what an engineer actually experiences, and it produced a genuinely counterintuitive result. Forty-eight subjects played the role of an HR manager answering a folder of emails, under one of three conditions: no interruptions, interruptions on the same topic as the email task, or interruptions on an unrelated topic — the supervisor calling to ask, say, how many hot dogs to order for a company party.
The uninterrupted group took the longest to finish — 22.77 minutes on average. Both interrupted groups finished faster, around 20.3 to 20.6 minutes, with no significant difference in spelling errors or politeness. People didn't do worse work under interruption. They did the same work, faster, by writing shorter emails and moving with more urgency. For the the operations side of this angle, see The XenGrowth resource library.
Interrupted work is performed faster. That is the finding. The cost shows up somewhere else entirely: stress, frustration, time pressure and effort were all significantly higher in the interrupted conditions, measured after only twenty minutes.
The researchers' own interpretation is worth sitting with: people who expect to be interrupted develop a compensating strategy — work faster, write less, hold less slack — to protect the deliverable. It works, in the narrow sense that the deliverable gets protected. It comes at a cost that doesn't show up in any output metric, because output metrics were never built to measure how the work felt to produce.
The study's own workload measurements, taken on a standard 20-point scale right after each condition, make the trade-off concrete rather than just described. Every measured dimension moved in the same direction, and the size of the move is worth sitting with.
Workload measure (1-20 scale) | No interruption | Same-context interruption | Different-context interruption |
|---|---|---|---|
Mental workload | 10.0 | 10.8 | 11.5 |
Stress | 6.9 | 9.5 | 9.1 |
Frustration | 4.7 | 6.6 | 6.5 |
Time pressure | 11.0 | 12.7 | 12.2 |
Effort | 9.5 | 11.0 | 11.5 |
Stress alone jumped by roughly a third between the uninterrupted and interrupted conditions, and every other measure moved the same way, in a single 20-minute lab session. Extend that pattern across a working week rather than a single sitting, without ever changing the task itself, and it's not hard to see how the same compensating strategy that protects Tuesday's deadline quietly produces Thursday's exhaustion.
Where the compensation strategy runs out of road
A 20-minute lab session tells you the compensation strategy works, at least once. It can't tell you what happens when the strategy is the only mode available, all day, for years. Mark, Gudith and Klocke describe the mechanism as adaptive — people speed up because they've learned an interruption is coming and don't want it to cost them the deadline. Adaptive strategies are usually reversible: remove the interruption and the person presumably relaxes back to baseline effort. What the study doesn't test, because no lab session runs that long, is what happens when the interruption never stops coming and the relaxation period never arrives. The honest answer is that nobody has run that experiment cleanly, which is itself worth noting — a huge amount of workplace advice about interruption assumes an answer to a question the primary research doesn't actually settle. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
What is settled is the direction of the effect at the timescale that was tested, and there's no plausible mechanism by which stretching that same pattern out over months would flip it in the other direction. If twenty minutes of interruption raises stress and effort with no time to recover, a work week built the same way isn't accumulating relief — it's accumulating exactly the measures that went up.
Why this matters more for engineers than the original study suggests
Mark, Gudith and Klocke's subjects were interrupted every two minutes for the duration of a lab session — bad, but bounded, and they knew it would end. Meyer, Barton, Murphy, Zimmermann and Fritz's instrumented study of 20 professional developers found something closer to that lab condition running as the default state of a real job: outside planned meetings, developers switched activities every 0.3 to 2.0 minutes. Not occasionally interrupted. Almost continuously fragmented, all day, indefinitely.
Layer the two findings and the honest picture is worse than either study alone suggests, but in a specific, actionable way. The output doesn't collapse — engineers, like Mark's subjects, compensate. Code still ships. Tickets still close. What accumulates instead is the stress-and-effort side of the ledger, day after day, with no equivalent compensating mechanism, because there's no lab session that ends.
The familiarity variable everyone skips over
Go back to Rubinstein, Meyer and Evans for a moment, because their finding about familiarity has a practical use most retellings drop. Switch costs weren't a fixed number — they shrank when the task being switched into was familiar and well-practiced, and grew when it was novel or complex. That's a lever, not just a data point. A codebase you've worked in for two years and a codebase you joined last month impose very different switch costs for the exact same two-minute interruption, because the second one demands you rebuild context from a much thinner base of familiarity every time you're pulled away and back. XenGrowth on AI search, GEO and discovery works through AI search, GEO and discovery in more operational detail.
This is a reasonable, evidence-consistent argument for treating new hires and engineers on unfamiliar systems as more interruption-sensitive than tenured ones, not less — the opposite of how onboarding schedules are usually built, which tend to assume the newest person has the least urgent work and can therefore absorb the most context-switching. The switch-cost research suggests that's backwards: the newest person on a system pays the highest price per switch, precisely because nothing about that system is familiar enough yet to make the switch cheap.
What actually follows from this
Stop citing the 40% figure as a measured result. Cite the real finding instead: switch costs are small individually and compound with frequency, which is a better argument for reducing frequency than a made-up percentage is
Judge interruption cost by stress and effort, not by whether the ticket still closed on time. Output holding steady is not the same as the work being sustainable — it can mean the opposite
Distinguish same-context from different-context interruptions in your own reasoning, even though Mark's study found no significant difference in disruption cost between them — the intuition that a related question is 'less disruptive' isn't supported by the data, so don't design your interruption policy around it
Treat a day with constant 0.3-to-2-minute activity switches as the real baseline for engineering work, not an edge case, and design focus time as a deliberate departure from that baseline rather than assuming it's the default
If someone on your team is consistently hitting deadlines under heavy interruption, that's not proof the interruptions are fine — Mark's data says the opposite is just as plausible: they're paying for it in frustration and effort you aren't measuring
It's worth being honest about the limits of leaning this hard on two lab studies. Rubinstein, Meyer and Evans used abstract classification and arithmetic tasks, not real engineering work, and Mark, Gudith and Klocke used a simulated HR email inbox, not a real codebase under real deadline pressure. Lab conditions buy precise measurement at the cost of realism, and neither study followed its subjects for more than a single sitting. The instrumented field data from Meyer, Barton, Murphy, Zimmermann and Fritz is the piece that closes that gap — it measured real developers doing real work over real months, not a simulated task in a controlled room — and its fragmentation numbers line up with, rather than contradict, what the lab studies found. That convergence across a lab experiment, a field experiment, and a long-run instrumented study is a stronger basis for a claim than any one of the three alone, which is exactly the kind of triangulation the 40% figure never had behind it.
The real research on interruption cost is stranger and more useful than the folklore version. It isn't a tidy percentage you can drop into a slide. It's a trade: the work still gets done, and the person doing it pays for that in a currency almost nobody's dashboard tracks.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
The operational playbooks that sit alongside software engineering live with XenGrowth's work on go-to-market systems.
Four questions on the studies behind this post, not on general multitasking advice. The gap between what's commonly quoted and what was actually measured is the whole point.
