The Empty Chair

In my experience, Software Development organizations spend a large fraction of their Maintenance & Run attention on work that fixes the immediate issues without solving the long-term ones.

That sounds like an accusation, so let me be precise: this is not a claim that engineers are slow, undisciplined, or badly managed. The work is good; the fix stays fixed. What vanishes is everything else the effort produces along the way. The problem survives good hiring, good tooling, and good intentions. It’s an operating-model problem, and its attributes don’t show up on the typical dashboard we run.

The business shape of it is simple. Does the problem of Maintenance & Run get easier over time? We fund it like an investment, but in reality it’s more like a lifetime subscription: the work doesn’t get easier, and there’s a lot of repetition in it.

We put a lot of stock into audit findings and postmortems, and talk a lot about discipline and prioritization. While they’re all necessary, they’re insufficient to the need. The real issue is that there’s a group of activities that are consistently given short shrift, a job that is unstaffed. There’s an empty chair in every software organization, and once you see it, you’ll see it everywhere.

Consider what an ordinary, productive day actually achieves.

The Anatomy of an Ordinary Day

A senior engineer on a mid-sized platform team starts the morning by pulling the next card off the Kanban board: a reporting bug that’s been undercounting a subset of records. She traces it, fixes it, writes a test, ships it by midday. Correct behavior, clean work.

After lunch, a message arrives from another team: how does the roll-up logic behind the weekly-actives view work in the data warehouse? She knows the answer (she built that view two years ago), so she spends forty minutes explaining it, with a query pointer and a caveat about a timezone edge case. Exactly the help the other team needed. The answer now lives in a chat thread: searchable in principle, findable rarely.

Next up: a version-upgrade ticket a junior engineer couldn’t quite close, a timely bump to patch a known vulnerability before it becomes a risk SLA miss. She picks it up, resolves one breaking change, runs the suite, and merges. Meanwhile, across the floor, a production incident has pulled four engineers into a call. They swarm, find a plausible cause, mitigate, and disband back to their sprint work. A root-cause writeup gets opened, and (as happens more often than anyone likes to admit) the documentation stops at just good enough to get by. The incident is over; the sprint is not.

A typical day. Every task necessary, every task done reasonably well. Now come back thirty days later and take stock. The defect stays fixed, but everything she understood while tracing it (where that class of bug comes from, what else it might touch) is fading fast. If the roll-up question comes up again, whoever answers it next starts from scratch, at full price. The breaking-change lesson from the upgrade may or may not reach the next engineer who needs it. The incident’s root cause is written down; the circumstances around it are not so cleanly immortalized. Hard-won knowledge is decaying rapidly.

What persists is the code: the fix, the patch. What evaporates is the understanding that produced them, and the understanding was the expensive part. Measure the day by what the team still has a month later, not by what it closed.

Now look back at the day and notice a recurring knowledge-keeping task hiding inside the four: capture what the trace taught her, make the roll-up answer findable, record the breaking-change lesson, finish the incident’s story. Real work, hours of it, generally considered impractical and optimized out with little thought. Truth is, few really want to do it anyway; there are more important matters to attend to. Implicitly, they’d rather pay the cost of discovery again sometime in the abstract future.

The Unmade Decision

Inside almost every unit of engineering work hides a fork.

• The transient path: answer the question, patch this instance, close the ticket.
• The durable path: make the answer findable, automate the upgrade, purposely look for patterns amongst the defects.

You won’t find the fork on the ticket. The ticket describes one road, and the estimate was written for that road alone.

The durable path looks like the expensive one, and on the day, it is: capturing takes longer than answering, automating takes longer than doing. But that comparison prices only the first payment, when there are typically multiple. Problems come back chaotically: some never resurface, others turn into constant churn, and it’s rarely obvious which is which when the ticket closes.

If the transient path is like a subscription model, the durable path is like a purchase. We keep choosing the subscription because its price hides in future sprints and other people’s calendars, while the purchase price sits right there in the estimate. Worse, we’re on auto-renew.

Yet the durable choice does something no amount of velocity can: it deletes work from future sprints before anyone schedules it. It manufactures time.

The Empty Chair

So why does the subscription keep winning? Look closely at the durable road: every step on it assumes a worker. Someone to make the answer findable, and keep it findable. Someone to automate the upgrade, and watch the automation. Someone to notice that three tickets this quarter were the same defect wearing different clothes. The durable path is priced as extra work for people who already have full-time jobs, because the job it actually describes has never been staffed.

That’s the Empty Chair, and it sits at fork after fork, sprint after sprint, company after company.

Knowledge Has a Half-Life

There’s a complication that makes the durable path harder than it looks, and a name worth borrowing for it: knowledge half-life.¹ Every captured piece of understanding (a wiki page, a chat answer, a root-cause writeup) is a snapshot of a system that keeps changing. From the moment it’s written, its accuracy decays. The half-life of a typical engineering document is months, not years: the service gets refactored, the roll-up logic changes, the diagram quietly stops matching production. The more documentation there is, the faster it seems to rot.

This is why “we should document more” disappoints so reliably. Teams pay the durable price and still end up holding a transient asset. No fairy comes at night to keep your pages true; keeping them true is work, and the worker was never hired. None of this argues against durable choices. It raises the bar for what counts as one: a durable asset isn’t one that was expensive to make; it’s one that stays true without being re-made. Very little of what we produce today clears that bar.

Structural, Not Cultural

The instinctive response to the vacancy is to treat it as a discipline problem: finish our RCAs, keep the wiki current, stop letting the backlog grow. In other words, keep the chair empty and ask everyone to take turns sitting in it. Most organizations make those resolutions at some point. They take real energy to sustain, and the energy fades until the next big incident sparks another round of the same resolve to do better.

The resolutions fail because discipline can’t staff a vacancy. The evaporation is structural: it’s the natural entropy of institutional knowledge, and no amount of resolve repeals it. Look at how the work is packaged: the unit of engineering work is the ticket, and a ticket’s life ends at closed. Nothing in the system asks whether closing it produced anything beyond the closure.

And nothing on the instrument panel asks either. Velocity, cycle time, tickets closed, uptime; flow metrics, all measure how fast work moves through. None of them can tell you whether the team that closed a thousand tickets last quarter is any better equipped for the next thousand. I’ve not found a robust way to measure that, yet. But you can ballpark it for your own team, and I suspect a leader who does won’t love the answer.

The same structure explains why root-cause analyses are so rarely fully successful, despite heroic efforts. The swarm is judged on time-to-mitigate, and rightly so; customers are hurting. But once the mitigation is in place, attention moves on, and the deeper fixes enter the backlog as ordinary tickets, weighed against feature work with named stakeholders and deadlines. Organizations close far fewer of their RCA action items than their own postmortems recommend. No one decides to abandon them; they just lose, one prioritization at a time.

Compensation Isn’t Correction

Watch what happens when the symptoms surface. Quality degrading? Launch a quality initiative: a themed sprint, a bug bash, a fix-it week. Knowledge walking out the door? Mandate documentation. Incidents recurring? Add a review meeting. Each response is reasonable. Each is also a temp placed in the Empty Chair: the team works at it for a week, the mandate hangs around for a quarter, and then everyone goes back to their day jobs.

The tell is what happens when the pressure comes off. The fix-it week ends and the backlog resumes its slope. The documentation push produces a burst of pages that start decaying on arrival, because nothing resets their half-life. The review meeting joins the calendar permanently, spending senior staff’s hours to re-propagate context the system loses by its very nature. Even with real diligence, the cost keeps coming: you pay it sprint after sprint, and it grows as the organization and its systems get more complex.

The Myth of Too Expensive

A caveat, in fairness: not every decision should be the durable one. Incidents must be mitigated now, whatever it costs. Some questions deserve a conversation, not a document. And there’s a real failure mode on the other side: organizations so devoted to building durable machinery that they stop shipping. Gold-plating the meta-work is its own way to waste a quarter.

Traditionally, capturing knowledge is expensive because it means writing a page in a separate system, where the half-life clock starts ticking immediately. Retiring a class of defect is expensive because the fix has to win a prioritization contest against features with deadlines. Neither cost comes with the problem; both come from working as if the chair must stay empty.

In the bedrock of this understanding is an assumption as old as the industry: the chair is impractical to fill, because no one worker could sustain so nebulous a job. Part librarian, part toolsmith, part pattern-spotter; always on, never in the way. That assumption has always held, which is exactly why nobody re-checks it. Later in this series I’ll argue it no longer holds, and that the price of durable is about to fall accordingly. When it does, the eyes-open choice starts coming out differently, one fork at a time.

While the Chair Is Empty

Start by seeing it. The chair is at sprint planning, where the estimate usually prices only the transient road. It’s in the dashboards, which have no gauge for work nobody assigned. It’s behind the fix-it week: the team attends to it for a few days, then reverts.

Then make the call at the estimate: transient or durable, one decision, eyes open, knowing who isn’t at the table. Plenty of forks should still go transient. Just stop pretending the other road is staffed when the durable path is needed.

And keep an eye on the price of durable. It’s high because we pay it as extra work from people who already have full-time jobs. That isn’t a law of nature; it’s the price of an empty chair. Prices like that don’t survive the arrival of a worker who can finally sit down.

Today, most hours spent fix one thing and are gone. That’s the operating model we inherited, built carefully around a vacancy nobody names. This series is about what happens when the vacancy gets filled.

A principle for the pivot: Invest in hours that compound value over hours that pay once.

Next in the series: the most expensive symptom of evaporating knowledge, the one your best engineers pay personally: The Archaeology Tax.

---

About this series: Next Quarter’s Normal is about how agentic systems are changing the way we build software. Today, though, we mostly apply agentic capability to assist our current practices. Useful, but not the point. The deeper opportunity sits in the problems we long ago filed under unsolvable, and in ways of working we haven’t imagined yet. We still build our tooling around the individual developer, when the heavy lift is getting an entire community to work in harmony. I don’t claim to have the answers; I’ve been building, and finding out. So each article closes by nominating one principle for the pivot: Waterfall to Agile took a re-imagination, and Agile to Agentic will too.

Footnotes

1. The idea is generally attributed to the economist Fritz Machlup, The Production and Distribution of Knowledge in the United States (Princeton University Press, 1962): the half-life of knowledge is the time it takes for half of what’s known in a field to be superseded. Machlup was among the first to treat knowledge as an economic resource — he put the knowledge industry at nearly 29 percent of US GNP — which is the frame this piece borrows along with the phrase. ↩