The problem is that nothing tells you to stop
An office has a moment where work ends. Someone stands up, the room empties, you travel home. None of that exists at a kitchen table. The laptop stays visible, one message becomes another hour, and the day dissolves into a long grey stretch of half-working.
The second cost is worse than the evening. Without a clean stop, tomorrow morning begins with yesterday's tabs, a stale sense of priority, and fifteen minutes of reconstructing what you were doing. You pay for the missing edge twice.
A shutdown routine is a replacement for the commute you no longer have. Ten minutes, same order every time, and it ends with permission to be finished.
Put it on the calendar before the stop time
If you want to stop at 17:00, shutdown starts at 16:50. This is the single change that makes the rest work.
Run it at 17:00 instead and two things happen. You are already out of energy, so writing anything feels optional. And you have spent the last twenty minutes starting work that cannot finish, which is how "one more small thing" turns into 18:30. Treat the final ten minutes as work, because they are.
The eight steps
1. Stop mid-task and write the resume cue. One minute. Save the file, stop the timer, and write the next physical action for whatever is unfinished. Do this before you feel done, not after.
2. Write what is done. Two minutes. Link the artifact rather than describing it. "Invoice tax line is on staging, sample in ticket 441" is a done line. "Worked on invoices" is not.
3. Separate open from blocked. One minute. Open means you can continue tomorrow. Blocked means you cannot, and someone else is the reason. Collapsing the two into a single list is how blockers sit unmentioned for three days.
4. Send the blocker asks now. Two minutes. This is the step people skip, and it is the most valuable one. Recording "waiting on design" helps nobody. Send the actual message: name the decision, attach the artifact, give a real deadline. If it goes out tonight, an answer may be waiting when you start.
5. Choose tomorrow's first action. Two minutes. Not a priority list. One line, with a verb, an object, and a location, small enough to start cold. This is the whole reason to plan tomorrow at shutdown rather than tomorrow morning: right now you still remember what you were doing, and in fourteen hours you will not.
Weak: "Continue portal." Usable: "Open portal.css, reproduce the overdue row overlap at 375px, compare against design frame 12."
6. Name one thing that is explicitly not tomorrow. Thirty seconds. Deciding what to drop is what stops tomorrow's plan from being a copy of everything still open. Writing it down means it stops nagging.
7. Close the work surfaces. Two minutes. Close the work browser profile, quit chat, put away notes and anything sensitive, move the laptop out of evening space if you can.
8. Do something physical. Turn off the desk lamp, shut a drawer, step outside for two minutes. It needs to be small enough that you will still do it on a bad day.
A finished shutdown note
- Done: invoice tax line on staging, link in ticket 441
- Open: customer portal overdue-label colour
- Blocked: need design approval on empty states by Thursday, asked in ticket 441
- Tomorrow's first action: open
portal.cssand reproduce the overdue row at 375px - Not tomorrow: renaming the invoice helper functions
Five lines. It carries the state of the work, the request that is out for an answer, the restart point, and one deliberate exclusion. If a teammate picks this up instead of you, they need the fuller version described in leaving work someone else can continue; for a note that goes to a client or manager, see writing an end-of-day status update.
What not to do
Do not copy every open task into tomorrow. A plan that lists eleven things is not a plan, it is an inventory. Three at most, one of them primary.
Do not send one more email after step 8. The routine only works if it is a real boundary. One exception teaches you the boundary is negotiable.
Do not write reminders instead of actions. "Look at the CSS thing" will cost you ten minutes tomorrow deciding what it meant.
Do not close the tools before sending the blocker ask. Steps four and seven are in that order deliberately.
Do not review the day as a verdict. Note what did not finish and why. A shutdown is operational hygiene, not a performance score, and turning it into self-assessment is the fastest way to start skipping it.
Do not build an elaborate ritual. Anything longer than ten minutes gets abandoned in the first difficult week.
When work genuinely has to continue
Deadlines and incidents happen. The rule is that the extension gets its own edges: decide the new stop time before you start, name the narrow outcome you are going for, and tell whoever is affected. Take a real break in between if you can.
At the new stop, run a shortened version of the same sequence. Capture, send, set tomorrow's action, close. An open-ended second session with no shutdown is how a bad night becomes a bad week.
Where this leaves the morning
The point of step five is that the next morning does not require a decision. You sit down, read one line, and start. That pairs with a simple morning routine, which is short precisely because the previous evening already did the thinking.
Capture done, open, blocked, and tomorrow's first action in the same place you will read them tomorrow - ticket, doc footer, or a single daily note linked from your task.
Shutdown replaces the commute you lost
Without travel, work stops only when you declare it stopped. Ten minutes of capture is cheaper than an hour of evening bleed trying to "finish one more thing." See how to structure a remote workday.
Leave context for tomorrow without replanning
Shutdown is not weekly planning. It is one first action and one explicit not-tomorrow line. Leave context for tomorrow keeps the note small enough that you will actually write it on bad days.
Hand off unfinished work in writing
If someone might continue while you are offline, use the pick-up bar from leave work someone else can continue: where it lives, how to verify, what not to redo, default next action.
Order of operations
Status first while memory is fresh, then physical signal, then personal devices. Reversing order invites "just one more fix" after the laptop is closed.
Bad-day shutdown
Primary slipped? Shutdown anyway with honest Done and shrunk tomorrow first move. Skipping shutdown because the day felt weak guarantees a worse tomorrow.
Recover workday after losing focus ends with the same close.
Tools and tab hygiene
Bookmark bar full of half tasks is tomorrow's trap. Close or park each open thread to a ticket line before stop time.
Example: Friday shutdown
Example: Note "Monday: run migration dry-run, link INF-9" and list what not to touch over weekend unless sev-1. Team knows ownership; you know rest is allowed.
Example: freelancer client close
Example: Send short Done/Next client note, log time, close project tabs, move phone to personal profile. Client gets clarity; you get boundary.
Shutdown is how remote workers manufacture a commute. Without it, every evening is overtime waiting to happen.
Five minutes, same order
Done, open, blocked, tomorrow first action, close tools, physical signal. Same order daily so you do not decide at 18:00 when tired.
Scenario: primary unfinished
Example: Feature not done. Shutdown still runs: stash with message, ticket updated, blocker sent, tomorrow first command written.
Unfinished with capture beats unfinished with laptop open on the couch.
Home space boundary
Finish work when home and work share space extends shutdown with physical cues when there is no office door.