The Hidden Cost of Context Switching for Developers

There is a well-known study that suggests it takes twenty-three minutes to regain focus after an interruption. In my experience managing engineering teams, that number is conservative. For complex coding tasks, I have seen developers lose an hour or more of productive time from a single unplanned fifteen-minute meeting.

As PMs, we are often the source of these interruptions. We need a quick answer for a stakeholder. We want to clarify a requirement. We have a "quick question" that turns into a thirty-minute discussion. Every one of these interactions has a hidden cost.

The Math

If a developer has six hours of potential coding time in a day and you pull them into two unplanned thirty-minute meetings, you have not taken one hour. You have taken the two meeting slots plus the ramp-up time on either side. Realistically, you have reduced their productive coding time by two to three hours. That is thirty to fifty percent of their day, gone.

Multiply this across a team of five engineers over a two-week sprint, and you start to understand why velocity is lower than expected.

What I Do Differently

I batch my questions. Instead of pinging a developer three times throughout the day, I collect my questions and ask them all at once, ideally during a scheduled touchpoint.

I use async communication by default. If it can be a Slack message that the developer reads when they finish their current task, it should be. The only reason to interrupt someone in real time is if the issue is genuinely urgent.

I also protect focus blocks on the team calendar. Two-hour blocks in the morning and afternoon where no meetings are scheduled. These blocks are sacred.

Protecting developer focus is not a nice-to-have. It is a direct lever on delivery. Every meeting you prevent is code that gets written. Every interruption you batch is a context switch that does not happen. The PM who understands this will always get more from their team.