← All posts
22 July 2025

Where the Context Goes

The 23-minute interruption stat is well-known. But nobody talks about the cost of returning to a project you left three weeks ago.

The 23-minute figure comes from Gloria Mark, who spent months in the mid-2000s trailing knowledge workers at tech companies and a financial firm in California. After being interrupted, people took an average of 23 minutes and 15 seconds to fully resume their original task — not because they were slow, but because interruptions spawn intermediate tasks that each need their own resolution before you can climb back out.

That number got everywhere. "Protect your focus time." "Disable your notifications." The whole genre of deep-work advice rests on it.

But the 23-minute stat describes a specific, narrow version of the problem: an interruption measured in minutes, where your mental context is still warm. Return to a project you haven't touched in four weeks, and that framing doesn't apply at all.

The notes are there. The files are there. If you were organized, maybe there's a doc with bullet points. But the mental model is gone — why you made the decisions you made, what you tried that didn't work, what you were actually trying to figure out at the moment you stopped. You're not resuming. You're reconstructing.

This is a categorically different problem, and almost nobody talks about it.

What gets lost

Erik Altmann at Michigan State has spent years studying what he calls resumption lag — the specific delay between putting down a task and picking it back up. Even with short interruptions of a minute or two, there's a measurable cost: you have to reconstruct what you were trying to accomplish, not just where your cursor was. Task goals decay. They need reactivation.

At week-scale gaps, goal reactivation is only the start. The things that actually take time are harder to name:

  • Decision archaeology: why did I make this choice, and does it still apply?
  • Dead-end memory: what did I try that failed, so I don't try it again?
  • Constraint reconstruction: what was I optimizing for, and has anything changed?

None of that lives in notes. Most notes capture conclusions, not reasoning. And conclusions without reasoning are unreliable — you can't tell whether they still hold. The constraint that shaped your decision three weeks ago may have dissolved. Or it may have hardened. Your notes probably don't say.

So you guess. Or you spend an hour excavating old files. Or, more often, you do a bit of both and still feel uneasy about the ground you're standing on.

The document that knows why

A to-do app can tell you that your task was "finalize authentication approach." It can't tell you that you had ruled out JWT tokens because of a specific refresh token edge case in mobile Safari, and that your next step had been to prototype session storage before the project got deprioritized.

That's not a task — it's a context record. And context records are almost never what people build when they take notes.

The interesting design question isn't "how do I capture more?" It's: what specifically needs to be there for resumption to be fast? The answer is something like: the last meaningful decision, the reasons behind it, the alternatives you considered and rejected, and the specific next step you had in mind. Forty words, maybe. But specific words, written in a moment when you knew the context and anticipated needing it later.

Most tools make this hard. You can write that kind of note in any text editor, but nothing prompts you to do it. The affordances point toward capture — get the idea down, don't lose the link — not toward the harder thing, which is encoding your current reasoning state so a future version of you can pick it up cleanly.

The brief

The scenario that made this concrete: open a project from before a long break. Open an AI assistant connected to your knowledge base. Ask: "Where did I leave this?"

A good answer isn't a list of matching notes. It's: "You were building the onboarding flow. You had decided against the email-first approach after testing showed users bounced at the verification step. Your last note was that you wanted to try a magic link flow instead, and your open question was whether the delivery service's reliability was acceptable in your target regions."

That's not retrieval. That's a resumption brief. The difference is that the underlying knowledge was structured in a way that lets a model reconstruct your intent, not just surface your words.

This only works if the knowledge was captured with enough structure to support it — not as a pile of timestamped text, but as something closer to a decision log: what you knew, what you chose, why, and what was still open.

Most productivity tools ignore this problem entirely. They're optimized for capture, because capture is legible and measurable and feels productive. Reconstruction is none of those things. It's the slow tax you pay on the back end, invisible in the design of the tool that supposedly helped you stay organized.

The 23-minute interruption stat has a clear prescription: minimize interruptions. The resumption problem is harder, because you can't — and shouldn't — keep every project mentally live at all times. What you can build is a knowledge structure that makes walking back in low-cost. The context doesn't have to go anywhere. You just have to leave it somewhere findable.


Asgeir Albretsen is the founder of Harbor.

Where the Context Goes: Harbor Blog | Harbor