Why does one engineer working three items at once deliver all three later than in sequence?
answer
- attention does not divide for free
- same work, later dates
- reload cost paid at every switch
- sequential delivers the first one early
- three at seventy percent deliver nothing
basics
~20 sSwitching costs reload time, and every item's clock runs the whole span, so all three land near the end instead of one landing early. Worked in sequence, the first item is delivered at roughly a third of the elapsed time.
solid answer
~50 sTwo costs stack. The first is the **reload cost**: every switch discards the mental context of the item you were on, and rebuilding it takes real minutes that produce nothing, so the same work consumes more hours. The second is arithmetic on delivery dates. Run three equal items in sequence and the first is done at about a third of the total span and the second at two thirds; run them together and all three land near the end, so nothing is usable early and the average wait is far worse. Parallel work also carries risk: if the team has to stop for a change of priority, an incident or an absence, it holds three unfinished items instead of two finished ones and one in progress. Finishing before starting is cheaper and safer, which is exactly what a work-in-progress cap forces.
go deeper
Be able to say that splitting attention across several items delays all of them, and that finishing one before starting the next gets something usable out much sooner.
Put numbers on it. Contrast the staggered finish dates of sequential work with the bunched, later dates of parallel work, and name the reload cost that is paid at every single switch.
Connect it to risk. Parallel work means nothing is deliverable if the team has to stop, feedback arrives late, and defects surface in three places at once. Expect to defend the honest exceptions rather than deny they exist.
Frame it as a portfolio question. Be ready to argue why cutting the number of things a team runs at once is usually a faster route to delivery than adding people to all of them at the same time.
## Two ways to spend the same fortnight Take a 7-person team building a legal-document review product, and one engineer with three items of roughly equal size - about 3.2 days of focused work each. **Sequential.** The engineer takes the first item, finishes it, then the second, then the third. | Item | Delivered on day | | --- | --- | | First | 3.2 | | Second | 6.4 | | Third | 9.6 | **Parallel.** The engineer keeps all three open, rotating between them as reviews come back and questions arrive. The total work is the same 9.6 days, but roughly 18% of the time is spent reloading context after switches, so the span stretches to about 11.3 days - and, critically, nothing is finished until near the end. | Item | Delivered on day | | --- | --- | | First | 10.4 | | Second | 10.9 | | Third | 11.3 | The totals tell one story and the individual dates tell a much sharper one. Sequentially, something valuable exists on day 3.2. In parallel, nothing valuable exists until day 10.4 - a difference of more than 7 days on the item that mattered most, from a decision that felt at the time like working harder. ## Where the extra time comes from - **Reload cost.** Coming back to an item means rebuilding what you knew: which branch of the problem you were on, what you had already ruled out, which edge case you were mid-way through. That reconstruction is pure overhead, paid at every switch, and it grows with the gap since you last touched the item. - **Re-reading and re-deciding.** Decisions made three days ago and not written down get made again, sometimes differently. - **Defect cost.** Mistakes made while half-loaded surface later, when the context has to be rebuilt a third time to fix them. - **Coordination drag.** Three open items mean three sets of reviewers, three sets of questions and three status conversations, each of which is another interruption. - **The long tail.** Items that are 90% done stay 90% done, because the remaining 10% is the fiddly part that requires uninterrupted attention, which is the thing parallelism removes. ## What finishing first actually buys 1. **Earlier feedback.** A finished item can be looked at by the person who asked for it. Two half-finished items cannot, and their assumptions stay unchallenged for another week. 2. **The option to stop.** If priorities change on day 5, sequential work leaves one delivered item and one in progress. Parallel work leaves three items that are individually useless. 3. **Lower risk at a fixed date.** With a deadline approaching, three items at 70% deliver nothing. One item at 100% and two untouched deliver something. 4. **Less to hold in mind.** The team's shared working memory is finite, and each open item consumes some of it whether or not anybody is actively touching it. ## The honest exceptions Nobody works strictly one item at a time, and claiming otherwise in an interview is a tell. There are cases where a second item is right: - The first item is genuinely blocked on an event outside the team and cannot progress at all until that event happens. - The second thing is a short, bounded interruption that unblocks somebody else - reviewing a colleague's change, answering a design question. - The two items are so tightly related that the context is shared rather than switched. The distinguishing test is the motive. If the second item was chosen to keep the board moving toward finished work, it is fine. If it was chosen so that a person would not appear idle, it is the failure mode this question is about. Even in the legitimate cases, the discipline is to return to the first item the moment it unblocks, rather than to let the second one grow. ## Why this sits under work-in-progress limits Everything above is an argument, and arguments lose to habit. Starting is visible and satisfying; it is under your own control in a way that finishing somebody else's review is not; and in many places progress is still reported as items started rather than items finished. A cap turns the argument into a rule: the column refuses, so the choice does not arise. That is why practitioners bother writing a number on a board at all rather than simply asking people to focus - the number holds when attention and good intentions do not.
- Are there cases where working on two items at once is genuinely right?Yes - when the first is blocked on an event outside the team and cannot progress at all, or when the second is a short interruption that unblocks somebody else. The test is motive: a second item chosen to keep finished work moving is fine, one chosen so nobody looks idle is the failure mode.
- If the arithmetic is this clear, why do teams keep working in parallel?Because starting is visible and satisfying, because looking busy is easier to defend than visibly waiting, and because progress is often reported as items started rather than items finished. Changing which number gets reported changes the behaviour faster than any amount of exhortation.
Three pots on one burner: moving the pan back and forth means nothing boils until nearly the end, while cooking them one at a time puts the first dish on the table early.
saying these in an interview costs you the question
- Claims switching between items is essentially free
- Believes parallel work delivers the same dates as sequential
- Measures progress by how many items are started
- Treats a wait for review as a reason to start two more
- Assumes senior engineers are immune to switching cost