Your runway is a learning budget

One of the best decisions I have watched a team make was to knowingly write code that was not good enough, to answer a question in time for a funding milestone. They named the debt going in and accepted they would have to pay it down afterwards.

They never did. The learning told them to drop the path, the product went a different way, and the code was written off. The debt came due against something that had stopped existing.

That is a story about what quality is for, and about how long the code in front of you is expected to live. It is also a story about how fast a company can find anything out, and what that speed costs when the money is finite.

A team that takes the shortcut and then ships that exact code when the answer comes back positive has paid the full price and collected none of the discount. The discount was always contingent on being willing to delete. If the honest answer to “what happens if this works?” is “we ship what we have”, then nothing was shortened. That is just worse work with a story attached to it.

There is a real hazard here, and it is that “we suspended some practices so a small group could move faster” is indistinguishable, written down, from what every team already does in a bad month and calls an emergency. The difference is not sincerity. The panicking team is sincere too. The difference is conditions: one question, one bounded piece of the product, a date, the debt recorded somewhere a person will actually find it, and a genuine willingness to throw the work away. Miss any of those and you have the usual collapse with better vocabulary.

It is also worth being exact about what got suspended. That team did not drop to no practice. It dropped practices nobody had revisited in years and replaced them with current ones. “We suspended our practices” and “we replaced practices that had stopped earning their place” describe the same act and recommend opposite things.

So why was a shortcut the only way through? The question was not hard to phrase and the code to answer it was not hard to write. What sat between those two things was everything that happens to a change after someone finishes writing it.

A change on an engineer’s laptop has told you nothing. It becomes evidence at the moment a real person uses it and does something you can observe. Everything in between is transport, and transport is where the weeks go.

That team was well equipped. Tests ran on every commit, the deployment was scripted from end to end, and every stage of it was green. They also could not get a change in front of a user inside a month. Both of those were true at once and nobody in the company found it strange, because they had built the automation to answer a question about engineering hygiene, and it answered that question well. Nobody had asked how long it takes this company to find out whether it is wrong.

Almost none of the delay was machines. It was people waiting on people. A change sat until someone reviewed it, and the review mostly checked whether the code matched a house standard rather than whether it would do what the user needed. I am not arguing against review. I am arguing about what we weigh it with: standards are the part a machine is better at and never tires of, and every human review is a person holding a queue. Behind the queue sat a release window, and behind that an environment somebody else was using.

The number nobody has

The gap that mattered has a name worth giving it: evidence latency, the wall-clock time between having a question and having evidence. Not how long the code takes. The whole distance, from the moment someone says “I wonder whether users would” to the moment you know.

Most teams already measure something in this neighbourhood and none of it is this. Cycle time, lead time, deploy frequency and the rest all measure how fast work leaves the team. Evidence latency measures how fast an answer comes back. A team can be excellent at the first and hopeless at the second, which is exactly what green pipelines and month-long waits look like from the inside.

Reading it that way changes whose number it is. Deployment stops being an engineering hygiene figure that the engineers care about and the rest of the company tolerates funding, and becomes the ceiling on how fast the business can learn anything at all. Every question the company wants to ask has to pass through it. Nothing you believe about your customers gets checked faster than this number allows.

Runway is a learning budget

Every company I work with knows its runway to the month. The number is on a slide, the board has seen it, and anyone in the building can recite it. Almost none of them know it in the unit that decides whether they make it, which is how many times they can ask a question and get a real answer before the money runs out.

Those two numbers multiply, and you can do it yourself in about a minute. Take your runway. Divide by your evidence latency. That is how many attempts you have left, and some of them will be spent on questions that turn out not to matter. A team answering in a week and a team answering in five weeks have wildly different companies underneath the same slide.

What makes it worth doing is that the money has already gone. Salaries are being paid whether or not anyone learns anything this month, so the spend is fixed and the return on it is not. Evidence latency is the exchange rate between budget you have already committed and knowledge you acquire. Nothing about the burn changes when you improve it. What changes is how much the burn buys.

That is also why it belongs in front of a board rather than in an engineering plan. Nobody funds a request to reduce coupling. They will fund a request that says the company has six attempts left before the raise and could have twenty, because attempts before the raise is a unit the board is already tracking, and evidence is what the next round is going to ask for.

Buying evidence on credit

Reducing evidence latency takes time you may not have. If the question in front of you decides whether there is a company in nine months, and the honest answer is that the loop will take four of them to fix, the loop is not the thing to fix first. You need the answer before you need the pipeline that would have produced it comfortably.

So you borrow. You build the thing to a standard that would be indefensible if it were going to live, in a bounded piece of the product, and you get the answer early. The debt is real and you write it down as debt. That is what the team in the opening did, and it is why the milestone was reachable at all.

The cost of a shortcut is only owed if the code survives. That team never paid, because the answer they bought told them to drop the path, and debt secured against deleted code is not a debt. They did not get lucky in the way that phrase usually means. They bought an answer at a price that was contingent on the answer, and the answer came back negative, which is the cheap outcome.

Which is what quality is actually for. Quality is a bet on how long the code lives. A standard calibrated for code that will be maintained for years is the right standard for code that will be maintained for years, and it is overpriced for code whose entire purpose is to find out whether it should exist. Suspending it for a bounded experiment prices the work against the odds the work survives. That is a judgement, and judgement is why this needs people who will tell you when the shortcut has stopped being worth it.

Own less, then deploy more often

Borrowing buys you one answer. It does not raise the ceiling, and a company that borrows for every question ends up owing against code it kept.

Borrow somewhere being different is survivable: isolated enough that a lower standard cannot reach anything else. Isolation is what keeps the risk manageable, and it is what lets you defend the exception to everyone working outside it. Hold to that constraint. If you cannot find such a place anywhere in your system, you have learned something more useful than the answer you went looking for.

Raising the ceiling is different work and it starts somewhere counterintuitive. Most of the latency in the team I have been describing was not the pipeline. It was accidental complexity in technical decisions that had outlived their reasons, along with processes nobody had revisited. So the order was to challenge the processes and practices first, then choose technology that performed well inside the changed ones. Choosing the technology first and hoping the process follows is the common version and it does not work, because the process is what decides which technology has to be good.

Most of what came out was ownership. Custom solutions that existed for reasons that had expired, replaced with vendors or open source. If a thing is not your differentiation against a competitor, buy it, and when you are unsure, still buy it. Wardley mapping is the instrument I use for that conversation, because it makes visible which parts of a system a company is obliged to own and which it owns out of habit.

The map has a limit though, and this is where it went wrong for us. It tells you what looks like a commodity. It cannot tell you which of those a business is about to need. We could have dropped a great deal of complexity around currency and we did not, because the people closest to it argued it was where the business was going, and they were right. Complexity the plan depends on is not accidental complexity, and simplification without a second signal from the people who object removes the things you were right to carry.

The external check on all of this is the 2025 DORA report, which found that “teams working in loosely coupled architectures with fast feedback loops see gains, while those constrained by tightly coupled systems and slow processes see little or no benefit”. The same report found that AI adoption still has a negative relationship with delivery stability. Both point the same way. Less system to reason about is the lever, and once you have that, shipping more often gets safe instead of brave.

What it took

The whole engagement ran 12 to 18 months, and I want to be careful about that number, because it is the one most likely to make a reader with nine months of runway close the tab.

They did not back-load the improvements. They changed how the team iterated and deployed long before they touched the rest, and faster experimentation showed up within weeks in key parts of the team. Cadence went from months to days and weeks. The 12 to 18 months is what it took to work through the accumulated complexity across the whole estate, which is a different job with a different clock: the weeks are where the learning restarts, and the long stretch is what stops it degrading again.

That ordering is the part to steal. Capability first and narrow, complexity second and wide. It is also the only reason the funding milestone was ever reachable, because the bounded piece where they borrowed was not sitting inside a system that was still slow everywhere. It was somewhere that had already got faster.

The other return was one nobody had planned for. Owning less turned out to buy stability, and then a run of performance improvements that were never a work item. Complexity had been charging rent in more places than the roadmap could see.

Where this does not hold

Not all latency is technical, and the fastest way to waste a quarter is to rebuild a pipeline that was never the constraint.

The clearest case is one I see constantly. Requirements are unclear, so somebody books a meeting to get clear on them. Three hours later the room has agreement about words and not one new fact about a user. That is evidence latency with no transport in it at all: the question was asked, nothing was built, nobody observed anything, and the loop did not close. A team can have same-day deploys and still answer nothing, because it keeps trying to resolve empirical questions in conversation.

The second case is structural. If the person who can unblock a decision is available on Thursdays, the team runs at one decision a week no matter what the pipeline does. That is a scheduling problem wearing a technical costume, and no amount of delivery capability moves it.

The third is where slow is correct. Some changes are irreversible, some are regulated, and for those the blast radius is worth more than the speed of the answer. Evidence is the goal rather than the loop, and some evidence costs more to obtain than it is worth.

There is a limit on outside help too, and it is worth being straight about. Nobody rebuilds delivery capability in a two or three week engagement. In that company every engineer already felt the pain and could describe it accurately. What none of them had was a path from where they were to where they needed to be, and the sequence is a smaller thing to supply than the work. The work was theirs, it took them the better part of a year and a half, and the diagnosis in this article is one they could have reached without me if anyone had thought to measure it.

Measure it this week

Take the last three changes you shipped that were meant to answer something. For each one, measure the wall-clock time from the moment someone framed the question to the moment you knew. Count what elapsed, in days, rather than what anyone estimated.

Then find the largest gap inside that span that is not somebody writing code. It will be a queue, a window, an environment, an approval, or a meeting. That gap is where your runway is going, and it is almost always somewhere nobody is measured on.

For a good number of teams the exercise stops early, because the honest answer is that the evidence never arrived. The change shipped, everyone moved to the next thing, and nobody went back to look. That result is worth more than the measurement would have been, and it is a worse position than a slow loop, because the money goes out and nothing at all comes back.

None of this needs an outsider. If you take the number to the supplier or the team you already have and ask which part of that gap they would remove first, you will have a more useful conversation than the one you had last week.

Priced for permanence

The teams this happens to are not neglecting their practice. They believe they are doing the right things and they are sincere about it, and measured against their own standards they are right. Strip it back to first principles and the processes have quietly become impediments rather than the thing they were built to be. The practice is present. What it was for is gone.

Every one of those practices was priced for code that would live. Nothing in the ceremony ever asks how long a particular change is expected to survive, so the question never gets asked and never gets priced, and every experiment pays production rates for durability it will never use.

The team in the opening asked it. They decided that one piece of code was a question rather than an asset, priced it that way, and had their answer while it still mattered. The code is gone. The answer is still in the company.