Technical Debt at Machine Speed

An executive told me his engineering organization had its most productive quarter on record. Output was up by a multiple no one could have proposed a year earlier. Then he mentioned, as an aside, that the team had stopped merging on Fridays because the review queue had grown long enough that nobody trusted what went out at the end of the week.

Both statements were true. They describe the same quarter. The first one is what the dashboard recorded, and the second one is what the organization actually did.

What debt meant originally

Ward Cunningham introduced the metaphor in a short experience report at OOPSLA in 1992, describing the financial system his team had built. Shipping code that was not quite right, he argued, was like going into debt. It let you deliver sooner. It also meant paying interest, in the form of every hour spent working around the shortcut, until the shortcut was repaid.

Two things about that formulation have kept it alive for more than thirty years, and both matter here.

The first is that Cunningham did not treat debt as a mistake. He treated it as a transaction. Borrowing is how organizations move faster than their current balance allows, and refusing all debt is its own kind of failure. The problem is never the borrowing. The problem is borrowing without recording the liability, which is how an organization ends up making payments on something it does not remember buying.

The second is that the metaphor is about a rate, not a quantity. Debt is manageable at any principal as long as the organization services it faster than the interest accrues. It becomes unmanageable when the accrual rate exceeds the repayment rate, and at that point the size of the original loan stops mattering. That distinction is the entire subject of this piece.

The word technical in technical debt is now the least accurate part of it. The same mechanics apply to a policy document nobody reviewed, a market analysis nobody checked, a process nobody validated, and a data pipeline nobody read. Every one of those is an artifact that later work will be built on, and every one of them can be wrong in a way that stays quiet for months.

The review bottleneck

Generation and validation were never the same activity, but for most of the history of knowledge work they ran at roughly comparable speeds. Writing a document took long enough that reading it was not the constraint. Producing an analysis took long enough that checking it fit inside the same week.

That relationship broke. Generation is now fast and cheap. Validation is still a human reading something carefully, and reading something carefully takes as long as it ever did. When one side of a coupled pair speeds up by an order of magnitude and the other does not move, the slow side becomes the constraint on the whole system, and everything upstream of it accumulates in a queue.

Adding reviewers does not resolve this the way it appears to. Fred Brooks made the argument in 1975 for software projects and the mechanism generalizes: bringing more people into work that is already late adds communication overhead and training burden faster than it adds throughput. Review is worse than average in this respect, because reviewing an artifact well requires holding its context, and context is exactly what a new reviewer lacks.

There is a second effect that is easier to miss. Lisanne Bainbridge described it in 1983 in a paper about automation that has aged into a permanent reference. When a system automates the routine parts of a task and leaves the human responsible for oversight, the human’s skill at the task degrades from disuse, while the situations that reach them become the hardest ones. Monitoring is also a poor fit for human attention, which does not sustain vigilance well over long stretches of things that are usually fine.

Apply that to review. A reviewer who no longer writes much of the underlying work loses the fluency that made review fast. The volume arriving means most of what they see is acceptable, which trains the expectation that the next item will also be acceptable. The items that are genuinely wrong arrive inside a stream that has taught the reviewer to expect correctness. That is the condition under which approval becomes a reflex.

Why volume compounds instead of adding

If unreviewed artifacts simply piled up, the problem would be arithmetic and the solution would be a bigger queue. They do not pile up. They get used.

An unvalidated artifact becomes an input. The analysis gets cited in a decision memo. The document becomes the template for the next twelve documents. The module gets imported. The process gets copied by an adjacent team who assumed someone had checked it. By the time the original error surfaces, it is not one error. It is one error plus everything built on top of it, and the cost of correction now includes finding all of the descendants.

The second compounding path runs through the reviewers. A queue that grows faster than it drains changes reviewer behavior, and it changes it in the direction that makes the queue worse. Facing more items, each item gets less attention. Less attention per item means a higher share of defects survive review. More surviving defects mean more downstream artifacts built on flawed foundations, which produces more work, which lengthens the queue.

The third path is the quietest. Once the queue is visibly hopeless, people stop treating review as a control and start treating it as a formality. Nobody announces this. It shows up as approvals arriving faster than anyone could plausibly have read the thing, and it shows up as the Friday merge freeze that the executive mentioned as an aside.

Compounding is why the honest measure is a rate rather than a total. An organization generating twice as much and reviewing at the same absolute rate is not accumulating twice the debt. It is accumulating debt that grows on itself.

The learning failure underneath

Underneath the queue is something older, and it is the reason the queue is tolerated.

James March drew the distinction in 1991 between exploration and exploitation. Exploitation refines what an organization already knows how to do. Exploration searches for what it does not, which means variation, experiment and a rate of failure that exploitation would treat as unacceptable. March’s argument was that organizations drift toward exploitation, because its returns arrive sooner and more reliably, and that the drift is self reinforcing: the better an organization gets at what it already does, the more expensive exploration looks by comparison.

Reviewing output is exploitation. Asking whether the output should have been produced at all is exploration. When generation capacity increases, the volume of things available to exploit increases with it, and the pull toward pure exploitation gets stronger. The organization becomes extremely busy refining artifacts it never questioned the need for.

Chris Argyris named the same failure in 1977 from a different angle. Single loop learning corrects errors inside the existing frame: the output was wrong, so fix the output. Double loop learning questions the frame itself: why is the organization producing this category of output, and what would we stop doing if we were honest about which of it mattered. Argyris’s finding was that organizations are structurally good at the first loop and structurally poor at the second, because the second requires people to surface assumptions that are embarrassing to hold in public.

An organization that only runs the first loop will respond to a review backlog by trying to review faster. It will not ask the question that actually dissolves the backlog, which is what share of the generated volume needed to exist.

And when an organization deploys AI into an environment without adaptability, where learning is expensive, where being wrong is punished, where experiments are treated as indulgences, the technology changes the tools but not the fundamental incapacity. The organization still cannot learn at the rate its environment demands.

From Builders Build, Chapter 9

Debt accumulation is that incapacity expressed in artifacts. An organization that learns quickly retires bad output quickly, because being wrong about something is cheap to say out loud. An organization where being wrong is expensive keeps the bad output, defends it, and builds on it.

The maximal day that produced negative value

Consider a specific day, because the abstraction hides how ordinary this is.

A capable team spends twelve hours at maximum output. They generate a substantial volume of code, three analyses, a revised operating procedure and a set of recommendation documents. Every hour is genuinely worked. Nobody is coasting, nobody is gaming anything, and the consumption figures for the day are the highest the team has ever posted.

Now account for the day properly. The code enters a review queue that was already longer than the team’s weekly review capacity, so it will sit, and while it sits other work will be written against assumptions about it. Two of the three analyses answer questions that no decision was waiting on, which means they will be read once and cited by someone who did not check them. The revised procedure was never validated against the constraint that made the old procedure necessary, so it will be followed until it fails and then quietly abandoned. The recommendation documents create decision points that now sit with executives who have no additional decision capacity than they had yesterday.

Count what the day cost the organization rather than what it produced. It consumed a day of a capable team. It consumed review capacity that other work needed. It added artifacts that will be paid for twice, once when they were generated and again when someone has to trace, correct or delete them. It added decisions to a backlog that was already the binding constraint.

The day was net negative. The dashboard recorded it as the best day of the quarter, and the dashboard was not lying. It was answering a different question than the one that mattered.

This is not an argument for producing less. It is an argument that production and value are different quantities, and that an organization measuring only the first will not notice when they separate.

Measuring retirement rate

The correction is unglamorous and it is available immediately, because it requires no new instrumentation.

Report retirement alongside generation. For any period, next to the count of what was produced, put the count of what was reviewed and accepted, what was corrected, and what was deleted. Those three numbers together are the retirement rate. The relationship between generation and retirement is the only figure that describes the balance rather than the borrowing.

A generation number rising while retirement stays flat is the signature of accumulating debt, and it is legible at a glance to anyone who has read a balance sheet. It converts an invisible liability into a visible one, which is the whole objective. Nothing about the metaphor requires the debt to be repaid. It requires the debt to be recorded, so that carrying it becomes a decision somebody made rather than a condition somebody inherited.

Three practices follow from the measure, and each of them is a governor on the rate.

Set generation capacity against review capacity explicitly. If a team can validate a certain volume per week, generating several times that volume is not throughput, it is borrowing at a rate the team has not agreed to. The constraint is the review capacity, and the honest planning conversation starts there.

Count deletion as output. Retiring an artifact that should not exist improves the balance exactly as much as validating one that should, and it is faster. Most organizations have no way to record this, which means the people doing the most valuable work in a debt heavy environment appear on the dashboard to have done nothing.

Make being wrong cheap. This is the Argyris point operationalized. If correcting an artifact costs someone reputationally, corrections will not happen, and the debt will be carried rather than retired regardless of what the measurement system says. Adaptability is the rate at which an organization converts experience into changed behavior, and no reporting change survives contact with an environment where changed behavior is an admission.

Debt is not a moral failing. It is a financing decision, and organizations that borrow deliberately outperform organizations that refuse to borrow at all. What separates the two cases is the ledger. An organization that knows what it owes can choose to carry it, pay it down, or take on more. An organization that does not keep the ledger finds out what it owes at the moment the balance comes due, which is always the moment it can least afford it.

Sources