The real cost of context switching, with concrete examples

I timed one Thursday

You will find plenty of confident numbers online about how long it takes to recover from an interruption. I am not going to quote any of them, partly because I cannot vouch for where they came from, and partly because the only number that matters for planning your week is your own.

So here is mine, from one Thursday when I was working for four clients and decided to write down every switch. I kept a text file open and logged two things each time I changed what I was working on: the time I left a thread, and the time I next did something real in the thread I moved to. "Real" meant a commit, a finished sentence that stayed, or a reply that answered the question. Opening files and scrolling did not count.

Between 09:00 and 17:00 I switched fourteen times. Not fourteen interruptions from other people; fourteen changes of thread, about half of which I started myself. The gaps between arriving and doing something real ranged from about three minutes (replying to a scheduling message) to twenty-five (getting back into a half-finished migration after a call). Most sat somewhere around ten to fifteen. Added up, it came to a little under three hours.

Three hours of an eight-hour day spent arriving. I had felt busy all day. I had been, technically. I just had not been doing very much of the work.

Three hours of an eight-hour day spent arriving.

That log is one day at one desk, not a law of nature. But I have repeated it a few times since, and the shape is always similar, and it changed how I plan.

What actually reloads

The minutes are the visible part. What you are really rebuilding when you switch is a working set, and it has more pieces than people expect.

Files and tools. Which branch, which tabs, which terminal was running what. This is the easy part, and the only part most people account for.

The goal. Not "the feature" but the specific thing you were halfway through proving. Which assertion was failing. Which paragraph was going to make the argument.

The social role. Writing to a client, reviewing a colleague, arguing in a thread and talking on a call are four different registers. Each one needs a slightly different version of you, and switching between them has its own warm-up.

Urgency. Support work puts you in a short, vigilant, reply-quickly mode. Design work needs the opposite. That mode does not switch off when you close the support tab.

The rebuild is cheapest when only the first piece changes, and most expensive when all four change at once.

Five switches from real days, with what they cost

From a feature branch to a "quick look" review. I had a failing test, a plan for the next commit, and a request to glance at a colleague's diff. The review itself took twelve minutes. Getting back to my branch took longer: reopening the files, rerunning the tests, and rereading my own notes because I had forgotten which assertion I was fixing. Forty minutes after I left, I had left two review comments and made one small local change. The cost was not the review. It was the feature thread. These days I review in fixed windows, which deep work for developers describes in more detail.

From support tickets to a design document. One morning started with a run of support replies for a maintenance client: short answers, high alert. At 11:00 I opened a design document that needed slow thinking. I stayed in reply mode for the next hour without noticing. The document filled with bullet fragments, I checked chat between paragraphs, and what I wrote read like a series of responses rather than an argument. I went back to tickets at lunch without finishing the section. The cost was the quality of the document, plus paying the setup for both modes twice.

From a proposal to a chat debate. I was drafting pricing for a prospective client when a thread erupted in a team channel about an unrelated policy. I read twenty messages, formed opinions, replied twice, and went back. The sentence I had been building was gone. Worse, the next paragraph had picked up the tone of the argument, and I had to rewrite it the following morning. The cost was an hour of shallow participation and a proposal that needed an extra pass.

From a deploy to "just starting" something else. The deploy was going to take a while, so I opened the next feature. The pipeline failed four minutes later, and I did not notice for about twelve, because I was busy loading the new feature into my head. Now both threads were red and neither had my full attention. Working while a build or upload runs is about choosing wait work that is cheap to drop.

From a client email to a blog draft and back. Formal and careful, then loose and personal, then formal again. Writers know this one even if they never measure it: the second email came out chattier than it should have, and I reread it twice before sending. Finish one voice before opening another, or accept a rewrite pass as part of the price.

Diagram

The same cost in euros

Minutes are easy to shrug at. Money is less so. Suppose a freelancer bills €60 an hour and has a four-client day like my Thursday: one client's email, another's review, a third's bug, a fourth's proposal, all before lunch.

If each switch between clients costs around fifteen minutes of rebuilding (my own rough average on mixed days, not a universal figure), six switches is ninety minutes. At €60 an hour, that is €90 of time in one day. There are only two things that can happen to it. Either you bill it, in which case your clients are paying for you to remember where you were, or you do not, in which case it comes out of your own effective rate. Over a twenty-day month, the same pattern is €1,800 of time that went into arriving.

That is planning math, not an accounting claim, and your numbers will differ. The point is that a day full of short switches has a cost even when every individual switch feels free. Running a multi-client week without context thrash is the calendar side of fixing this: themed days or half days per client, so the reload happens once.

A calendar that fits on paper and fails in practice

Here is a morning I actually had booked once: thirty minutes of support, a thirty-minute standup, forty-five minutes of review, thirty minutes on a document, sixty minutes of feature work, and a thirty-minute sales call. Three hours and forty-five minutes of items, six different contexts, and on paper it fitted before lunch with time to spare.

In practice each entry needed about ten minutes before I was doing it properly. That took an hour out of the morning that was not on the calendar anywhere. The sixty-minute feature block became about forty-five minutes of real work. The thirty-minute document slot became fifteen minutes of writing and fifteen of rereading where I had got to. Everything "fit." Nothing was finished.

The repair was boring. Support and review went together into one window. The feature got one longer block instead of being squeezed between two calls. The sales call moved into the afternoon with the other conversations. Same work, three contexts instead of six, and the feature actually landed.

Some switches cost double

The worst switches are the ones out of debugging. A debugging session is mostly a fragile structure in your head: what you have ruled out, what you suspect, which log line looked odd. An interruption does not pause that structure. It knocks it down. Why interruptions are so expensive during debugging covers how I protect those sessions.

The other expensive kind is switches you cannot see coming. If a manager asks for status every hour, the cost is organisational, and no amount of personal discipline fixes it. That one is fixed by agreeing an async rhythm, not by typing faster.

Caps I have kept

• One active thread for composition work. Code, design, long writing. If something new needs depth, it waits for its own block.
• Two windows for shallow work. Email, triage and reviews happen in them, not between them.
• Switches named in the plan. If the plan says "11:30 client call," the switch is intentional. If a ping causes it, it was stolen.
• A few minutes between modes. Before joining a call from code, I write the next action on the branch. Back-to-back calls with coding squeezed between them have rarely produced either good calls or good code.
• Notifications cut to the ones that can genuinely not wait. Every notification is a switch you have outsourced to a vendor.

Multiple monitors cut down on window shuffling but invite running two threads at once. One screen forces focus but slows legitimate reference checks. I pick a layout for the type of day rather than arguing about which is better.

The resume note template

When I leave any thread, planned or not, I write three lines. It takes about thirty seconds. Most of what it saves is the bit at the start of the rebuild where you stare at the screen trying to remember what you were about to do.

Next: one concrete action
Where: link, file path, or ticket
State: passing, failing, or unknown (and what was last tried)

I treat it like saving a file. It is not elegant, but it means the next arrival starts from a note instead of a guess.

Log your own before you fix anything

If you only do one thing after reading this, log three days. Each time you change thread, write the time and a one-word cause: chat, review, email, household, tool, me. Do not try to improve anything while you log. Just look at it at the end.

When I have done this, two causes have always dominated. For me it was chat and "quick" reviews, not the big project changes I would have guessed. Fix the top two before buying a new app. Then, if you only defend one thing, defend the longest composition block in the day, as in protecting two uninterrupted hours.

Context switching is not a personal failing, and getting faster at it is not really a skill. People who are good at switching still pay to rebuild; they just notice the bill sooner. The useful move is to make the bill visible, then stop paying it fourteen times a day for things that could have waited an hour.