HIVE80lab — Ops notes

The shift isn't over until the next shift can run it

A shift handover is a transfer of state — not a conversation, not a vibe, not a "call me if anything comes up." The outgoing shift knows things the incoming shift doesn't: what degraded at 19:40, which customer was promised a callback, which workaround is holding the payment sync together with tape. None of that survives a hallway conversation. Spoken words evaporate; the ones that matter most evaporate first, because the end of a shift is exactly when everyone is tired and the door is calling. The fix is one rule that outranks all the others: the handover is written before it is spoken — the talk is the Q&A for the log, not a replacement for it. This page gives you the three things that must travel between shifts, the five-line entry that carries them, the open-loops list that is the log's engine, the hot/cold distinction and the paid ten minutes, the repeat-back, and the five traps.

1. The handover is a transfer of state (not of mood)

What actually changes hands at a shift boundary is state — the difference between what the business is doing right now and what it would be doing on a normal evening. Three things must travel, and each one has a failure mode when it doesn't:

Notice what is not on the list: how the shift felt. "It was pretty hectic" carries no state at all. If a shift felt frantic because of a real event, the event goes in the log with timestamps; the feeling doesn't.

2. Hot vs cold — and the paid ten minutes

Two handover shapes exist, and pretending they're the same is the root of most handover failures:

The overlap rule, because it is the one that gets bargained away: the ten minutes are scheduled at the shift boundary, they are paid, and they are never "when things quiet down." A handover that happens "when things quiet down" happens never — things never quiet down; that's why you have shifts. If the shift ran hot, the ten minutes move, they don't vanish. And in a two-person company, the hot handover is you at 17:25 writing to you-at-9am; treat that person as a stranger, because in ten hours, they effectively are one.

3. The five-line entry (the whole template)

Every shift gets one entry. Five lines, this order, copy-paste:

  1. What happened: facts with timestamps. "19:42 — payment gateway errors on ~1 in 4 checkouts; 20:05 — support ticket opened with provider, ref #48211; 21:10 — errors cleared."
  2. What's still open: the loop, the owner, the next deadline. "6 failed orders to re-run — Sam — before 11:00 open."
  3. What's at risk: the fragile thing and its early warning. "Sync is running on the retry queue; if 'last synced' is older than 30 min, it's failing again."
  4. Who already knows: names. "Riverside Cafe emailed twice; Priya answered both, promised morning confirmation."
  5. If it gets worse: the threshold and the named escalation. "If checkout error rate > 10% or the queue stalls > 45 min: call provider duty line, then Alex."

Line 4 is the one small teams skip and customers feel. "Who already knows" is the difference between the morning shift making one confirmation call and sending a third apology email to someone who has already been apologized to twice. It costs ten seconds to write and it is the line that most often prevents a real mistake.

4. The open-loops list (the log's engine)

The entry is the shift's story; the open-loops list is the shift's debt. Every loop is one row with three fields, and a row missing any field is not a loop, it's a wish:

Then the repeat-back: the incoming shift reads the top three loops back in their own words — "I've got the six re-runs before 11, the supplier confirmation by noon, and the monitoring watch until the patch lands." Thirty seconds. Every misunderstanding a repeat-back catches is one that would otherwise be discovered at 15:00 by someone who never agreed to it.

5. The six rules

6. Paste-in template

SHIFT HANDOVER — [date] — out: [name] / in: [name]

1. WHAT HAPPENED:
   [timestamped facts, or "quiet shift, nothing to report"]
2. STILL OPEN (loop / owner / deadline / done-looks-like):
   - [loop] / [name] / [time] / [observable end state]
3. AT RISK (thing / early warning sign):
   - [thing] / [sign to watch]
4. WHO KNOWS:
   - [name] knows [fact]; [customer] was told [what] by [who]
5. IF WORSE:
   - if [threshold], then [action], then call [name]

TOP 3 LOOPS (incoming reads back): ...

Keep it where the next shift will actually look — the same place, every shift, pinned or linked from the thing they open first. A template nobody can find at shift change is decoration.

The five handover traps

  1. The chat-message handover. Typed into a chat at 17:31, it scrolls away by Tuesday, has no owner, and can't be searched when it matters. If your log lives in chat, it lives nowhere.
  2. The to-do dump. Twenty-five items, no priorities, no owners. The incoming shift will do the easy five and feel guilty about the rest. Three loops with owners beat twenty-five without.
  3. "Quiet shift, nothing to report" — written nowhere. The unwritten quiet shift is indistinguishable from the shift where nobody looked. Two logged lines cost fifteen seconds.
  4. Double-notifying. The outgoing shift already called the customer; the incoming shift, not told, calls again — now the customer has two apologies and zero confidence. Line 4 exists to kill exactly this.
  5. Handover only when something broke. If the log appears only on bad shifts, writing it starts to feel like confessing, and the fastest way to avoid confession is to stop noticing. Daily and boring is what makes it honest.

Worked example: the flapping gateway and the third apology

A two-person evening on-call for a small e-commerce operation. 19:42, checkout errors start — roughly one in four payments failing. The provider's status page stays green. 20:05, a ticket goes in (ref logged). 21:10, errors stop — almost certainly the provider, not anything they did. Six orders failed outright and need re-running; one customer, the Riverside Cafe, emailed twice and was answered twice by the outgoing shift, with a promise of morning confirmation.

The 17:00–01:00 shift writes its five lines in four minutes: the timeline, the six re-runs (owner: Sam, deadline: 11:00, done = confirmation emails sent), the fragile sync on its retry queue (warning sign: last-synced older than 30 minutes), who knows (Riverside twice, promised morning confirmation), and the worse-case ladder (error rate > 10% or queue > 45 min → duty line, then Alex).

Morning shift starts at 8:00. They read the log in ninety seconds, re-run the six orders by 10:40, and send Riverside exactly one confirmation — the one that was promised. Without line 4, the most likely morning behavior is a fresh apology for an outage the customer has already been apologized for twice; with it, the customer's experience is one competent follow-up. Total cost of the handover: about six minutes of writing, one paid overlap, and a provider ticket reference that made the morning's provider call three minutes long instead of twenty.

Related: the annual leave coverage checklist is the fortnight-long version of the same move (coverage ritual, the five-column sheet, the boundary rules); the paging policy decides what's allowed to wake the shift that just took over; and the after-action report template is what tomorrow morning does with tonight's log — the handover entry is AAR section 1, written on time.

From the HIVE80lab kit

Related: the annual leave coverage checklist runs the same transfer for a two-week absence; the paging policy sets the bar for what wakes the incoming shift tonight; and the standing orders ladder says what they may do about it before anyone else answers.