Operational Interrupts: What Kills Productivity Isn't the Workload, It's Fragmented Time

The on-call post covered “how to design alerts and who carries the pager”; the toil post covered “the 50% guardrail so operations doesn’t eat all the engineering time”. But between those two, something is missing that happens every day yet is rarely managed as a problem: interrupts — the stream of tickets, the ad-hoc questions, the pages tossed your way. Each looks small on its own, yet together they can leave an engineer “very busy, but nothing moved forward” for a whole day. This post covers why interrupts are so expensive, and how to manage them at the team level.

The cost of an interrupt isn’t time; it’s fragmented time

First, break an intuition: the real price of a 5-minute interrupt isn’t those 5 minutes. It’s that it broke your flow, and afterwards it takes 20 or 30 minutes to climb back into the state of thought you were in (ramp-up). So what interrupts kill isn’t “working time”; it’s “continuous time in which deep work is possible”. The cruel part: the same total amount of interruption, scattered versus gathered into one block, produces wildly different output:

Both rows have exactly the same total interrupt time, and wildly different output. ① Scattered interrupts each drag a ramp-up back into the zone behind them, chopping the work into small fragments — deep work drops to nearly zero. ② The same interrupts gathered into one block leave one long uninterrupted stretch on the left. So managing interrupts isn't managing the "total"; it's managing "fragmentation" — which is why "interrupted a little at any time" hurts far more than "interrupted once, in a batch"

Interrupt shield: trade one person’s focus for the whole team’s

Since fragmentation is the real enemy, the team-level solution is clear: don’t give everyone a slice of the interrupts (result: everyone fragmented, zero deep work across the team); instead, appoint one person (or a pair) as the “shield” for this period, taking all interrupts, so the rest get whole, uninterrupted time. Rotate next round:

On the left everyone takes a slice of the interrupts, and the result is all four fragmented, zero deep work across the team. On the right one person is the shield taking every interrupt, and the other three get whole uninterrupted time, rotating next week. It's a very good trade: one person's focus for the focus of the other N−1. The companion rule is that the shield must polarise their time — this period is full-time interrupt handling; don't take tickets with one hand and push a project with the other, which does both badly

Reflections

I measure team capacity by “whole blocks of time”, not by “busyness”

The longer I lead teams, the less I trust “busy”. A team can have everyone busy, everyone working late, every ticket answered, Slack read and replied within seconds — and not one quarterly goal moved. Because not a single person got three continuous hours to do the thing that actually needed thought. Busy is an illusion fed by interrupts; output comes from unbroken blocks of time. So when I review team health now, I don’t look at “is everyone busy”; I look at a more honest number: this week, how many “uninterrupted two-hour blocks” did each person get? That number maps almost directly onto whether we can produce anything that requires a brain. Since making it a metric, I’ve become much stingier about meetings, about “let’s sync quickly”, about casual @-mentions — because I know what I’m cutting isn’t a few minutes; it’s someone’s whole stretch of flow.

Half-hearted “available” is the worst state

“I’ll work on the project and keep an eye on Slack” sounds responsible, but it’s the worst of all states: you aren’t truly focused (ready to be pulled away at any moment, thinking stuck in the shallows), and your response to interrupts is slow too (stuck in the project’s context, unable to switch). 50/50 available is empty on both focus and responsiveness. That’s the essence of the interrupt shield — it forces you to polarise: either full-time shield, or fully protected; don’t sit in the middle. I apply the same rule to myself: when I decide today is deep work, I turn notifications off and tell the team plainly, “today, go to X; don’t come to me”. That isn’t shirking — quite the opposite: it hands “being responsible for responding” clearly to the person whose job it is right now, instead of everyone half-catching it absent-mindedly.

A rising interrupt rate is a symptom, not “time to hire”

The last is the judgment a lead most easily gets wrong. When a service’s tickets keep growing, the reflex is “we’re short-handed; add someone to take them”. But a steadily rising interrupt rate is almost always a symptom of something broken upstream: a service that never did its production readiness, a pile of toil that should have been automated and wasn’t, a stale runbook that lets the same question be asked again and again. Adding a person to absorb interrupts only absorbs the symptom, and makes the real disease harder to see — you’ve paid for “looks like we’re still coping”, at the price of never fixing the source that keeps generating tickets. So I track “interrupt volume” as an SLI: when it climbs steadily, what needs fixing isn’t the rota; it’s the source. And that ties back to SRE’s underlying belief — it does reliability engineering on “people’s time” too: focus, like a service’s normal operation, is a resource that erodes and must be actively protected.