Handing over work is one of the first things a new hire is asked to do. On sites with shift work, they hand over to the next shift in their first week, and office staff write handover notes every time someone goes on leave or changes roles. Yet few people ever practice it. Most learn by being handed a senior colleague's template and filling in the blanks.
A template shows you the blanks. It doesn't tell you what is most urgent. The semiconductor fab, construction site, co-op and IT company maps in First Run all include moments where work passes to the next person. This article uses those quests to set out what makes a good handover.
Shift handover: records and conversation together
This is a production planning quest in the fab. It is thirty minutes before night shift ends. A tool went down at 4 a.m., two lots are on hold waiting for engineering disposition, and one lot is running short on Q-time.
- Tell the day lead "all fine except one tool, details are in MES" and head home: Poor
- Paste the whole night's MES event log into the handover note so nothing is left out: Risky
- Stay past shift end and close every open item yourself so day shift starts clean: Risky
- Write up tool status, held lots and owners, Q-time left and open actions, then walk the day lead through it in person: Excellent
The three wrong answers are the three ways a handover fails. The first passes on too little: the held lots and the Q-time lot, the most urgent things, never get mentioned. The second passes on too much: everything is there, but Q-time keeps running while the next shift interprets the log. The third doesn't hand over at all: decisions made while exhausted invite mistakes, and the next shift doesn't know what happened. Shift work assumes handing over.
The Excellent answer does two things together. The record leaves nothing out, and the conversation carries the priorities.
When records and reality drift apart
Half of a handover is the record. The next person makes decisions from what you didn't say out loud. If the record drifts from reality, the handover passes on false information.
In the fab's MES quest, a film-thickness gauge goes down, and the operator suggests that since the lot is on a Q-time clock, they manually track it out of the measurement step in MES and measure later. Doing that is Poor: MES now shows the lot as measured when it wasn't. Moving the lot first and updating MES in a batch at the end of the shift is also Poor, because everyone else decides on wrong information in the meantime. Putting the lot on hold and waiting for the gauge is Risky: not skipping the step is right, but a hold should start a conversation with the owner. Excellent is not skipping the step, getting an approved disposition from metrology and process, and recording the reason in MES.
On the construction site, the day before ceilings close, the 7th-floor sprinkler pressure test has no record. The fire subcontractor says the test was done and only the paperwork is missing. Filling in the form yourself with numbers they read out is Poor. Creating a record for a test you didn't witness is a false record, and the person who wrote it carries the responsibility.
Settle tomorrow's work today
The construction engineer writes tomorrow's work order. The formwork crew and the rebar crew both want the same zone on the 13th floor tomorrow morning, both need the tower crane, and the electrical crew has to lay conduit before the pour.
- Give the crane to the biggest subcontractor and let the others sort it out on site: Poor
- Put all three crews in the same zone at once and give the crane to whoever asks first: Risky
- Report the situation to the team lead and pass on the order the team lead decides: Good
- At the afternoon coordination meeting, agree sequence, zones and crane times with the three foremen, write it into the work order and confirm it again at the morning TBM: Excellent
The Good feedback is especially useful for new hires. Reporting was right, but the work order is the construction engineer's document to coordinate, so next time bring your own proposal and get it checked. Passing a problem up is not the same as passing the decision up. The structure of the Excellent answer matches the shift handover: write it down, then confirm it in conversation at the morning toolbox meeting.
Report the slip early
The other face of a handover is a delay report: passing the fact that things aren't going to plan to the next person, your manager or another team. All four maps grade delay reports the same way.
The fab's New Line Setup PM learns that two joints failed a helium leak test on a new gas line, which will cost a week. Handover to operations is two weeks away, and nobody above has been told.
- Ask the contractor to sign it off without a retest, since the leak was tiny: Poor
- There's still room to recover, so cover the week with night and weekend work and say nothing: Poor
- Report once the retest results are in, so you report facts, not guesses: Risky
- Report now to the sponsor and operations: the cause, the impact on the handover date, recovery options and the decisions needed: Excellent
New hires most often pick the third. Reporting only what's certain feels conscientious. But by the time it's certain, there's no time left to choose alternatives. Mark what is uncertain as uncertain, and report now. As the feedback puts it, a delay reported early becomes part of the plan; a delay reported late becomes an incident.
The construction site's contracts engineer has to submit a recovery plan after a long rainy season pushed the frame ten days behind. One of the worst answers is adjusting the planned dates in the schedule so the delay doesn't show until next month's report. The IT company's PMO quest asks the same question: when a key feature will clearly slip by three days, the first thing to do is summarize the cause, impact and options and tell stakeholders now, while silently cutting scope is Risky.
In the co-op's center operations quest, two drivers call in sick on a busy Monday morning. Skipping the uncovered route today and delivering tomorrow without telling members is Risky. Worse than frozen food arriving a day late, members on the watch list won't even know why nobody came. Pushing every route back and sending one app message is Good; re-planning routes to put frozen-heavy group drop-offs and watch-list members first, and warning the members who'll be late, is Excellent.
What belongs in a handover note
Gather the Excellent answers and the items common to handover notes and delay reports appear.
- Current state: where the tool, the job or the route stands now
- Open items and owners: what isn't finished and who is waiting to decide
- Time limits: Q-time, pour times, frozen goods, handover dates, anything that can't wait
- Next action: what the next person should do first
- Uncertainties: what isn't known yet and when it will be
- Decisions needed: for a delay report, what the reader has to decide
And don't pass this list on paper alone. Confirm the two or three most urgent items face to face, or by phone.
Checklist for handover scenarios
- Are passing on too little, too much and nothing at all all treated as wrong answers?
- Is the correct answer the one that combines a record with a conversation?
- Do the scenarios cover records drifting from reality (manual workarounds, after-the-fact records)?
- Do they distinguish passing a problem up from bringing your own proposal?
- Is reporting only once certain kept from being the correct answer?
- Is hiding a delay explained as the worst answer?
- Do handover notes include time limits and the next action?
For design rules shared across industries, read Onboarding scenarios for industries beyond IT. The reporting order when you see a hazard is covered in Teaching new hires to report near-misses.
Try workplace scenarios as onboarding quests
Pick production planning on the semiconductor fab map to play the shift handover quest yourself. Play the Onboarding