I've read the studies. 23 minutes to regain focus. The costs of interruption. All of that. What I want to write about is what context switching actually looks like in a small engineering team, because the academic version doesn't match the texture of the real thing.
The Setup
Two engineers. Four services: a TypeScript API, a Python data pipeline, a Go CLI, and some infrastructure managed in Pulumi. All actively maintained, all regularly changing. This is normal for a small product team.
We noticed about six months ago that we were both consistently underestimating task durations by a factor of roughly two. Not because the tasks were harder than expected — because switching between them was costing more than we were accounting for.
What We Actually Measured
This is informal, not a controlled study. We each tracked context switches for two weeks — defined as: switching from one service's codebase to another, or switching from coding to a different kind of cognitive work (review, writing, planning). We logged the time from switch to "producing output I'd actually keep."
Average: sixteen minutes to meaningful productivity after a context switch. The 23-minute number exists because some switches are worse than others; the language boundary switches (TypeScript to Go, Go to Python) were consistently the worst. The "same language, different domain" switches were faster but still nonzero.
What We Changed
We implemented a rough version of deep work blocks — two-hour minimum work periods on a single service, scheduled in advance. This is not a new idea. It helped. The underestimation problem improved within three weeks.
We also changed how we handle interruptions. Small questions that don't require immediate answers go into a shared document, batched, and addressed in a scheduled 30-minute session. The cultural change of convincing yourself that a "quick question" is not always urgent was harder than the logistics.
What Didn't Help
Turning off notifications is usually where this kind of post goes. We tried it. It didn't help because the interruptions weren't coming from notifications — they were coming from ourselves. "Let me just quickly check that other thing" is self-interruption and you can't filter it.
Project management tooling changes didn't help either. We tried Linear, Notion tasks, plain text files. The tool doesn't change the pattern. The scheduling change did.
Where We Are Now
Task duration estimation is better. The underestimation factor went from roughly 2x to roughly 1.3x, which is tolerable. We still context switch more than I'd like — the nature of the work requires it — but we're more deliberate about when we do it.
The honest finding: context switching is a scheduling problem as much as a focus problem. You can't eliminate it, but you can cluster it. That turned out to be the lever that mattered.