The Empty Chair

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 operating models don’t show up on any dashboard you currently 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 totally insufficient to the need. The real issue is that there’s a group of activities no one has the time for, a job that has never been staffed. 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 never.

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. The leak worth watching isn’t what the day closed; it’s what the team has lost just a month later.

Now look back at the day and notice a recurring 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, no one really wants 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.

Note: This fork is easily confused with technical debt, but debt is what piles up after the transient road is taken; the fork comes first.

The durable path looks like the expensive one, and on the day, it is: capturing takes longer than answering, automating takes longer than doing. That math holds only if the problems stay solved. They don’t. They come back chaotically: some never resurface, others turn into constant churn, and it’s rarely obvious which is which when the ticket closes. The transient path is the subscription model, whereas the durable path is 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 every fork, in every sprint, at every company.

Knowledge Has a Half-Life

Why hasn’t this role materialized after all this time? 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.

And none of this shows up on the instrument panel. 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 it, yet. But you can ballpark it for your own team, and I suspect a leader who does won’t love the answer.

Structural, Not Cultural

The instinctive response to the vacancy is to treat it as a discipline problem: finish our RCAs, document more, 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. 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. The incentives, the metrics, and the ceremonies all measure flow through the queue; none of them measure what accumulates.

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 the most diligence, its cost never ends: you pay it every sprint, and it grows with the complexity of the organization and its solutions.

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 can’t be filled, because no worker could succeed at 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 every estimate prices only the transient road. It’s in the dashboards, which have no gauge for work that was never assigned. It’s behind every fix-it week: the whole 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, every hour spent fixes one thing and is gone. That’s the operating model we’ve all inherited, built carefully around a vacancy nobody names. This series is about what happens when the vacancy gets filled.

A principle for the pivot: Hours that compound over hours that close.

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

About this series: a quarter century ago, a small group of practitioners stepped back from how software was built and asked what they actually believed. The Agile Manifesto reset the industry’s principles for a generation. I think we’re at that kind of moment again. Most of today’s AI energy is aimed at the problems we’ve wrestled with for decades. 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 new manifesto. I’ve been building, and finding out. So each article in this series closes by nominating one principle for the pivot: Waterfall to Agile took a re-imagination, and Agile to Agentic will too.