The Process Was a Person

“Half the time the person doesn’t even know what the exceptions are anymore,” they wrote. “They’ve been fixing them for so long it’s just how they do the job.”

Three readings of that symptom point at three different fixes. Your Dave might be withholding what they know, which is a willingness problem, and a conversation or an incentive fixes it. Your team might know the documented process and ignore it, which is a standards problem. A commenter argued hard for that reading: no standards, no accountability, no enforcement, and the fix is management training. jimmyray71’s answer drew a line worth keeping: “A manager can absolutely own the outcome and still need to understand why the process isn’t being followed before deciding what to fix.”

The third reading is the one nobody plans for. The person is doing the job correctly, wants to help, and still cannot produce the list, because the exceptions stopped registering as exceptions years ago. Another commenter described trying: “Planning feels more like trying to extract a confession from someone who committed a crime but doesn’t remember.”

Telling them apart costs one cycle

You don’t have to guess which one you have, and you don’t have to buy an assessment to find out. Ask the person to write down every exception they handle in a process. Then sit next to them for one run of that process and count the departures from the standard path that weren’t on their list.

A mostly complete list points at standards or willingness, and you should go handle that instead. A list that misses most of what you watched is the retrieval case, where every remedy built on asking is aimed at the wrong target. Expect a mixture rather than a clean verdict, and read the proportions: a half-complete list means you have some of both, and the missing half still isn’t coming out of an interview.

What the written process actually is

In the retrieval case, your SOP is not a bad description of the process. It’s an accurate description of something else: the path the work takes when nothing is wrong. Human factors research explains why that gap is structural rather than sloppy. Steven Shorrock’s 2016 piece on the varieties of human work separates work-as-imagined, “work that we imagine others do,” from work-as-done, “actual activity, what people do,” and finds the two can’t be made to converge by writing harder: “It is usually impossible to prescribe all aspects of human work, even work that is well-understood, except for extremely simple tasks.”

Be precise about what that establishes. Shorrock’s claim is about documentation, not memory. The amnesia claim rests entirely on those Reddit threads, one author and their commenters in one week, which is a recognizable account rather than a measurement. Hence the diagnostic: check it in your own shop instead of taking our word for it.

What keeps the gap invisible is that the compensating work looks like the opposite of a problem. jimmyray71 asked the subreddit a second question about operations that are busy for the wrong reason: “If someone spends an hour finding material, their effort isn’t the productivity. The fact that it took an hour to find the material is the problem.” Nobody logs that hour as an exception, because to everyone watching it is simply what the job involves.

Then you try to automate it

Here is where a documentation problem starts costing real money. Somebody is selling you automation, and the first question any vendor or internal team asks is: what’s the process? You hand over the SOP. What gets built runs the happy path.

Lisanne Bainbridge saw the consequence in Ironies of Automation, her 1983 paper in the journal Automatica on industrial process control. Her second irony: “the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate,” which leaves that operator with “an arbitrary collection of tasks.”

She was writing about power plants and flight decks, not about a bookkeeper and a billing tool. The extension is ours, and here is the reasoning so you can check it: the designer builds from the description available, the available description is the happy path, so the residue left to the human is the exception set nobody could enumerate. If that holds, Dave’s job doesn’t shrink so much as change shape, losing the routine work that made their day predictable and keeping the part that requires them sharp on demand. We haven’t measured that, and neither had Bainbridge for your kind of business.

It’s also why a pilot can pass its evaluation and still change nothing. Judged against the SOP it works. Judged against the actual queue it hands back everything the SOP omitted. If you want one question to put to a vendor, make it this: measured against what, and who handles the rest.

Capture it at the moment it fires

If the exception set can’t be recalled on request, it has to be caught while it happens. That one constraint rules out the interview, the offsite, and the binder. jimmyray71 got there too: “I’d rather capture the exception while we’re working through it than ask Dave three months later why he did something. By then he probably doesn’t remember either.”

What you’re producing is not a procedure document. It’s a list, one line per exception, each line holding three things: what the person noticed, what they decided, and what they did instead. The trigger is the valuable part. Steps you can reconstruct later; the cue that told a human to leave the standard path was never written anywhere.

Granularity is the hard part, and there’s a test for it. A line is specific enough when someone who wasn’t in the room could read the trigger alone and tell whether the case in front of them is one of those. “Sometimes the data doesn’t match” fails. The particular mismatch, in the particular field, from the particular source, passes. That list is then your specification: automate what’s on it, and treat anything absent as unhandled rather than assumed.

Two practical notes. Teaching has to sit inside the job, because otherwise it loses to the five-minute fix. A commenter described being the living documentation for a legacy PHP stack for three years, for an honest reason: “every time someone asked how the cron jobs worked, i’d fix it myself because explaining it took longer than doing it.” And the capture needs a named owner. Another commenter proposed the rule: “every time you get Dave’d, Dave gets time set aside by the one who manages Dave to update the documentation.” Without that, this becomes the thing you’ll do when work slows down, and it never slows down.

Then check it the only way that counts, by having a second person run the process while the expert is still there to correct them. A written handoff proves nothing about whether anyone else can do the work, an argument we’ve made at length in The Irreplaceability Trap.

What it costs, and the cheaper thing you should probably do instead

Be clear about the bill: the pairing is the cost. You’re paying two people for less than one unit of output while capture runs, because the expert slows down while being watched and asked why. The observer’s time is real whether or not it lands on a timesheet, and it has to be someone with enough context to recognize a departure as it happens, which is a scarce person in exactly the shops that need this most.

Be equally clear about when it ends, because the obvious stop rule is wrong. A quiet run does not mean you’re done. Exceptions cluster around the calendar and around particular counterparties: month end, the annual audit, the one client on a bespoke contract, the vendor who keeps changing their portal. Capture has to span the cycles that actually generate them. Stop at the first uneventful run and the list you keep will be missing precisely the exceptions that made this worth doing. Afterward there’s a smaller permanent cost, because processes drift and new exceptions keep arriving, so the slot for updating the list never goes away.

Given that bill, weigh the cheaper option honestly, because for a lot of processes it wins. Cross-train a second person by apprenticeship and produce no list at all. The exceptions transfer the way they were learned, by working beside someone, and you get redundancy in the role instead of a document about the role. That’s the right answer when your goal is continuity, when the work isn’t a candidate for automation, and when you have someone who can absorb it. The list earns its cost only when you intend to build something against it, when the exception set has to be shared wider than one apprentice, or when the holder is leaving and there’s nobody to apprentice.

Sometimes the answer is to do neither. If the process runs rarely, the person isn’t going anywhere, and a bad outcome is cheap to reverse, leave it alone. Some exception sets are pure judgment you shouldn’t want to automate at all.

Where outside hands earn their place is the part that keeps losing to Tuesday: capture competes with urgent work forever, and the observer it needs is the person whose time is scarcest. Sitting in the queue with your people, catching exceptions as they fire, and building against what’s actually there is a lane we run. Hold that offer to the same standard as everything above. The evidence here covers the problem and the reasoning, not our results on your process, and the only proof that counts is whether your team can run the thing once we’re gone.

Before any of that, there’s a number you can get for free, and it’s the one thing nobody can tell you from the outside: the gap between what your best operator can describe and what your best operator actually does.