There is a particular kind of engineering team that is always busy and never finishes anything.
Everyone is at capacity. Standups are full of progress. Utilisation is high, tickets are moving, nobody is idle. And yet the roadmap slips quarter after quarter, and no one can point to the reason, because there isn't a single obvious one. There's just a general sense that things take longer than they should.
Usually the reason is that the team has no uninterrupted time, and nobody is measuring that.
The cost is not the interruption
The standard framing of context switching is about the interruption itself. Someone asks a question, you lose five minutes, you get back to work. Framed that way it sounds trivial, and it is easy to conclude that people complaining about interruptions are just precious about their calendars.
But the interruption is not the cost. The cost is the state you were holding.
Complex engineering work involves keeping a lot in your head at once: the shape of the data, which invariants hold where, the three things you already ruled out, the reason the obvious fix doesn't work. That state takes time to build and it does not survive a detour. Coming back, you are not resuming — you are rebuilding, and you rebuild it slightly worse than you had it.
Which is why a fifteen-minute interruption does not cost fifteen minutes. It costs the fifteen minutes, plus the reload, plus the fact that the work either side of it was shallower than it would have been.
Why it hides from every metric you have
This is the part that matters for managers, and it is why the problem persists in teams that measure a lot.
Context switching does not reduce hours worked. It does not reduce activity — if anything it increases it, because switching generates its own traffic: more Slack, more tab-flipping, more little commits. It does not reduce ticket counts, because the tickets that survive a fragmented day are the small ones.
So a team drowning in interruptions looks more active, not less. Every presence-based metric says they're working hard. They are. They're just spending a large fraction of that effort on reattachment, and none of your dashboards have a column for that.
The only way to see it is to look at the shape of the day rather than the total. Focus time versus active hours is the same observation from the other direction: high activity and low focus is the signature of a fragmented team, and it is very common in teams that consider themselves high-performing.
What actually causes it
In our experience the causes are almost always structural, and there are four of them.
Too many concurrent workstreams. One person on three projects is not doing three projects. They are doing one project badly, three times, with switching costs in between. This is the biggest single lever and it is a staffing decision, not a discipline problem.
Undirected interrupts. When any engineer can be pulled into support, everyone's day is fragmented a little. When one engineer is on a rotating interrupt duty, one person's day is fragmented a lot and everyone else's is clean. The second arrangement produces more work, and it is not close.
Meeting placement. A meeting at 11:00 does not cost an hour. It costs the morning, because 90 minutes is not enough to get properly into something hard. Same meetings, moved to the edges of the day, cost almost nothing. We wrote about the full cost of meetings separately, but the placement point is the one engineering managers can act on immediately.
Review latency. If a PR sits for a day, the author has moved on and has to reload the whole thing to respond. Fast review is not just politeness; it is a context-switching intervention.
The uncomfortable part
Most of what gets written about focus puts the responsibility on the individual. Turn off notifications, block your calendar, use a technique with a name.
That advice isn't wrong, but it is aimed at the wrong person. An engineer cannot decide to be on fewer projects. They cannot unilaterally stop being the person everyone asks. They can block their calendar and watch it get booked over by someone more senior.
Fragmentation is a property of how work is organised, and it is fixed by the people who organise the work. If your team's focus time is poor and your intervention is a productivity workshop, you have misdiagnosed it.
How to measure it without turning it into a stick
Track two numbers per team, monthly: sustained focus blocks per person per day, and concurrent workstreams per person. Watch them move together, because they nearly always do.
Do not track this per individual and do not put it in a review. The person with the worst fragmentation is usually the most senior person on the team, because they are the one everybody interrupts. Punishing that is both unfair and self-defeating — and the moment people suspect the number is being used against them, they will protect it in ways that make the data useless. The wider method is in how to track employee productivity.
Where this leaves you
If your team is busy and slow, the hypothesis worth testing first is not effort and not talent. It is that nobody on the team has had two uninterrupted hours in a fortnight.
That is measurable, and it is fixable, and neither requires anyone to work harder.
ProdView surfaces focus blocks and meeting load from activity metadata, at team level, with engineers seeing the same view their manager does. It runs natively on Linux alongside Windows and macOS, which for engineering fleets is usually the deciding practical detail. Free for three seats if you want to check the hypothesis on your own team before believing us.