Context switching: what a project switch really costs — and how to do the arithmetic

Your head switches, it does not parallelise

"Multitasking" describes an ability that does not exist for work requiring attention. What actually happens is fast switching between tasks. And every switch has a price made of three parts:

1. 1.Setup: restoring the right documents, files, windows, threads of conversation.
2. 2.Recall: where was I, what was the open question, what had I discarded and why.
3. 3.Attention residue: part of your head is still on the previous task. This effect is documented under exactly that name and is why the first minutes after a switch feel unproductive even though you are working.

Together that adds up to a realistic ten to twenty minutes per switch for knowledge work. Not as a law of nature, but as a workable figure to calculate with — and calculating is the point of this article.

Disclosure: we build Balane Plan, an app that caps context switches in the schedule and measures individual switching costs. The arithmetic below you can do yourself, and we recommend you do.

The arithmetic: what twelve switches cost

A normal-looking day: three projects, email in between, two questions from colleagues, one ticket that has to be answered quickly.

Almost two and a half hours — not for work, but for switching between work. Against a net time of four to five hours, that is half the day.

What makes this arithmetic treacherous is that no single item looks bad. "Just answering that email" feels like two minutes and costs ten. The cost is invisible because it never collects in one place.

Why three projects in parallel are worse than three in sequence

Assume three projects need 6 hours of work each, and you have three days with 5 hours of net time each.

Option A — in parallel: touch all three projects every day. That is at least 4 switches a day, 12 over three days. At 15 minutes each: 3 hours gone. 15 hours of net time become 12 hours of work — against 18 hours of demand.

Option B — in sequence: project 1 on day 1 and the morning of day 2, then project 2, then project 3. About 2 switches in total: 30 minutes gone. 15 hours of net time become 14.5 hours of work.

The difference is two and a half hours — for identical work and identical hours. The only difference is the order.

There is a second effect the arithmetic does not show: in option B one project is finished at the end of day 2. In option A, at the end of day 3 all three are at 80 per cent. Finished work is worth something; 80-per-cent-finished work is not.

Three kinds of switch, three different remedies

Not every switch is the same, and the remedy differs.

The self-inflicted switch. You switch because a task gets tedious or another looks more interesting. Remedy: timeboxing with a decision at the end. The box holds you through the tedious phase, which is where the work actually happens.

The scheduled switch. A meeting interrupts, another deadline forces your hand. Remedy: batching. All meetings into one window, small stuff into a shared box, projects by the day rather than by the hour.

The externally caused switch. Colleague in the doorway, message, ticket. The remedy here is not willpower but an agreement: what response time applies? "Within four hours" is compatible with focus work; "immediately" is not. Making that agreement explicit does more than any technique, because it solves the problem where it originates.

Four measures that actually work

1. One project at a stretch instead of five in rotation. The single most effective measure. Plan projects by day or half-day, not in hourly slices.

2. Set a ceiling on switches. Six or seven deliberate context switches a day is a defensible limit. It forces a decision at planning time that you would otherwise leave to the day.

3. Batch the small stuff. Email, approvals, short replies into one or two fixed windows. Not because that is faster, but because it cuts switches from twelve to two.

4. Log the exit. Two sentences when leaving a task — where it stands, what is next — noticeably reduces setup time on re-entry. It is the cheapest measure on this list and the one least often done.

What can be measured

Switching costs feel vague but are measurable:

• Number of switches per day. Counting is enough. The number is usually twice what people estimate.
• Time to the first productive minute after a switch. Time it for two weeks and average — that is your personal switching price.
• Switching cost per project pair. Jumping between two related projects costs less than between two unrelated ones. Knowing that lets you cut days sensibly.

Those three quantities are exactly what Balane Plan picks up in passing, because every work session is measured anyway: the planner knows your personal switching cost between two specific projects, keeps a project together, and caps switches per day. Without an app the same thing works with a tally sheet — less precisely and with more effort.

The uncomfortable part

Most advice about context switching ends at "less multitasking". That is correct and useless, because the switches rarely happen for fun. They happen because too many commitments are running at once.

Someone who has committed to four projects in parallel cannot stop switching — they can only choose whether they do it deliberately or by accident. The real intervention sits one level up: start fewer things in parallel and finish them properly. That is a question of capacity planning, not of concentration.