How to Stop Losing Decisions Overnight

The overnight gap is the period between when your last shift signs off and when your first shift comes back online. For a globally distributed team, this gap is typically six to twelve hours. During that window, any decisions made in the last shift can effectively disappear — buried in a Slack channel, implicit in a code change, or simply held in the outgoing engineer's head.

When the next shift starts, those decisions are either rediscovered, reinvented, or never found. All three outcomes waste time. Preventing them requires a systematic approach to decision capture at shift end.

The three ways decisions get lost overnight

Lost in conversation: The decision was discussed in Slack, the discussion ended, and nobody extracted the decision from the thread into a structured record. The thread is technically accessible but practically invisible to the incoming shift.

Lost in code: The decision was implemented — the code was written a particular way because of a choice the engineer made — but the choice wasn't communicated anywhere. The incoming engineer can see what was done; they can't see why, and they may undo it without realizing the undoing was a mistake.

Lost in mind: The decision was made but not written down anywhere. The outgoing engineer intended to note it but ran out of time, forgot, or assumed the incoming engineer would figure it out from context. They won't.

The practice that prevents it

One practice solves all three failure modes: the decision section of the shift-end record. Before signing off, every engineer explicitly lists any decisions made during the shift that affect what the next shift will do. This takes sixty to ninety seconds if the decisions are fresh in mind. It takes significantly longer if you're trying to reconstruct decisions made six hours ago.

The practice only works if it's consistent. One shift-end record per engineer per day, every day, with decisions explicitly captured every time. When the habit is inconsistent — when engineers write the record "when something important happened" — the incoming shift can't trust the record and defaults to asking questions to cover for potential gaps. Consistency is what makes the record trustworthy enough to act on.

The compounding value

A team that has been capturing decisions consistently for three months has a searchable record of why things are the way they are. New engineers can read it and understand the system. Engineers returning from leave can quickly reconstruct the current state. Post-mortems can reference the actual decision history rather than relying on memory.

This compounding value is often the argument that converts skeptics. The immediate benefit is preventing overnight decision loss. The long-term benefit is institutional memory — the team starts to remember things as a team, not just as a collection of individuals who were present at different moments.

Frequently asked questions

What if the incoming shift ignores the decision records?

This is a reading habit problem, not a writing habit problem. The fix: make it a team norm that every engineer reads the shift-end records for their project before touching any code. If the reading habit is established before a costly oversight happens, that's ideal. If it takes a costly oversight to motivate it — that's how most teams learn to read handoffs.

How far back should decision records go?

Keep at least three months of decision records accessible and searchable. Archive older records rather than deleting them — you'll be surprised how often a six-month-old decision becomes relevant when a similar problem arises. A complete decision history is more valuable than a curated one, because you can't always predict which decisions will matter later.