Skip to content

Support Burn-Rate Review

Recurring review — instantiates Sustainment-Reach Alignment

A recurring review of how fast sustainment capacity is being consumed relative to reach, projecting when the front will outrun its support.

A line can look healthy today and still be doomed — if it is consuming its reserves, its spare crews, its goodwill faster than reach is paying them back, the collapse is already scheduled, just not yet visible. Support Burn-Rate Review is the recurring review that watches the rate, not the level: each cycle it takes the cost of holding current reach, compares it against the capacity remaining, and projects the runway — how long until the support system is exhausted at the present burn. Its defining move is turning a snapshot into a trajectory with a date: where the dashboard says "here is the ratio now," the review says "at this burn we hit the wall in about six weeks, and here is what is driving it." It projects; it does not read the live gauge or enforce the stop.

Example

A software company is signing enterprise customers fast — the "front" is racing ahead. Each new customer adds integration work, on-call load, and account management that the same support org must absorb. The Support Burn-Rate Review meets monthly. It does not ask "are we coping now?" (they are); it asks "how fast is support capacity burning against growth?"

The reach-cost model shows each cohort of ≈20 new customers adding roughly one support engineer's worth of steady load, while hiring adds only about half that per month. Extrapolated, the review projects support saturation in ≈4 months — the point where on-call breaks and quality craters — even though today's dashboards are green. Surfaced early, that date reframes the conversation from "grow as fast as we can close" to "grow only as fast as support can be sustained," and lets the company slow intake or fund support ahead of the wall instead of discovering it on a bad weekend.

How it works

  • Track the rate, not the level. Measure how fast reserves, crews, and capacity are drawn down per cycle, and treat that slope as the headline.
  • Cost the current reach. Use a reach-cost model to price what merely holding today's front consumes each period — not what expanding would cost.
  • Project the runway. Extrapolate burn against remaining capacity to a date: "sustainment exhausted in ~N weeks at this rate."
  • Recur on a cadence. Run the same review each cycle so the runway is re-projected as reach and burn change, catching acceleration early.

Its distinguishing feature is a rate-and-runway projection on a fixed cadence — a forward date, versus the dashboard's instantaneous level.

Tuning parameters

  • Cadence — weekly vs. monthly vs. quarterly. Faster catches acceleration sooner but costs attention and can chase noise.
  • Burn definition — which reserves count (stock, crew-hours, budget, goodwill). Narrow burn is measurable but misses soft exhaustion; broad burn is truer but fuzzier.
  • Projection method and horizon — straight-line vs. accelerating extrapolation, and how far out to trust it. Linear is simple but underplays compounding strain.
  • Trigger thresholds — what runway length escalates (e.g., under ≈8 weeks → act). Set long to act early, short to avoid false alarms.
  • Scope reviewed — the whole line vs. the worst segment. Reviewing the worst segment catches the binding constraint the average hides.

When it helps, and when it misleads

Its strength is catching the slow-motion failures a level-based view misses — the front that is fine today and gone in a month — and giving a date that decisions and staging can attach to. Its lineage is the military notion of the line of communication: the longer and busier the supply route, the more of the force is consumed simply keeping it open.[1]

A runway projection is only as good as its burn estimate, and the softest burns — morale, attention, partner goodwill — are the hardest to rate and the first to be left out, so a review can read "18 weeks" while the real constraint is a team about to quit. The classic misuse is to re-forecast until the runway is comfortable: stretching the horizon or trimming the burn definition to push the wall past the next milestone. The discipline is to hold the burn definition steady across reviews, carry the un-priceable reserves as explicit risks even when unquantified, and treat a shortening runway as the signal it is rather than a forecasting error.

How it implements the components

Support Burn-Rate Review realizes the forward-projection side of the archetype — the components a recurring review can fill:

  • reach_cost_model — its analytical core: what holding the current front costs per period, and how that cost scales with reach.
  • reach_review_cadence — the recurring rhythm itself: the standing cadence at which reach-versus-sustainment is re-projected.

It does not read the live delivered ratio (net_delivery_metric, line_health_monitor) — that is Net Supply Ratio Dashboard; nor enforce a stop when the runway runs out (front_pace_gate, crossover_threshold) — that is Reach Limit Gate. It supplies the date those act on.

Notes

The review projects but does not act — a shortening runway with no coupled gate or rescope is just a well-documented march to the wall; wire its output to the Reach Limit Gate or Front Rescope Playbook. It also differs from Lead-Time Stress Simulation: this review extrapolates the actual current burn, whereas the simulation explores hypothetical shocks that have not happened.

References

[1] Line of communication — in military logistics, the route connecting a force to its base of supply. A foundational principle is that lengthening it raises the fraction of the force consumed defending and running it — precisely the burn a support review tracks. ↩