Gloria Mark at UC Irvine has been measuring workplace attention for nearly two decades. The finding that holds up across every study: after a single interruption, it takes an average of 23 minutes and 15 seconds to fully return to the original task. Not 23 seconds. Twenty-three minutes.
For product managers watching a sprint unfold, that number should change how you think about every interaction with your engineering team during the build phase.
The Math That Changes Behavior
Gerald Weinberg calculated the overhead in Quality Software Management back in 1992, and the math hasn’t aged. A developer working on two concurrent efforts loses about 20% of productive time to switching overhead. At three, 40% evaporates. By five simultaneous workstreams, roughly 5% of productive capacity remains per project.
Most PMs don’t assign engineers to five projects at once. But they create five-project cognitive loads through interruptions. A Slack message about a different feature. A “quick sync” about next quarter’s planning. A request to review a document unrelated to the current sprint. Each one triggers the same penalty.
Sophie Leroy at the University of Washington identified the mechanism: when someone switches from Task A to Task B, part of their cognitive processing stays allocated to Task A. She coined the term “attention residue.” The person isn’t fully present on the new work. They aren’t fully present when they return to the old work, either.
Five Ways PMs Create Context Switches Without Realizing It
The “quick question” in Slack. It takes you 15 seconds to type. It costs the engineer 23 minutes of recovery. If the question isn’t blocking your work right now, batch it.
Mid-sprint scope adjustments. “Can we also add…” is the most expensive sentence in product management. Even small additions force engineers to rebuild their mental model of what “done” looks like. Atlassian’s 2024 State of Teams research found that 78% of engineers say they struggle to complete primary work because of competing demands during the sprint. Those competing demands often originate with the PM.
Status check meetings that duplicate the sprint board. A Fortune analysis of Atlassian’s meeting data found that 72% of meetings are ineffective at accomplishing their stated purpose, and 76% of workers say meeting-heavy days leave them drained. If your sprint board already shows status, another meeting to discuss it is a pure context switch with zero information gain.
Pulling engineers into discovery during the build phase. Discovery is essential. But scheduling a customer interview with an engineer mid-sprint trades tomorrow’s shipped feature for today’s research insight. Both matter. Sequencing them matters more.
Requesting estimates on future work while current work is in progress. Estimation already carries its own risks. Asking an engineer to switch from writing code to sizing a feature they haven’t thought about forces two fundamentally different cognitive modes into the same hour.
What It Looks Like When the PM Absorbs Instead of Distributes
During a network infrastructure rollout early in my IT operations career, I routed every stakeholder question straight to the engineering team. I thought I was being transparent and collaborative. What I was actually doing was turning a four-week project into a seven-week project. Engineers spent more time answering questions about their work than doing their work.
The fix was embarrassingly simple. I became the single point of contact for all inbound questions during the build phase. I kept a running document of answers, updated stakeholders on a fixed cadence (twice per week), and batched all non-urgent engineering questions into one 15-minute block per day.
The next rollout of comparable scope finished in three and a half weeks.
That pattern maps directly to product management during sprint execution:
Batch your questions. Instead of seven Slack messages across the day, collect them and ask in one conversation. One context switch instead of seven.
Protect the morning. Shopify and Atlassian have both adopted variations of “no-meeting mornings” because engineers who get 90 to 120 minutes of uninterrupted work before their first meeting produce measurably more output. If you control meeting scheduling, protect those hours.
Use the sprint board instead of asking. If the board is current, you have your status. If it’s not current, the fix is to make updates easier, not to schedule another meeting.
Say “next sprint” more often. Every request that can wait should wait. The PM who protects the current sprint’s focus is the one whose team actually ships on time instead of watching features stall at 90%.
Absorb, don’t relay. When a stakeholder asks about progress, answer from what you already know. Don’t forward the question to the team. When a customer reports a non-critical bug, log it for triage rather than interrupting the developer mid-task.
“But I Need to Stay Close to the Work”
The pushback is always the same: if I step back during execution, I’ll miss problems.
True that you need visibility. Not true that visibility requires interruptions. Read the pull requests. Watch the sprint board. Sit in the standup if you have one. Review the demo. None of those require you to break anyone’s flow state.
The PM who creates a protected environment for their team during the build phase will ship more features in a quarter than the PM who “stays involved” by pinging engineers twelve times a day. Mark’s research and Weinberg’s math both confirm it: the single highest-leverage move a PM can make during execution is reducing the number of context switches their team absorbs.
The features your team never shipped weren’t all killed by bad requirements. A meaningful number were killed by the accumulated weight of every “quick question” and “just one more thing” that fragmented attention across the sprint.