The most important task is the one that’s already done
What’s the most important task when you’re starting your daily work on any project? It’s the last task from your previous work session. The one that logged your progress and project status. It left you a shorthand of what was in your working memory when you stopped, in order to put it right back there when you start up again.
If you did that, the pickup is easy. You open your project and find your ducks all lined up in a nice row. If not, the pickup starts with chasing down those ducks. It starts with reconstructing that working memory: hunting for notes, re-reading documents, and getting your bearings. You spend 20 minutes orienting before you can start the real work.
This is re-entry friction, and almost everyone pays it many times a week without naming it. A person managing four concurrent projects, returning to each three or four times a week, with even ten minutes of reorientation per return, is spending two and a half hours a week chasing ducks before they can start working. That cost arrives in small enough increments that it doesn’t register as a single visible problem. It just feels like the normal beginning of work.
It isn’t. It’s one of the more tractable productivity problems in a knowledge worker’s week, and the prescription for it is well known.
The solution: leave yourself a note
Re-entry friction has been studied under several different names by people who didn’t always know they were studying the same thing.
The closest match in the academic literature comes from human-computer interaction. Cognitive scientists Erik Altmann and J. Gregory Trafton’s 2004 paper “Task Interruption: Resumption Lag and the Role of Cues” established that the time required to perform the first action after returning from an interruption scales with how long you were away, and that external cues left immediately before the interruption significantly reduce that lag. An external cue here just means something tangible left behind for your returning self to find: a written note saying where you stopped and what’s next, a comment in the code, a commit message describing the half-done work, even a sticky note on the monitor. The follow-on literature, including recent augmented-reality cue studies (Altmann and Trafton, 2004; subsequent CHI work), has confirmed the basic finding consistently: the longer you were away, the more time and effort a good exit cue saves you on return.
Adjacent and worth knowing about is University of Washington Bothell business professor Sophie Leroy’s 2009 paper “Why is it so hard to do my work?” - the originating empirical work on what she called attention residue. Strictly speaking, Leroy’s research isn’t about re-entry to a project after days away; it’s about cognitive residue lingering on a prior task while you try to start the next one. But her intervention finding generalizes neatly to our problem: a brief structured plan written at the point of switching, naming where you were and what you intended to do next, measurably reduces the residue (the space the thing continues to occupy in your brain) and improves performance on the next task. Same prescription, slightly different paradigm.
In popular productivity, the same prescription appears in three forms. Productivity consultant David Allen’s 2001 Getting Things Done builds its whole approach around a “next action” notation - the explicit point of which is that when you sit down again, you don’t have to figure out what to do; the note already tells you. Computer scientist Cal Newport’s 2016 Deep Work prescribes a “shutdown ritual”: five to fifteen minutes at the end of the workday spent reviewing every open task, capturing next steps, and verbally closing the day with the phrase “shutdown complete.” Knowledge management educator Tiago Forte’s 2022 Building a Second Brain extends the same point-of-departure capture principle from tasks to notes and references.
In software engineering, the same practice exists informally and ubiquitously. “Save your context” is a common phrase. Work-in-progress commits with descriptive messages. Scratch files left open in the editor. Leaving a failing test as the first task for tomorrow.
Three research traditions, three popular methodologies, and a default professional culture all converge on the same advice: leave a marker for your returning self at the point of departure. The problem is real, the prescription is broadly shared, and none of this is novel.
So the question isn’t whether to do it. The question is how to do it without it becoming its own job.
Why it goes wrong, and what to do about each kind of wrong
The practice fails in three predictable ways, and they each need a different fix.
- Process: the note never gets written, usually because you got interrupted.
- Tools: there’s nowhere good for the note to live, and nothing surfaces it when you come back.
- Content: you do write the note, but the note is too big, too small, or about the wrong things.
Process: the note doesn’t get written
You don’t leave yourself enough time to write the note, or you get interrupted. You get pulled into a meeting, have to stop and answer questions, a fire started somewhere else and you had to drop everything to go fight it. This is only a problem if you have no hook back to it. If you can come back later that day and capture what you remember while it’s still recent, you’ve recovered most of the value.
The fix: Build in a tickler. Plan to end your work ten minutes before your time runs out so that you have time to write your note. If you get interrupted, have an end-of-day process to walk back through every project you touched and didn’t close cleanly, and capture what you can while it’s still recent.
Tools: there’s nowhere to put it
The first is that the tool has no home for it. Most project-management tools weren’t designed for this. They give you a project description (static) and a task list (granular). They don’t give you a first-class slot for “where this project actually stands in my head right now.” So the note ends up in a scratch doc, or a Slack message to yourself, or a sticky on the monitor - somewhere you’ll forget to look. Or, you don’t have a project specific note at all, and you’re relying on a daily notes file to keep you current. When you sit back down with a project after a few weeks, you don’t know which day’s entry to look at, and the project’s notes are mixed in with notes about everything else you were doing that day. What you need is one note per project, updated at the end of each work session, living with the project itself.
The fix: Create a status file for every project, and link it to the project. The note needs a permanent home attached to the project, and the tool needs to put that home in front of you when you open the project. Where the tool doesn’t support this natively, build a workaround. A pinned doc at the top of the project page. A convention like “every project folder has a STATUS file.” A Notion template with a status section pinned at the top. You may have daily notes too, but the project-specific bits get extracted and live with the project.
Content: too much or too little
The trap is writing too much or too little. Too little and the note is useless. Too much and the ritual becomes its own work that you eventually skip.
The fix: Capture what’s not written anywhere else yet: the decisions you made, the open questions, what you were waiting on, the concrete next thing to do. “Fix section 3” is useless. “Section 3, paragraph 2: the citation contradicts the claim; either find a different cite or weaken the claim” is useful.
Iterate
The closing advice isn’t a system to adopt. It’s almost the opposite.
This is a practice you tune to your actual rhythm, not a methodology you take on whole. Start light. The first version of an exit note can be a single sentence at the top of the document. If your returns are still expensive, add. If maintenance starts competing with the work, subtract. Notice when a system has stopped earning its place, and throw it out, including systems you built yourself. The hardest scaffolding to take down is the one you designed.
There is no universal right answer, and even within your own life there will be seasons that need more structure and seasons that need less. The right system for a quarter where you’re running five concurrent projects is not the right system for a quarter where you’re heads-down on one. The right level of detail for a project you touch daily is not the right level for one you touch monthly. Refactor the system as the work changes.
The test is simple. When you sit down to work, is the first task on your list - figure out how to start - already checked off? If yes, the system is doing its job. If no, change it. Then see what happens.
