GGH.
All writing

Flow dynamics · 05

Multitasking is bad

Two runs of the same work. Each task needs the same fixed amount of focused effort, and only the task you are working on makes progress. The first run finishes one task before starting the next. The second adds interruptions — requests to switch — to show what changes when attention is divided.

By Gavan Grenville-HuntInteractive guideFlow system map

Work through both scenarios below, then compare them: when each task is delivered, when everything is finished, and how much time is lost to switching.

The items here are labelled “Task A” and so on, but the same applies to whole workstreams or projects. If your work is usually organised by project or epic, read these as “Project A” or “Epic A” — and note that the cost of multitasking tends to be more pronounced at that level, where the re-orientation between pieces of work is larger.

1Scenario 1 — one task at a time

Pick up a task and work it to completion before starting the next. This is often called single-piece flow: one item is finished and delivered before the next is begun.

With auto-advance on, just click the first task — each task is worked to completion and the next is picked up automatically.

2Scenario 2 — pressure to multitask

In the real world there is often pressure to look responsive and visibly start work sooner. In this scenario a stakeholder prompts you to switch tasks. Leave the auto-switch option ticked for now.

Click any task to begin. With auto-switch on, stakeholder requests are obeyed automatically — as if the team complies with every interruption.

The two runs compared

Complete Run 1 and Run 2 to see the comparison.

What the stakeholder actually wanted was the work delivered sooner. They fell into a natural trap — assuming the sooner work is started, the sooner it is finished — and pushed for everything to begin at once. Side by side, the one-at-a-time approach delivered sooner. But a real stakeholder only ever experiences one of these timelines. If the team gives in to the pressure, the stakeholder sees only the late delivery and blames the team, never knowing the disciplined approach would have served them better.

Completion is when value lands

Starting every task early feels like progress and is easy to report. But nothing delivers value until it’s finished, and splitting attention across three features means none of them ships until near the end. Working them one at a time delivers the first finished feature in roughly a third of the time, because effort is concentrated until something is done.

This matters because value lands on completion. A feature that is 90% done delivers nothing. Three features each 90% done deliver nothing three times over. Finishing one and releasing it gets something into users’ hands early — the opposite of starting everything at once.

Starting everything early delays every finish.

Switching has a direct cost

Returning to a task after working on something else is not free. A developer picking up a half-finished feature after two days on a bug has to reload it: read back through the code, work out where they left off. That’s before any progress happens. In the second simulator this appears as the red switching segment — time that counts as neither touch nor wait but is lost.

This cost scales with the number of switches. A developer rotating between three features in one week incurs it many times over. The overhead is added to the total — so heavy multitasking doesn’t just delay the first delivery, it increases the total time to finish all the work.

Starting all the work sooner does not finish it sooner. Splitting attention delays the first delivery and, because each switch carries a re-orientation cost, increases the total time to complete everything.

Efficiency per task

The efficiency figure on each task is its touch time divided by its total elapsed time — the share of the task’s life spent being actively worked rather than waiting. Working one task at a time gives that task a high efficiency while the others wait. Switching lowers efficiency across every task at once: each one spends most of its life waiting for attention to return, and a share of the active time is consumed by re-orientation overhead.

The same principle, one person

Limiting the number of tasks worked at once shortens the time to deliver each one. That’s Little’s Law applied to a single developer: with throughput fixed, fewer items in progress means lower cycle time. The re-orientation cost is a form of the variability that Kingman’s formula penalises, and concentrating on one task at a time is the same principle as protecting a constraint from interruption. Finish work before starting more.

Takeaways

  • — The work is fixed; only the sequence of attention varies. Sequence alone determines when results are delivered.
  • — Value lands on completion. Starting everything early delays every finish.
  • — Each switch carries a re-orientation cost. Heavy multitasking increases the total time to finish all the work, not just the first delivery.
  • — Working one task to completion delivers the first result soonest and finishes everything soonest.
  • — Pressure to show progress on everything delays everything. Sequencing delivers one thing sooner; splitting attention delivers everything later. The trade-off needs to be made explicit.
  • — If a stakeholder needs one thing fast, assign one person to it uninterrupted. One developer finishing it in two days beats three developers sharing it across a week.