The Run Tail: Why Every Project You Deliver Makes the Next One Slower

Your organization delivers less change than it did 4 years ago. Not for want of trying: the team is the same size, the people are at least as good, the tooling is better, and nobody is slacking. Ask around for an explanation and you will be offered culture, or governance, or the fact that the easy things have all been done. Somebody will say the organization has lost its edge, and almost nobody will point at the keep the lights on work.

None of those is the cause. The cause is arithmetic, and it is a consequence of your success rather than your failure. Every system you have ever delivered is still running, and every one of them draws a small, permanent, unbudgeted quantity of your scarcest specialists' time. That draw never appears in a plan, because the project that created it closed years ago. It compounds, because you add to it every time you finish something. And it is subtracted from exactly one place: the capacity you have left to build the next thing.

Most organizations already have a name for this draw: keep the lights on work, the budget line for running what already exists. The label is useful, because it admits the work is real. Where it stops is that it is counted in money, as a steady share of the budget, while the hours come out of your scarcest specialists, the same people who would build the next thing. Measured in those hours, it is not a steady share of anything. It grows every time you deliver.

The effect needs a name, because an unnamed drain gets absorbed rather than managed. Call it the run tail: the permanent claim on constrained capacity that a delivered system makes for the rest of its life, created by a decision that priced only the build.

You already know the symptom. Your delivery rate is falling and your people have never been busier. Those two facts are not in tension. They are the same fact.

Keep the lights on: the capacity you spent without ever deciding to

Numbers make the shape concrete. The figures below are illustrative, but the pattern is one I have watched play out in organization after organization.

A change portfolio runs everything through a platform engineering team of nine people. They are the constraint: nothing ships without them, and everything queues for them. Each contributes about 28 productive hours a week once meetings, interruptions and administration are stripped out, across roughly 46 working weeks. That is 11,592 constraint-hours a year, and it is the true capacity of the organization to deliver change.

An hour of that team, spent on new delivery, returns about $900 of value. That is the value per constrained resource hour the organization is actually being paid on, and it makes the annual throughput of the whole enterprise about $10.4 million. A typical delivery consumes around 800 constraint-hours to build, so a planner looking at that team would conclude, quite reasonably, that they can sustain about 14 deliveries a year.

Now the part the planner has not priced. Each delivered system leaves behind an ongoing draw on the same nine people. Not a project, not a program, nothing with a name: incidents that only the people who built it can diagnose, a vendor patch cycle, an access request, a schema change, audit evidence, a quarterly certificate rotation, and the steady drip of questions that begin "sorry, quick one". Call it 2 hours a week, which is a figure most engineering leads recognize as conservative when they actually count.

2 hours a week, 46 weeks, is 92 constraint-hours a year, per delivered system, indefinitely. At $900 an hour, that is $82,800 a year of foregone throughput for every thing you have ever finished. Over a typical eight-year service life, one delivery consumes about $662,400 of the organization's future capacity to deliver.

Read that figure next to a business case. A project forecasting $400,000 of benefit, approved on the strength of it, can carry two-thirds of $1 million of unbooked constraint cost. The business case was not wrong about the benefit. It simply stopped counting on the day the project closed, which is the day the cost started.

5 years of doing everything right

Watch what happens to a portfolio that delivers competently and retires nothing, which describes almost every organization I have seen.

• Year one. A clean start. All 11,592 hours are available to build, and the team delivers about 14.5 systems.
• Year two. Those 14 deliveries now draw 1,333 hours. Available build capacity falls to 10,259 hours, and delivery falls to 12.8.
• Year three. The tail is 2,513 hours, over a fifth of the constraint. Delivery: 11.3.
• Year four. The tail is 3,557 hours. Delivery: 10.0.
• Year five. The tail is 4,481 hours, 39% of the entire capacity of the organization to deliver change. Delivery: 8.9.

Delivery has fallen by 39% in 5 years, and the annual value the portfolio produces has fallen from $10.4 million to about $6.4 million. Nobody made a decision that caused this. There was never a meeting at which somebody proposed moving 4,000 hours a year from building to running. The transfer happened one closed project at a time, in increments of 2 hours a week, each far too small to be worth anyone's attention.

And it does not stop. Left alone, with nothing retired and nothing moved off the constraint, the tail converges on the whole of the capacity. The end state of a portfolio that only ever adds is an organization that is fully occupied and delivers nothing, staffed entirely by people maintaining the things it built when it used to be able to build things. Most organizations do not get there, but only because delivery slows enough on the way that the tail stops growing. That is not a solution. That is the equilibrium.

The delivery equation

The equilibrium is worth writing down, because it turns out to be the most useful planning number in this whole article, and almost nobody calculates it.

If your constrained resource has C hours a year, a delivery costs B constraint-hours to build, each live system draws r constraint-hours a year to run, and things stay alive for an average of L years, then the number of deliveries a year you can sustain indefinitely is:

n = C / (B + rL)

The denominator is the honest cost of a delivery. Not the build cost, which is what your plan uses, but the build cost plus the whole tail across the asset's life.

Put the worked example through it. C is 11,592, B is 800, r is 92. If the average system lives 8 years, the sustainable delivery rate is 7.5 a year. The planner's figure, derived from build cost alone, was 14.5. The build-only view overstates the sustainable capacity of the organization by 93%, which is a reasonable first explanation for why your portfolio has been over-committed every year since anyone can remember. It is not that sponsors are greedy or planners are optimistic. The formula in use is missing a term.

Now use the equation as a lever, which is the point of having it.

• Shorten asset life. At L of 15 years, sustainable delivery is 5.3 a year. At 8 years it is 7.5. At 4 years it is 9.9. Halving the average life of what you own, by retiring things deliberately, raises the delivery rate by roughly a third without hiring anybody.
• Move the tail off the constraint. If tiered support, runbooks and a genuine operations capability cut r from 92 hours to 30, sustainable delivery rises to 11.1 a year, a 48% increase in throughput, again with no new people on the constrained team.
• Build more cheaply. Cutting B by a fifth, from 800 hours to 640, moves the rate from 7.5 to 8.3, an 11% gain. This is where almost all improvement effort goes, and it is the weakest of the three levers by a wide margin.

That last comparison is the finding that matters. In a portfolio with a mature estate, the tail term is larger than the build term, so the returns available from retirement and from support design exceed anything available from making your engineers faster at building. Your improvement budget is almost certainly pointed at the smallest of the three numbers.

Why the tail is invisible

Four mechanisms keep this hidden, and each suggests a different correction.

It is priced at the wrong moment. A business case is written before the build and closed at handover. The run tail begins at handover and is paid for the following decade, by a budget holder who was not in the room, from a capacity pool that belongs to nobody in particular. Every organization has a rule that benefits must be tracked after closure. Almost none has a rule that costs must be.

It arrives in interruption-shaped units. 2 hours a week is not a task; it is 15 scattered intrusions. The hours are bad enough, but the damage is worse than the hours, because an interrupted specialist pays a switching cost each time and loses the deep blocks in which the hard build work actually gets done. This is the cost of multitasking arriving through a channel nobody tracks, so the real figure is meaningfully worse than the 92 hours the arithmetic uses.

It is below every threshold you have. No single instance of the tail is large enough to govern. 40 minutes of an engineer's Tuesday does not qualify for a change request, a business case, or a line on any report. It is the same structural blindness that creates the sub-threshold portfolio, with one aggravating difference: sub-threshold change work is at least discretionary, and somebody asked for it. The run tail is non-discretionary and nobody asked for it at all. It is simply the bill for things you already own.

Nobody can book the saving from removing it. Decommissioning a system returns capacity to the constraint, which is worth real money, but the return is spread across every future project rather than attributable to any one of them. So the decommissioning proposal has a hard cost and an unbookable benefit, which is the exact profile of a proposal that never gets funded. This is the asymmetric ledger operating on your estate: the organization can measure what retirement costs and cannot measure what it returns, so it does not happen.

Why single-project management is blind to this

Ask which project should have paid for the tail, and the question answers itself.

A business case nets one project's costs against one project's benefits, across one project's life, and the life of a project ends at handover. Under that frame the run tail is not a cost of the project. It is a cost of the organization, appearing after the project no longer exists, and there is no mechanism by which a closed thing can be charged for something that happens afterwards. So the cost lands on shared capacity, and shared capacity has no advocate at the moment of approval.

Worse, the frame actively rewards creating tails. A project team is measured on delivering its scope inside its budget. Designing for low ongoing support, building the runbooks, automating the certificate rotation, making the thing legible enough that somebody other than its authors can fix it, all of that costs build hours and delivers no project benefit. It improves the throughput of the organization for a decade and makes the project look worse. A rational project manager declines to do it, and is right to, given the instrument they are judged by.

This is the Project Illusion in its most expensive form. The illusion is that a portfolio is a set of independent projects whose costs and benefits can be summed. What the run tail shows is that projects are not even bounded in time, let alone independent. Each one leaves a permanent lien on the capacity of every project that comes after it, and the organization delivering 14 things a year is, whether it knows it or not, selling off its own future delivery rate to do so.

A note on batch size, because this looks like a contradiction

Flow Economics argues consistently that smaller projects capture more value. Somebody reading this article will conclude the opposite: if each delivery costs 92 hours a year forever, surely fewer and bigger is better.

It is worth being precise, because the two ideas are compatible and the distinction is the whole practical point. The run tail attaches to the deployed thing, not to the project. Slicing the delivery of one system into six increments adds nothing to the tail, because there is still one system to look after; it simply starts the value earlier, which is what the batch size argument is about. Delivering six separate systems adds six tails.

So the rule is not "deliver less often". It is: small batches, small estate. Ship in thin slices, and be ruthless about how many distinct things you end up owning. The failure mode this article describes is not organizations that release frequently. It is organizations that have accumulated 60 named systems, roughly 9 of which anyone could justify today.

What to do instead

1. Measure r before you argue about anything else. For 4 weeks, have the constrained team tag every interruption with the system that caused it. Not a timesheet, a tally. 4 weeks is enough to get an hours-per-week figure per live system, and the figure is almost always 2 to 4 times what leadership assumes. This is the single number that makes every other conversation in this article possible, and you can have it by the end of next month. Expect the distribution to be skewed: typically a handful of systems generate most of the tail, which is useful, because it tells you exactly where to start.

2. Price the tail into the business case and make it the sponsor's problem. Every proposal to build something should carry one extra line: expected run draw on the constrained resource, in hours a year, multiplied by expected service life, priced at your value per constrained resource hour. In the worked example that line reads "92 hours a year for 8 years, 736 constraint-hours, $662,400". Some proposals will not survive it. That is the correct outcome, and it is far cheaper to discover at the gate than 5 years into an estate you cannot afford.

3. Fund retirement as a capacity investment, with an explicit return. Decommissioning is not housekeeping and should stop being discussed as though it were. Removing a system that draws 92 hours a year returns 92 constraint-hours a year to your delivery capacity, worth $82,800 annually. A decommissioning exercise costing 200 constraint-hours pays back in under 3 years and then pays forever. Run the numbers per system, rank them by hours returned per hour spent, and work down the list. The systems at the top of that list are usually not the ones anybody would have guessed.

4. Set an estate cap and force a trade. The most effective single intervention is also the bluntest: fix the number of systems the constrained team supports, and make adding one require retiring one. This does for your estate what a work-in-progress limit does for your pipeline, and it works for the same reason. It converts an invisible, cumulative, unowned cost into a visible decision taken by a named person at a specific moment. Sponsors who would never argue against a saving will argue hard about which system dies, and that argument is exactly the one the organization needs to be having.

5. Make a low tail a delivery requirement, not a virtue. If a project can only pass its gate by demonstrating the ongoing draw it creates, the design changes. Runbooks that someone outside the build team can follow, automated certificate and credential rotation, observability that answers the common questions without a human, and a genuine second line that resolves at least the routine 80%. Budget those hours explicitly in B rather than hoping for them. Spending 60 extra build hours to remove 40 run hours a year is an outstanding trade, and no project will ever make it voluntarily.

6. Report the split, every quarter, to the board. One chart: constraint-hours consumed by building versus constraint-hours consumed by running, quarter on quarter, with the estate count alongside. It takes one slide, and it is the only view that makes this problem visible while it is still cheap. A portfolio board that has watched the run share climb from 12% to 30% over 3 years will fund retirement without being persuaded. A board that has never seen the number will keep asking why delivery is slowing and keep being told it is a culture problem.

The objection you are already forming

"This is not our situation. We have an operations function. Our engineers hand over at go-live and move on to the next thing. Support is somebody else's budget."

I would like that to be true, and occasionally it is. Mostly what a handover does is separate the routine 80% from the residual 20%, which is a genuine and valuable achievement. But notice what the residual consists of. It is everything the operations team cannot resolve: the novel failure, the undocumented interaction, the thing that has only been live for 6 months, the problem whose answer exists in exactly one person's head. Those escalations are, by construction, generated most heavily by your newest deliveries, which is to say by the very systems your constrained team needs to be moving on from.

There is also a measurement trap here worth naming. The tail does not appear on the constrained team's timesheets, because interruptions get booked to whichever project the engineer is nominally assigned to that week. So the hours show as project work, the project runs late, and the delay gets explained locally. The absence of the tail from your records is not evidence that it is absent from your week. It is evidence that your records have nowhere to put it, which is the whole thesis of this article.

So do not accept the objection and do not dismiss it. Test it, using the four-week tally in step one. If your r really is close to zero, you have solved a problem most organizations have not, and you should be able to show it in an afternoon and take the win. If it comes back at 2 or 3 hours a week per system, then you now know what your operations function is actually absorbing and what it is passing back.

The deeper point is that a portfolio's delivery capacity is not a property of its headcount. It is a property of its headcount minus everything that headcount is already committed to, and an organization that has been delivering successfully for a decade has committed a great deal without ever writing it down. Nothing in the five-year decline above required a single bad decision. It required only a measurement system that prices the building of things and not the owning of them, applied consistently, by competent people, for long enough.

The organizations that escape this are not the ones that build faster. They are the ones that decided, at some point, that what they own is a portfolio decision too.

If you have not yet established which resource sets your delivery speed, start with How to Find the One Resource That Sets Your Delivery Speed, because the equation in this article needs it. For the number that prices a constraint hour, see Value per Constrained Resource Hour. And for the other half of the invisible load on your specialists, the small change requests that governance was designed not to look at, read The Sub-Threshold Portfolio.