Information Transfer Model

You’ve hit the classic failure: you transmitted information, but you didn’t ensure transfer. A memo is a one-way broadcast, not a loop. The night crew didn’t misbehave—they lacked a shared mental model of what “correct” looks like.

First, stop explaining the workflow and start defining the output. Show them three screenshots: one correct entry, one common mistake, one garbled entry. People learn patterns, not paragraphs. Second, make the system reject ambiguity. If the software allows free-text fields, lock them down with dropdowns. If it accepts “defect type” as anything, it will be anything. Third, run a 15-minute live drill at shift change—one supervisor enters data while the other watches and corrects in real time. That closes the loop.

Finally, ask each night crew member to teach it back to you in two sentences. If they can’t, you haven’t transferred—you’ve only spoken. The test of transfer is not that you said it clearly; it’s that they repeat it accurately. Fix the system, not the memo.

The Handover Is a Teaching Problem, Not a Documentation Problem

You're right to worry. Piles of specs and API references are worthless if your team can't absorb the why behind the code. Treat the transfer like a course, not a courier delivery.

Structure it in three layers:

1. The "Survival Guide" – A 10-page maximum document covering only the non-obvious traps: the weird database constraint, the fragile deployment step, the hidden cron job. If it's not surprising, leave it out.
2. The "Show-Me" Sessions – Have the dev shop walk your team through live debugging of the three hardest production bugs. Memory sticks better than reading.
3. The "You Own It" Period – Keep the vendor on retainer for 4-6 weeks after handover. Your team fixes real issues, with the vendor on call. That's when true understanding forms.

The inversion: Ask yourself what would guarantee a failed handover. Usually it's assuming documentation equals transfer. Kill that assumption.

The goal isn't a perfect archive. It's a team that can survive a fire drill without calling for help.

Keep the documentation lean, force hands-on practice, and pay for overlap. That's the whole game.

Stop Teaching Patterns, Start Teaching Meaning

Your students described the what — flashes — but not the why — the code. That’s because they memorized your words instead of building the mental model. Here’s how I’d fix it.

1. Start with a stupidly simple example.
Have them encode a message like “Duck” using only two sounds: a tap and a pause. Let them invent the code themselves. Once they see that any pattern can carry meaning if both sides agree on the rules, the light lab becomes obvious. The flashes aren’t the point; the agreed-upon mapping is.

2. Ask the killer question:
“If I showed you these flashes with no prior agreement, would you know what they meant?” No. So meaning isn’t in the pattern — it’s in the shared convention between sender and receiver.

3. Have them decode each other’s lab data.
Swap conclusions. Each student must explain what the other group’s flashes meant, then check with the original group. If they can’t decode it, the encoding failed. That’s the real lesson: information transfer is only successful when the receiver reconstructs the intended meaning.

4. Use the “telephone game” principle.
Every step — encoding, transmission, decoding — can corrupt the message. Have them add noise (a flickering light) and see how meaning degrades. That teaches them why redundancy and clarity matter.

Stop asking them to describe the pattern. Ask them to prove the meaning survived the trip from sender to receiver. That’s the whole game.