Technical debt vs operational debt: Systems that work, eventually

Engineering organisations have become rather good at talking about technical debt. We measure it, we put it in quality gates, we negotiate time to pay it down. There is a second kind of debt that receives far less attention, even though it is often more expensive: operational debt, the debt that lives not in our code but between our systems, in the processes that hold them together.

To describe how operational debt behaves, I find it helpful to borrow a concept every Kafka engineer knows: eventual consistency. Many organisations run on what I would call eventually working systems. The monthly report goes out, the supplier gets paid, the customer receives an answer. In the end, every time. But only after a reminder, a spreadsheet, a manual correction and a colleague who stayed a little later than planned.

A short note for French-speaking readers, since “eventually” is a notorious false friend. It does not mean éventuellement. It means à terme, in the end. An eventually working system is not one that works now and then; it is one that always ends up working, at a price nobody has measured. That price is the subject of this post.

Two debts, two ledgers

Technical debt and operational debt are related, but they behave very differently.

The two feed each other. When a system cannot do what the business needs, someone builds a workaround around it: a spreadsheet, a manual check, a recurring correction. Technical debt in one place becomes operational debt everywhere around it.

What eventual consistency actually promises

Its promise is famously modest: if no new updates are made to a piece of data, all copies will eventually return the same value. At no given moment can you rule out inconsistent behaviour, and the only guarantee is that, at some point in the future, something good will happen.

Yet, a great many successful products are built on that guarantee. The reason is not the guarantee itself. It is everything engineers have built around it: measuring how stale the data really is, bounding the time it takes to converge, designing explicit compensation when copies disagree, and choosing data structures that cannot conflict in the first place. Eventual consistency works in production because it is surrounded by discipline.

Operational debt, seen as a distributed system

Look at a company through the same lens and the resemblance is striking. Teams behave like services. Emails, chat messages and meetings are the messages between them. The same customer, contract or figure lives in several places at once: a core system, a CRM, a spreadsheet, a slide deck prepared for Thursday’s committee. Those copies drift apart, and something has to bring them back together.

In a well-engineered system, that something is a protocol. In an eventually working organisation, it is a person.

Every recovery mechanism the architecture forgot is still there. It has simply been implemented in people. That is what operational debt looks like from the inside: the retry loop is a person.

Why this is not eventual consistency

It would be comforting to conclude that organisations are just another eventually consistent system and that all is well. The comparison breaks down precisely where it matters.

• It was never chosen. Eventual consistency is a deliberate trade-off, made for availability or performance. An eventually working process is what remains when a process was never designed, only accumulated.
• It is not measured. Engineers track consumer lag in seconds. Hardly anyone knows how long a customer request takes, on average, to converge through three teams and two spreadsheets, or how much that time varies.
• It is not bounded. A Kafka consumer that falls hours behind triggers an alert. A case that sits in an inbox for three weeks triggers nothing until a customer complains.
• Its compensations are improvised. A compensating transaction is designed, tested and reviewed. A manual correction is invented under pressure and remembered, if at all, by the person who applied it.
• Its convergence depends on specific people. A consensus protocol does not go on holiday. The colleague who knows which figure to fix in the Monday spreadsheet does.

There is also the matter of updates. Eventual consistency promises convergence only once updates stop, and organisations never stop: new products, new regulations and new exceptions arrive every week: Operational debt has exactly that quality. The organisation is always converging and never quite converged.

Finally, engineers know where eventual consistency must not be used. Nobody wants two cash machines to believe, at the same moment, that the same money is still available. Yet the flows that matter most, such as payments, customer commitments and regulatory figures, are very often the ones held together by manual convergence.

The interest on operational debt

Eventually working systems do work. That is precisely what makes their debt so hard to see and so hard to argue against. But the interest is real, and it is paid in three currencies.

Pain. It is paid first by the people doing the converging: the interruptions, the evenings, the quiet weight of knowing that if they do not check, nobody will. These are very often the most conscientious people in the building.

Cost. Every manual retry, reconciliation and correction is time that could have gone elsewhere. Because it is spread across many people in small increments, it rarely appears in any budget, which is exactly why technical debt gets discussed and operational debt does not.

Risk. Manual steps are where errors, fraud and key-person dependency concentrate. People are not idempotent: under pressure, the same correction gets applied twice, or not at all. Research on spreadsheets alone is sobering, with field audits finding errors in the vast majority of the spreadsheets examined. And when the person who makes a process converge moves on, the knowledge of how it converges often leaves with them.

Paying it down with lessons we already have

The encouraging part is that we do not need a new discipline. We need to apply one we already master to the second ledger.

1. Measure how eventual it is. Bailis and Ghodsi describe how measuring real systems showed they were consistent far more often than their weak guarantees suggested. Operational debt deserves the same honesty: measure how long a request takes to converge, and how much that varies. In regulated environments, a well-designed audit trail already holds most of the signal.
2. Bound the window. Decide how long “eventually” may last for each flow, and raise an alert when it is exceeded. An unbounded eventual is not a design, only a hope.
3. Make operations idempotent. A correction that can safely be applied twice, tied to a case identifier, removes an entire class of human error.
4. Make compensation explicit. Replace the improvised fix with a documented, tooled and reviewed correction. If a compensation happens every week, it is not an exception; it is a missing feature, and a line in the technical debt backlog.
5. Know where not to be eventual. For money, customer commitments and regulatory figures, invest in strong guarantees rather than in heroic convergence.
6. Take people out of the retry loop, and keep them for judgement. Machines are good at retrying. People are good at deciding what an unusual case means. Eventually working organisations tend to have these roles exactly the wrong way round.

Notice that half of these lessons turn operational debt back into technical work: a feature to build, a tool to provide, a guarantee to engineer. That is the real link between the two ledgers. Operational debt is often technical debt that was never written down, paid in instalments by people instead of being repaid once by a system.

The people in the protocol

I would like to end where this debt really lives. The colleagues who keep an eventually working organisation converging are not the problem to be solved.

Without them, the report would not go out and the customer would not receive an answer. They have been quietly compensating for design decisions they did not make.

The kindest thing we can do for them is not to thank them for another late evening. It is to measure what they carry, design the convergence into the system, and give them back their time for the work that genuinely needs a human being.

A system that works only eventually still works, right up until the day the person who makes it converge is on holiday.

What changes

Identifying and quantifying operational debt is the first step towards paying it down.

In the next post I’ll cover how Agentic Era will require a new level of operational excellence, with more than never the need to continuously improve the system, and the importance of having a written culture, documented processes and clear ownership to keep the system reliable.