Context Switching

For a long time, staffing plans were filled in with division. Take one person's week as 100, give this project 50, give that project 30, leave 20 for support questions. If the columns added up to 100, the plan was considered done.

And at the end of every cycle the same scene played out. The person listed in three places was about halfway through all three, and none of them could ship. The people who built the plan asked why nothing finished when all the time had been spent. The person doing the work said they hadn't had a slow day. Both were telling the truth. Time was leaking out through a gap that the table had no column for.

Context switching is the name given to that leak. It exists so that the act of moving between pieces of work can be written down as a cost rather than assumed away, which is why capacity planning treats it as one of the reasons the usable total is smaller than the calendar total.

Moving to another piece of work means taking down the state you were holding and loading a different one from scratch. The loss happens during the reload, not during the work.

There are roughly three things to recover when you come back.

1. Where you stopped. Which file you touched last, and what you were about to do next.
2. What you decided. Why this approach won, which options you already threw out, and what you agreed with a teammate.
3. What is still open. Questions waiting on an answer, and assumptions you haven't confirmed.

Recovering all three takes fifteen to thirty minutes, and the count restarts every single time you come back, no matter how short the trip away was. It works like closing a book without a bookmark. You hunt for the page, reread a few of them, and only then are you reading at your old speed again.

So the number of assignments and the amount of output don't move together. With one assignment, almost all of a person's time goes into it. With two, each gets about 40 percent and 20 percent goes into the moving. With three, each gets about 20 percent and 40 percent goes into the moving. Those are widely quoted rough figures rather than a precise measurement, but the direction is clear: each additional assignment costs more than the one before it.

The loss survives for years because nothing records it. A meeting takes a block on the calendar and vacation leaves dates behind, but twenty minutes spent reloading state leaves no trace. Look at a finished cycle from the outside and it just looks like the work went slowly. With no record, the next plan gets built from the same division, and the same result arrives again.

The term comes up most often in the meeting where people get assigned to work. Someone puts up a table with one name spread across several columns, and the question is whether that division actually holds.

• Reviewing assignments. If one name appears in three columns, cutting it to two and pushing the third into the next cycle usually produces more total output. Teams with a low focus factor — the share of total hours that actually reaches planned work — often find the cause here. A team landing at 0.5 instead of 0.7 wasn't idle; it was moving around.
• Interruptions. An urgent customer question or an incident in the middle of a sprint belongs here. Thirty minutes of handling costs well over an hour of real time. Rather than leaving that to individual discipline, teams set the time aside in advance as a buffer.
• Limiting parallel work. In kanban, a work in progress (WIP) limit caps how many items can be underway at once, and it aims at this loss directly. You can't pick up something new until what you started is finished, so the opportunity to switch shrinks.
• Meeting placement. Three thirty-minute meetings at 10am, 2pm and 4pm don't cost 90 minutes; they cost most of a day. That's why teams push meetings into one morning or one weekday and protect the rest. The longer the protected stretch, the fewer times the reload has to be paid.

"Theo is in three places. With the context switching, two would be better."

The columns add up, but the real output won't, so one of them should move to the next cycle.

"The numbers came in low this cycle — a lot of context switching."

Less time reached the planned work than expected, and the cause was moving between assignments.

"This is a thirty-minute thing, right? Can you squeeze it in?"

The asker is requesting thirty minutes; anyone who knows the term immediately thinks about how much more than thirty minutes actually disappears.

At Pagedeck this comes up during quarterly planning. Mia's staffing table had Theo spread across a billing rework, a search performance fix, and customer support duty. The columns summed to 100. Theo asked to be cut from three to two, and Mia pushed the search work back a cycle. The billing rework finished ahead of schedule.

Grace looked at the same table and asked how removing work from a person who was still there could possibly help. Mia's answer was that what got removed wasn't work — it was the number of times Theo had to reload.

The most common assumption is that people who are good at multitasking don't pay this cost. Some people really do move between windows quickly, and it feels productive from the inside. But the feeling and the measurement disagree. Switching produces a strong sense of busyness, which reads as progress, and yet when the cycle ends and you count what actually shipped, the person who finished one thing at a time is ahead. Left in place, this belief produces staffing plans that pile more assignments onto whoever switches most comfortably.

The other one is arithmetic: a short interruption costs only as long as the interruption. A five-minute question costs five minutes. It doesn't work out that way, because what disappears is the reload, not the answer. Six five-minute questions in a day cost closer to two hours than to thirty minutes, and those two hours land in no line item anywhere. The person answering looks available all day and delivers half of what the plan assumed, which is exactly the gap the term was invented to make visible.