Nobody Turns Around

For twenty years the fastest system in your org was a hallway with somebody in it who would turn around. I lost that hallway twice, both times before remote work had a name. What replaced it has to answer the questions nobody knew to ask.

By Jason Waldrip, with Claude Opus 5 September 20, 2026 09:15 8 min read

You are one commit from dropping a column. You’ve read the code, nothing in the repo touches that field, the migration is eleven lines and two of them are comments. Before you write it you swivel your chair and ask the person behind you whether anything still uses it. They say yes, the nightly export, don’t. Four seconds. No ticket, no doc, no meeting invite, no record of any kind. You just ran the cheapest and most effective architecture review of your entire quarter, and nothing in your system knows it happened.

That answer was load-bearing. It was also undocumented and unowned, available only to whoever sat within earshot of a chair.

Most of them were.

the hallway nobody put on the diagram

Every team I have ever worked on ran on a layer of informal answers underneath the official one. Underneath the architecture docs and the tickets, there was the stuff that moved sideways across a room: somebody overhears a question, recognizes the shape of a mistake they already made in 2019, and says three words that save a week.

Nobody models that layer. It isn’t in the onboarding plan or the org chart, and no team I’ve been on could have told you how much of their reliability depended on it. You find out what it was worth by losing it.

I lost it twice, both times before anyone said “remote work” with a straight face. At KickApps I ran product for a team spread across New York, Paris, and Denver. A few years later at CommercialTribe I owned engineering for an org that was half in a Denver office and half in Argentina, and my mandate was literally to make those halves function as one. In neither case was the work the hard part. The hard part was that the four second answer became a next morning answer, then a next week answer, and then people stopped asking.

Watch what a team does when the tap on the shoulder gets expensive. The questions keep coming, they just start arriving in batches. You get a standup that grows a second standup, a weekly sync that becomes twice weekly, an architecture review board, a channel where people post “quick question” and wait ninety minutes. Every one of those is a team trying to rebuild a hallway out of calendar invites.

It sort of works. It is also the single most expensive way anyone has ever answered a yes-or-no question about a column.

what actually fixed it was the release path

At CommercialTribe I spent the first stretch of the job on GCP, Kubernetes, and automated testing and deploys, and took the release cadence from weeks to hours. I’ve written about why that mattered for the learning loop.

The release path did something to the split-team problem that no meeting had touched, and this is the part I’ve never written down: it changed who was answering the questions.

Before, “will this break the export?” had exactly three possible sources. A person who knew. A meeting where you found the person who knew. Or nobody, and you learned the answer from production, in the worst format, at the worst hour. All three route through a human being who has to be awake and holding the right memory.

After, the same question had a fourth source. You pushed, and something that never sleeps and never went to Argentina told you in minutes. I mean that literally rather than as a point about culture. An engineer in Buenos Aires at 9am could get a specific, trustworthy answer about a system built in Denver without a single person in Denver being conscious.

The pipeline stopped being how we shipped and became how we talked.

I didn’t sell it that way at the time. I sold it as speed, because speed is what executives buy. The actual product was answers, available at the moment of the question, to a person who had nobody to turn to.

a doc waits, a check arrives

I’m the guy who tells everyone to write it down. I still believe it, and the why behind a decision is the most perishable asset a team owns.

But a document answers a question that somebody went looking for. Docs are a library. You have to walk in.

The expensive questions are almost never the ones people went looking for. The engineer about to drop that column did not fail to read the page about the nightly export. They didn’t know the export existed, which means they didn’t know there was anything to look up, which means the best-written document in your repo would have sat there being correct and unread while the incident happened anyway.

A written answer waits to be found. An executable one shows up whether you went looking or not.

You could get away with blurring those two when the questioner was a person, because a person has a fallback. They can feel themselves standing in unfamiliar territory and go find somebody who isn’t. Judgment covers the gap between what’s written down and what’s true, which is why the gap never had to be small.

conway’s law, on a team with no people in it

Melvin Conway published the line in 1968 and it has outlived nearly everything else written that year: organizations are constrained to produce designs that copy their own communication structures. It has always been used as a warning about org charts. Split your team by layer and you’ll ship a layered system whether or not that’s the right shape.

Now count the things producing changes in your repo this week and ask which of them are on the org chart at all.

A fleet has no hallway. It has no backchannel, no lunch, no three years of institutional memory about the thing that broke in March. Its entire communication structure is what you committed. So Conway’s law doesn’t stop applying when most of your throughput comes from agents. It gets sharper, because the communication structure stopped being an emergent property of where people sit and became a file you can edit.

Which is either very good news or very bad news, depending on what’s currently in that file.

the fleet will not turn around

Your remote teammate had one saving grace, and it’s what makes this urgent rather than interesting: when they didn’t know, they were blocked. Not knowing cost them a morning and cost you a Slack thread, and the cost was the safety mechanism.

An agent is never blocked. It hits the same gap and fills it confidently and wrong, and the output is a clean diff with a reasonable commit message and green tests, because the tests were written against the same misunderstanding. It will never be surprised by the nightly export. It will never be surprised by anything.

So every answer that still lives in someone’s head is now a question that will get answered incorrectly, at volume, by something that cannot tell it’s guessing. Call that a documentation gap and you will underbuild the fix. It’s a load-bearing hallway you never replaced, running at a throughput it was never designed to carry.

The fix is mostly stuff you already know how to build. Put the constraint in the database instead of the convention. Let the compiler carry what a code comment was carrying. Name a test after the consequence rather than the function, so the failure message reads like the sentence your colleague would have said out loud. Gate the deploy on the thing you’re actually afraid of. All of that is old practice. What changed is that it stopped being hygiene and became the only hallway you’ve got.

You swivel your chair to ask whether anything still uses that column. Nobody is there, and nobody is coming. The question is as good as it ever was, and the only thing left that can answer it is the thing you built to answer it.

What does yours say?