What Happens When the Air Traffic Controller Goes on Vacation

Friday. The air traffic controller is out.

Maybe they're on a plane. Maybe they're in back-to-backs. Maybe they're out sick. It doesn't matter. Slack fills with the same three messages: "who knows how X works?", "who can approve this?", "who remembers why we did it that way?"

Work doesn't stop. Context does.

You didn't lose a coder for a week. You lost the map.

In the last article, The Air Traffic Controller Problem, I argued that every team needs an air traffic controller: someone in the work, not above it, who sees the whole system and decides where independence helps and where coordination is necessary. That still holds. The role is real. Most teams don't staff it. When they do, they usually staff it as a hero.

This article is about what happens next.

Because a person who holds the whole-system view in their head is still a weak system. The test is not whether you have an ATC. The test is whether the org can still see when they're gone.

The Intuitive Fixes All Fail the Same Way

The first instinct is to hire another one.

That gets you coverage. It does not get you a system. Now you have two people who each hold part of the map, and a new coordination problem between them. When both of them are in the same meeting, the org is fine. When neither of them is, you are back to Friday Slack.

The second instinct is documentation.

Write it down. Wiki it. Record the decision. That sounds like designing yourself out. Sometimes it even works, for a while. Then the page goes stale, the decision gets reversed in a thread nobody links, and six months later the wiki is a museum of what used to be true. People stop trusting it. They go back to asking the person.

The third instinct, now, is to paste it into the model.

Bigger context windows. Project files. Rules. "Memory" features. You stuff the transcript, the RFC, the architecture doc, last week's corrections into the next session and hope the model figures out what is current. It works until paragraph 12,000 contradicts paragraph 47,000, or Tuesday's decision was supposed to replace Monday's and nobody told the window.

All three fixes share a shape. They treat the map as a pile. They ask an unreliable actor (the next hire, the wiki, the model) to enforce what is true. They do not give you a system that knows what superseded what, what depends on what, and what is still unknown.

A pile is not a view.

This Series Already Named the Disease

I started writing Product Engineering because most teams treat product development as a backlog problem: prioritize, estimate, execute. That is wrong. The real constraint is uncertainty. Teams either absorb it or fight it.

Fighting it looks like excessive process, certainty theater, and the trust tax. CYA docs. Defensive architecture. Decisions made to avoid blame. The best people keeping the real picture in their heads because telling the truth out loud is expensive.

The ATC is the human answer to one piece of that. Someone has to see across the seams. Someone has to stay in the work so the coordination stays relevant. Someone has to design themselves out, or they become the bottleneck they were hired to remove.

But look at what the earlier articles actually require:

Fast/Good/Well only works if teams can choose independently. If the reason last quarter's "Fast" is still load-bearing lives in one person's head, nobody else can make the next tradeoff.
Known vs unknown unknowns only stay useful if the org can tell them apart. Unknown unknowns that got named last month and then trapped in Slack are not known. They are lost.
Certainty theater is what you get when the map is a person. You cannot afford to be wrong in public, so you wait for the hero to come back and tell you what is true.
High autonomy through high visibility is the management version of the same bet. Autonomy without a shared view is just isolation. Visibility that routes through one calendar is just a quieter form of micromanagement.

The series keeps landing on the same reframe: how wrong can we afford to be, and how fast can we recover?

You cannot answer that if the recovery path is "wait until Monday when Jordan is back."

The View in One Head Has a Name

Software engineering already had a metric for this. The truck factor (sometimes the bus factor) is the number of people who have to disappear before a project is incapacitated. Guilherme Avelino and colleagues estimated it across 133 popular GitHub projects and found that 65% had a truck factor of two or fewer¹. Most of the systems we treat as resilient are one or two people from stalling.

That number is about code authorship. The organizational version is worse, because the load-bearing knowledge is not only in the repo. It is in the Slack thread where the decision actually got made. It is in the meeting that never got written down. It is in the correction you gave the model three times this week that will not be there on Friday.

Atlassian's 2025 developer experience research found 68% of developers save 10+ hours a week with AI tools, then 50% lose 10+ hours a week to organizational inefficiencies: finding information, context switching, collaborating across teams². Atlassian's own framing is the wash. The work is not the bottleneck. Reconstructing the map is.

You already knew this as a manager. The staff engineer who is in every thread. The founder who is still the implicit ATC. The principal who can explain how the pieces fit, and who therefore never gets to build. The last article's anecdote was that person getting turned into a full-time router. This article's point is what the org does when the router is offline.

It starts from zero.

Every Session Is a First Date

I noticed the same pattern in a different place.

At the start of 2024, a problem started keeping me up at night. I had been using AI tools every day for over a year: writing code, thinking through architecture, leaning on them the way you lean on a colleague who is always available. And every conversation started from zero.

The model did not know I had already made a decision about the database. It did not remember that I had corrected it three times about how I name things. It did not carry yesterday, or last week, or the project I had been grinding on for months.

Every interaction was a first date.

That is not a new observation. Anyone who uses these tools seriously has bumped into it. What kept nagging at me was the shape of the solution the industry was shipping.

Bigger context windows are brute force. Stuff more tokens in. Hope the model figures out what matters. It works until it doesn't: when Tuesday was supposed to replace Monday, when the constraint you named in January is now load-bearing and the model treats it as color.

Bolt-on memory features are organizational metaphors dressed up as intelligence. ChatGPT Memory, Claude Projects, Cursor rules files. They let you attach things. They do not understand things. There is no awareness of what is current versus stale, no propagation when a fact changes, no scoping for who should see what.

They're filing cabinets with an AI label.

If that sentence feels familiar, it should. It is the wiki problem. It is the Slack-as-source-of-truth problem. It is the ATC-in-one-head problem, running at the speed of a new session every morning.

Opaque memory is the trust tax for machines. You cannot inspect it. You cannot supersede it on purpose. You cannot audit why the model said what it said. So you paste the context again, "just to be safe." That paste is CYA documentation. Same behavior. Faster loop.

This Is Not a Machine Learning Problem

The industry keeps trying to solve "my AI doesn't remember" with more model. More parameters. More window. More retrieval bolted onto the side.

That is the wrong layer.

The problem is state management. It is scope isolation. It is consistency, conflict resolution, change propagation: the work database engineers and distributed systems people have been doing for decades. Nobody needs a new neural network to know that a correction should replace the thing it corrected, or that a known unknown should show up as a known unknown instead of a confident guess.

Weak systems ask the unreliable actor to enforce truth. In orgs, that actor is the hero, the wiki, the approval chain. In AI, it is the model: a next-token predictor being asked to remember what is true, what changed, and who is allowed to see it.

Strong systems put truth somewhere that can absorb uncertainty without pretending. They assemble what matters for this decision, this budget, this scope. They represent what they do not know instead of hallucinating through the gap. They stay when the agent is disposable.

That last sentence is the ATC failure mode, restated for software. Agents are disposable. The view should not be.

Why I Started Building Anneal

I wrote this series to reverse-engineer how product teams actually decide under uncertainty. Fast/Good/Well. Known and unknown unknowns. The cost of certainty. The trust tax. Autonomy that does not go blind. An air traffic controller in the work.

Building Anneal is the productized version of the same move.

The move is: do not ask the unreliable actor to enforce what is true.

Not the model. Not the hero. Not the wiki that went stale in March.

Put truth in an engine that assembles context on purpose. Facts that can be superseded. Corrections that propagate. Known unknowns that stay named instead of getting smoothed into a fluent answer. A view you can inspect, not a transcript you hope the next session will reread correctly.

I am not going to walk a feature list here. This is not a pitch. The point is architectural, and it is the same point the last six articles have been making about teams:

Fast work should be cheap to throw away. That only works if the learning is not trapped in the session that produced it.
Good work should stabilize known unknowns. That only works if "known" is a property of the system, not of whoever was in the room.
Well work should remove specific brittleness. The brittleness here is starting from zero: every Monday, every new hire, every new chat.

Anneal sits between you and whatever model you are already using. The model never remembers. The engine does. That is the whole bet, and it is a systems bet, not a model bet.

I started it because I could not unsee the isomorphism. The org that cannot operate when the ATC is on vacation, and the engineer who re-explains the same decision to a chatbot for the third time this week, are paying the same tax. One is slower. One is more obvious. The receipt is the same: the view lived in the wrong place.

This Doesn't Change With Scale

A common dodge is "that's a startup problem" or "that's an enterprise problem." It isn't. The blast radius changes. The underlying failure does not.

Startup. The founder is the ATC, implicitly, because they built most of it. Then the founder gets on a plane. Or takes the week off after a hard ship. The company discovers that "we all know how this works" meant "one person knows how this works." AI makes the same discovery every morning: the session does not know the product.

Mid-market. You named the role. A principal, a platform lead, a head of revops. They are in every thread because they are the only ones who can see the seams. They cannot go on vacation without the org noticing. Documentation exists and nobody trusts it. The model has a project file that is six weeks out of date.

Enterprise. The role federates. You get ATCs who each own a domain, and still nobody owns the seams between them. Institutional knowledge is in Confluence, SharePoint, and the heads of people who will leave this year. You buy an "AI assistant" and watch it confidently cite a policy that was superseded two reorgs ago.

No organization graduates from this. They only graduate into more expensive ignorance.

The strong-system version is the same at every scale. Make the view a property of the system. Make supersession explicit. Make unknowns visible. Make recovery possible when the person (or the agent) is gone.

Connecting to the Series

This is the seventh piece in a single argument.

Decision-making is the constraint, not talent. What you are trading off is uncertainty. Chasing certainty postpones learning. Low trust makes telling the truth expensive, so the real picture hides in people. Autonomy needs visibility that does not route through a meeting. Every team needs an ATC who stays in the work.

And the ATC's job is to design themselves out.

That last sentence is only possible if the view can live somewhere other than a person. Otherwise you have renamed the hero and called it a role.

Anneal is what I am building because I got tired of diagnosing a disease I was also living in. I do not think it is the only way to put the view in a system. I do think "paste more context" and "hire another hero" are not ways.

The View Can't Live in One Head

The best air traffic controllers are invisible. Planes land. No collisions. Nobody thanks them.

The best organizational ATCs look the same, until Friday, when you find out whether the view was in the system or in them.

If they cannot go on vacation, they haven't finished the job. If the org cannot answer "why did we decide X?" without waiting for a person, you do not have institutional knowledge. You have a bottleneck with a good reputation.

The question this series keeps returning to still holds: how wrong can we afford to be, and how fast can we recover?

You cannot recover fast if the person who knew is at the beach.

Every team needs an air traffic controller. Most just don't know it yet.

What they need next is a system that still knows what's true when that person is gone.

References

Guilherme Avelino, Leonardo Passos, Andre Hora, Marco Tulio Valente, "A Novel Approach for Estimating Truck Factors," IEEE 24th International Conference on Program Comprehension (ICPC), 2016. 133 popular GitHub projects; 65% had a truck factor of two or fewer. Open-access version: https://arxiv.org/abs/1604.06766. DOI: https://doi.org/10.1109/ICPC.2016.7503718 ↩
Atlassian, "State of Developer Experience Report 2025." Survey of 3,500 developers and managers across six countries; 68% save 10+ hours per week with AI tools; 50% lose 10+ hours per week to organizational inefficiencies. https://www.atlassian.com/blog/developer/developer-experience-report-2025 ↩