The Instruction Manual
I rewatched Night at the Museum recently with my young children. In the first film, three retiring night guards hand Larry Daley a numbered instruction booklet. Cecil, the oldest, delivers the briefing with the confidence of a man who has been doing this for decades: "Do 'em in order, do 'em all and do 'em quick." No explanations. No rationale. Just a list of commands and a warning not to let anything in or out.
I think that might be the most honest depiction of a Standard Operating Procedure (SOP) I have ever seen on film. And I must admit, I recognised the handover. I have been Larry. I once inherited a deployment procedure for a banking system that included the step "wait 90 seconds before proceeding." No one could tell me why. I followed it for months before discovering it was the time a long-retired server had needed to flush its cache. The server was gone. The wait remained.
We have all inherited instruction manuals like Cecil's. They arrive with a new role, a new system, a new team. They are numbered, ordered, and stripped of context. They tell you what to do. They do not tell you why.
And how often do we ask whether the omission is accidental?
For automation, codified procedures are genuinely indispensable. Larry's first instruction is "throw the bone." It sounds absurd until you discover that the T-Rex skeleton just wants to play fetch. The rule, followed on faith, works. Grab's engineering team found that structuring LLM agents around explicit SOPs achieved over 99.8% accuracy, precisely because the machine does not need to understand why. You cannot automate what you cannot codify, and codification means writing down the steps, however strange they may look to the newcomer holding the bone.
However, I think there is a difference between codifying a procedure and understanding one. And that difference may matter most when your organisation is not trying to repeat the past but trying to move beyond it. I should be clear: in safety-critical settings, rigid SOPs save lives, and Gawande's checklist research makes a compelling case for not inviting reasoning under pressure. What I am talking about is the procedures that govern how organisations change, not how they operate at the sharp end.
In the third film, Secret of the Tomb, the golden tablet that animates the museum exhibits begins to corrode. It has been away from its source (the moonlight of the Temple of Khonsu) for too long. The exhibits start glitching, becoming aggressive, losing themselves. The rules keep firing.
The rules now hurt.
How many of our procedures are running on a corroding tablet? I suspect more than we think. The procedure still runs, but the context has quietly moved. Consider the WHO Surgical Safety Checklist: at eight pilot hospitals where teams were trained in what each item meant and why it mattered, deaths fell by 47% and complications by 36%. When Ontario rolled the same checklist out to 101 hospitals, with 215,000 procedures, there was no significant reduction in either. Same form. Opposite outcomes. The reasons are probably more complex than any single explanation (implementation quality, institutional culture, training investment all played a role), but I think the direction is clear: the form without the understanding is the tablet without the moonlight.
You may have heard the story about five monkeys, a banana, and a cold water spray (new monkeys, never sprayed, still attack anyone who reaches for the banana). It is a vivid parable about inherited behaviour. It is also entirely made up. And yet the fact that every manager has heard it is perhaps itself the phenomenon it purports to describe. We pass around a story about unquestioned rules without ever questioning where the story came from. (I am building my own argument on a Ben Stiller film, but I hope the difference is that I am using it as metaphor, not as evidence.)
G.K. Chesterton offered the opposite warning in 1929: do not remove a fence until you know why it was put there. I think both positions may be true simultaneously. A procedure without its rationale is vulnerable to what Richard Feynman called cargo-cult behaviour, ritual that perfectly imitates the form of the original while missing everything that made it work. A procedure whose rationale you never bother to recover is vulnerable to reckless removal. Either way, the why is what makes the difference. We cannot afford to treat it as optional documentation.
Taiichi Ohno, Toyota's chief engineer, understood this. His standardised work was never the end state, it was the starting line. "Without standards, there can be no kaizen", he argued, meaning that you begin by following the written procedure faithfully, measure what happens, and then improve it. The SOP is a hypothesis taped to the workstation, not a commandment carved in stone. But you must follow it first.
In Night at the Museum, we eventually discover that Cecil, Gus, and Reginald were the villains all along. They had been stealing the tablet's magic to keep themselves young. The manual was not neutral. Its omissions were deliberate. They did not forget to explain why. They chose not to.
I suspect more of our organisational SOPs carry this kind of silent self-interest than we might like to admit. The approval gate that justifies the approver's role. The weekly meeting whose purpose no one can articulate but whose cancellation would threaten someone's calendar. Not conspiracy, exactly. Just the quiet accumulation of procedures that serve their authors more faithfully than they serve the organisation.
If you are automating, then by all means codify. Throw the bone. But if you are transforming, perhaps the first question is not "what does the manual say" but "who wrote it, and what did they gain from what they left out." As David Marquet, the submarine commander who turned USS Santa Fe around, put it: "Instructions require obedience; intent requires thought."
The tablet can be restored, but only if we take it back to the moonlight. Write the why down while someone still knows it. And if no one knows it, perhaps that tells you something about who wrote the manual and what they wanted you not to ask.
(Views in this article are my own.)