Work someone else can run

I have left five accounting firms, a corporate finance function, and a couple of departments, and in every one of them I left behind something I had built. A reconciliation process. A payroll reporting routine. A close checklist. A way of getting from one system’s output to another system’s input without a person retyping it.

Every one of those was correct when I handed it over. Correct in the strong sense: it produced the right number, it had been tested against the prior period, somebody who did not build it had reviewed it.

And the reliable event, four to eight weeks after leaving, is a message asking what to do because the file came through with an extra column this month.

The presence you cannot see in your own work

While you are in the building, you are a component of the system.

Not in a self-important way. It is just that everything you know is silently part of the design. You know which of the two supplier codes is the real one. You know that the March figure always looks wrong for a week and then corrects. You know the process assumes the file arrives sorted, and you have never written that down because you have never seen it arrive unsorted, because the person who sends it knows you and sorts it.

So the thing runs. It looks finished. What is actually happening is that you are quietly finishing it every month, in about four minutes, using judgment you do not experience as work.

Correctness is testable while you are there. Transferability is not, and that is the whole asymmetry. You cannot sit the test. The test is administered exactly once, after you have gone, by somebody who cannot ask you the question, and by then the result is somebody else’s problem and you never hear the score.

The remedy that did not take

My first response was documentation, and more of it. Longer procedures, screen by screen, every step numbered, which is the same mistake I have made with written procedure everywhere else.

It did not help much, and the reason is that steps were never the missing part. The person picking it up could see the steps. What they could not see was the set of judgments about what to do when the input is wrong, which is not a list, does not decompose into instructions, and is roughly ninety percent of why the thing worked.

The version that helped was cruder and slightly humiliating. Hand it over while you are still there, then sit in the room and say nothing while they run it. Not a walkthrough. Watch them do it and write down every place you wanted to interrupt. That list is the actual undocumented design, and it is never the list you would have predicted.

Transferable often means rigid, and rigid is a downgrade

I do not think transferability is a universal good and I have watched it applied as though it were.

Making work runnable by anybody usually means making it more rigid. You replace a judgment with a rule, and the rule is right in eighty percent of cases and mechanically wrong in the rest, and the rest used to get handled by a person who noticed. There is real work that should stay with a person, and forcing it into a form somebody else can run is not maturity, it is a decision to accept a worse output in exchange for continuity. Sometimes that is obviously right. Sometimes it is a downgrade nobody records as one.

The uncomfortable part is that you cannot tell which you are doing at the moment you are doing it. It only shows up later, in the cases the rule handles badly, and by then the person who would have noticed is not there.

I have handed over processes I was proud of and watched them get simplified, within a quarter, into something I would not have written and would not defend. Mostly I have stopped taking that personally. Not entirely.