Field notes,
filed properly.

The most expensive sentence in operations is "let's just automate it." Not because automation is bad — I build it for a living — but because automation is an amplifier. Point it at a clean process and it multiplies the cleanliness. Point it at three teams who define the same term differently, and it multiplies the argument, at machine speed, with a log file.

So the order of work is fixed: definitions, categories, and collection first; machinery second. At the twelfth Saudi Film Festival, the guest operation had six separate sign-up forms, each with its own manual routine. The tempting move was to automate the copying between them. The correct move was to make the six forms one — a single bilingual form carrying fourteen conditional rules — and only then let automation touch what came out of it, because what came out of it now meant one thing.

The same order held underneath. Before a logged mail-merge sent roughly 714 personalized messages, an automated quality layer of eleven checks had already run against the master list, and a written set of editing rules governed every hand that touched it. The machinery worked because the ground under it had stopped moving.

The test I use: if you paused the automation for a week, would the manual version produce the same numbers? If the answer is no, you don't have an automation problem. You have a definitions problem wearing an automation costume.

A dozen people editing one spreadsheet is not a data problem; it is a traffic problem. The festival's master list was live during the festival — hosting, registration, and messaging all ran off it while it was being edited — so the automation working on it had to behave like a careful driver, not an owner. These are the rules it worked under, and they generalize to any live, shared system:

Find every column by its header, never by its position. Someone will insert a column. Position-based code then writes phone numbers into the airline field, quietly.

Target every row by an identifier, looked up immediately before writing. Row numbers shift under sorting and deletion. An identifier doesn't.

Confirm before overwriting. If the cell already holds a value, the collision goes to a person. Overwriting silently is how two people's work becomes one person's mystery.

Read back after writing. The write you didn't verify is the write that didn't happen — or happened twice.

Keep blank, error, and missing rigorously distinct. A blank cell, a failed lookup, and "we never collected this" are three different facts. Collapse them and every downstream count is fiction.

None of this is glamorous. That's rather the point: the glamour budget went to the parts of the operation people saw, and these rules are why what they saw was correct.

Record matching sounds like a technical task until you watch it go wrong. Two lists, one person, slightly different spellings — and a system that guesses wrong has now merged two strangers into one guest with one seat at the opening ceremony.

The routine I built for the festival scored each candidate match on how many attributes agreed. High agreement matched automatically. Anything doubtful was flagged for a human to settle — not resolved by the machine's best guess. When a filmmaker list was merged into the master, all 32 email addresses were cross-checked and 328 cells were filled. The number I care most about in that sentence is the one that isn't in it: zero cells were invented.

The discipline generalizes past spreadsheets, and this is where it earns its keep: it applies to how you report your own results. Two figures once appeared in draft accounts of that engagement — an 80% improvement in data completeness, a 67% reduction in errors. Attractive figures. They could not be substantiated when checked, so they were removed, by me, from my own record. When the evidence runs out, the claim stops.

A number that collapses under a client's question costs more than it ever earned. The same is true of a matched record, a filled cell, and a bullet point in your own portfolio.

Near the end of the festival build I made an arrivals board — a live view of who was landing when, clean enough to put on a wall. I demonstrated it. It worked. The operations manager preferred printed manifests. The board was shelved, and the manifests shipped: a daily bilingual arrivals-and-departures pipeline, rebuilt around twenty to thirty times across the festival week, with own-car and no-reception guests excluded from pickups automatically.

It would be easy to tell that story as a compromise. It wasn't. It was the correct engineering decision, made on the client's terms instead of the tool's. A wall display serves a control room; a printed manifest serves a driver standing at an airport door at 2 a.m. The operation had drivers, not a control room.

The general rule: a deliverable is justified by the decision or the action it changes, and by nothing else. Not by its elegance. Not by how it will look in the portfolio. Not by the fact that you already built it — that cost is sunk, and shipping it anyway just makes the client pay maintenance on your ego.

So before anything gets built now, it answers one question: what will someone do differently because this exists? The arrivals board had no answer. The manifests did. That's the whole method, and it fits on an index card.