The checklist: are you flying blind?

Walk with me for a minute, because aviation figured out our problem a century ago and wrote the answer in blood.

Early pilots flew by feel — and by feel, in clear weather, they were good. Horizon out the window, wind on the wires, seat of the pants. Then they started flying into clouds, and something horrifying was discovered: without a visible horizon, the human inner ear doesn't just fail to tell you which way is up — it confidently lies. A pilot in cloud, flying by sensation, will roll into a gentle turn, feel perfectly level, pull into a tightening spiral, feel perfectly level, and continue feeling perfectly level all the way down. The killer wasn't ignorance. It was false certainty — a cockpit full of vivid, trustworthy-feeling signals that had quietly disconnected from reality.

Aviation's response became one of the great safety revolutions: instrument flight. Not better intuition — replaced intuition. A trained pilot in cloud ignores their screaming inner ear and believes a little gyroscope, because the gyroscope has no inner ear to fool. And the discipline that keeps pilots honest about which regime they're in is charmingly unheroic: the checklist. Not because pilots are stupid — because confidence is not a sensor.

Now, your engineering org. For its first decades, software leadership flew by feel too, and mostly got away with it — codebases were small enough to fit in a tech lead's head, code arrived at human speed with human authors who winced when they cut corners, and the weather was, roughly, clear. This series has spent twenty-seven parts arguing that the weather changed: authorship went anonymous (Part 21), review went theatrical, volume went to generation speed, and the mental instruments everyone was navigating by — "our people know the code," "we review everything," "it feels solid" — became inner-ear signals. Vivid. Trustworthy-feeling. Disconnected.

And the cruelest part of the analogy holds: signals that disconnect don't announce it. Your veteran engineers still have strong intuitions — that module feels risky, this deploy feels fine — and those intuitions were calibrated on a codebase that no longer exists: smaller, human-written, moving at a tenth of today's volume. An instrument that was accurate last year and is wrong now is more dangerous than no instrument at all, because you still trust it. That is what "the inner ear lies" means in engineering terms. Nobody's intuition degraded. The weather it was calibrated for just left.

The question is not whether your team is talented. The pilots in the spiral were talented. The question is what you're navigating by — and the honest way to answer it is the same way aviation does: run the checklist, out loud, no skipping items because "that one's basically fine."

Twelve questions. Four themes — what you can see, whether your review is real, where your debt is, and what your team is actually spending itself on. One point per true statement. Count honestly; the sky doesn't grade on effort. And a scoring note: if a statement is true for any meaningful slice of your production system, it counts — partial blindness in the one place that matters is the whole ballgame.

What to do with your number

First: whatever you scored, you now know something most engineering orgs never establish — which flight regime you're in. That alone puts you ahead, because the deadly failure mode was never a bad score. It was a bad score plus the feeling of a good one.

Second: resist the instinct to fix all twelve items. That's a two-year program disguised as a to-do list, and you'll abandon it by August. The items are not equal. Nearly every one of them becomes dramatically easier once the visibility theme is handled — you cannot weight debt by load, guard critical paths, or measure the firefighting ratio for a codebase you can't see. Fix the seeing first. Everything else is downstream of the gyroscope.

Third: put a re-run on the calendar — quarterly is right for most teams — and track the score like you track revenue. A 7 falling to 4 is a genuinely better story than a lucky quarter of shipping, because the 4 compounds. (If you want the continuous version instead of the quarterly ceremony, per-function production telemetry is the instrument panel this checklist is approximating by hand — that's the product we build, and Part 30 makes the full argument. But the checklist is free, and honest, and you can run it today.) Scores are also comparable across teams in a way vibes never were: if you run three squads, run three checklists and put the numbers side by side — the spread tells you where your next senior hire, or your first instrument, actually belongs.

Fourth: run it with your team in the room, not on them from a distance. The score isn't a grade — it's a shared map of where the org is navigating by sensation, and the people closest to the code will amend your answers in both directions ("actually, we DO track that" and, more often, "oh, it's worse than you think"). The checklist read aloud does something no dashboard does: it makes the blindness discussable without making it anyone's fault. Aviation figured that out too — the checklist is called out loud, by two pilots, precisely so that neither one has to be the hero who noticed.

Clear skies are lovely. Instruments are for the other days — and the forecast, per the last twenty-seven parts, is clouds.