The cost of switching

The standard story about abandoned systems is discipline. The better story is arithmetic, and it starts with a measurement from workplace research: interrupted work was resumed, on average, after about 23 minutes, with roughly two other tasks in between (1).

That figure is often misquoted as lost time. It is not — the interval includes handling the interruption and doing other useful work. What it does measure is how expensive it is to put a thing down and pick it up again.

Now count your own switches

Tasks in one app, calendar in another, money in a third, the shopping list in a chat with yourself, documents in a folder of photographs. To know what today holds you visit four places and assemble the answer yourself.

None of those tools is bad. The cost is not in any of them — it is in the gaps between them, and the gaps are paid daily, by you, in the currency that was already scarce.

Why this kills systems that are working

The failure is not dramatic. One day checking all four costs more than doing the smallest thing in them, so you do the small thing instead of checking. A week later the system is out of date, which makes it less worth checking, which makes it more out of date.

People then conclude they are not the kind of person who keeps a system. They kept it fine. The toll went up.

The second cost: assembling the answer

Switching is the visible toll. The hidden one is that none of the four places can answer a question on its own.

What does Thursday hold? The calendar knows the meetings, the task list knows the commitments, the money screen knows the payment, and the answer exists in none of them. You assemble it in your head each time, from four partial views, and then it evaporates.

That assembly is the actual work of running your own life, and it is the work that gets quietly skipped on a busy day — not because you are disorganised, but because it costs four visits and produces something that lasts until you close the tabs.

What integration does and does not mean

It does not mean one application that does everything. That product exists, repeatedly, and it is usually worse at each thing than the tool it replaced.

It means one shared axis — in practice, the day — that each part can answer about. The planner keeps being a planner and the money screen keeps being a money screen; what changes is that both can say what they know about Thursday without you being the integration layer.

The practical rule

Count places, not features. A tool that does ninety per cent in one place beats two tools that do one hundred and ten between them, because the missing ten per cent costs you once and the switch costs you every day.

And when you do add a second place, give it a hard boundary — a whole domain, not a slice. Two systems that both hold tasks is the worst arrangement available.