An engineer with six hours of nominally free calendar and an interruption every forty minutes does not have six hours of engineering time. They have nine fragments, each preceded by the several minutes it takes to rebuild the mental model that the last interruption destroyed. The calendar is not lying exactly, but it is measuring the wrong thing.
This is not a plea for isolation. Collaboration is most of what makes teams effective. It is an argument that unstructured, always-on availability is a specific choice with a specific cost, and most teams make it by default rather than by decision.
Rotate the interruptions onto one person
The highest-leverage change I have seen a team make is an interrupt rotation: one engineer per week handles questions, support escalations, small requests and anything unplanned. Everyone else is genuinely unavailable for those. One person's week is fragmented on purpose so four people's weeks are not fragmented by accident.
It works because it makes the cost visible and bounded rather than diffuse. It also surfaces the volume: a rotation that is overwhelmed every week is telling you something about documentation, tooling or product quality that individual interruptions were hiding.
- Default to asynchronous and write it down. A question in a channel with context gets a better answer than the same question interrupting someone mid-thought.
- Batch synchronous time — stand-ups and meetings adjacent rather than scattered. Three meetings spread across a day costs the whole day.
- Agree what is genuinely urgent. In most teams the honest answer is a production incident and very little else, and saying so out loud changes behaviour.
- Protect at least one long block per day per person. Two hours uninterrupted outproduces four fragmented ones, and everyone knows this and schedules as though it were not true.
- Make 'I will reply this afternoon' socially acceptable. If instant response is rewarded, no policy will survive it.
A meeting at eleven does not cost an hour. It costs the morning, because nobody starts something hard with ninety minutes on the clock.
The part that is about the work, not the calendar
Some fragmentation is self-inflicted and comes from the shape of the work rather than from other people. A twenty-minute test suite guarantees a context switch every time you run it. A flaky deployment pipeline means checking on it repeatedly. A task too large to hold in your head forces you to reload it constantly. Fixing those buys focus more reliably than any calendar policy, because they are under your control.
Working with agents adds a new version of the same problem. Dispatching a long-running task and then watching it is the worst of both — you have neither the focus of doing it yourself nor the benefit of delegating. The habit worth building is to hand off something substantial, genuinely leave it, and return at a natural boundary, which requires the same discipline that made code review batching work.
None of this is about working harder or longer. It is about noticing that engineering output is roughly proportional to uninterrupted time rather than to total time, and that most organisations optimise the second number because it is the one that appears on a calendar.