How would you build the economic case for moving quality work earlier without leaning on a defect-cost multiplier?

## Why the multiplier is the wrong foundation The reflex when asking for quality investment is to reach for the industry curve. It is a bad foundation for a lead, because a borrowed number can be disputed by anyone with a search engine, and once it is disputed the whole request is discredited. Worse, a multiplier is an *average*, and nobody funds averages: they fund a specific piece of work, this quarter, against a specific alternative use of the same people. Build the case on evidence you own and reasoning the audience can follow. ## Step one: price your own escapes Take every defect that reached users in the last two quarters and price it fully in the four cost-of-quality categories, coarsely but honestly. For a warehouse stock ledger that might read: one stale-cache read escaping for nineteen days, costing 41 engineer-hours of diagnosis and fix, nineteen re-runs of a 6-hour nightly reconciliation, 2,847 hand-corrected ledger lines and 63 support-hours; three smaller escapes at 9, 14 and 22 engineer-hours; and eleven cosmetic ones at roughly an hour each. That distribution already tells the story better than any curve: the cost is concentrated in a small number of state-corrupting defects, and it is dominated by repair of data and by other people's time, not by engineering effort. ## Step two: make it a marginal question For each escape, ask what specific earlier intervention would plausibly have caught it, and what that intervention costs per cycle if adopted permanently. Now the ask is concrete: *this* check, at *this* recurring cost, against *these* four escapes it would have caught. That is a proposition a finance-minded stakeholder can evaluate, and it is honest about the fact that prevention and appraisal are themselves costs, not free virtue. Be rigorous about the counterfactual. "Would have caught it" is easy to assert after the fact; a stale-cache read under a specific interleaving is not caught by generic extra checking, and claiming otherwise is how quality proposals lose credibility on contact with the first sceptical engineer in the room. ## Step three: weight by irreversibility, not just by expectation Expected cost — likelihood times impact — is the right starting frame, but it under-serves the tail. Some failures are *irreversible*: money moved, data destroyed beyond reconstruction, a regulatory disclosure, a customer relationship ended. Reversible failures can be traded against delivery speed rationally; irreversible ones deserve spending out of proportion to their expected value, in the same way people insure against rare ruin rather than against likely inconvenience. Say that explicitly, because it is the part of the argument that survives when someone points out the expected-value maths looks marginal. ## Step four: argue in the decision-maker's units Engineers argue in defects. Nobody funds defects. Convert to what your audience already tracks: hours of manual reconciliation absorbed by another department, delivery dates missed because a release was spent on repair, exposure of money or compliance, and predictability. Where a cost is real but unmeasurable — the warehouse teams who have stopped believing the on-hand figures — name it as unmeasured rather than scoring it zero, because silent zeroes are the single largest bias against quality investment. ## Step five: be honest about where the argument stops A lead's credibility comes from stating the limits before anyone else does. **Diminishing returns are real.** Prevention and appraisal spending has a marginal-return curve. A check that has caught nothing in two quarters and costs review time every cycle is a live cost with no observed return, and should be argued for on residual-risk grounds or dropped. **Not everything can be shifted.** Some failure classes only appear against production-scale data, real concurrency and real user behaviour. For those the lever is not earlier detection but *fast* detection and cheap recovery: reducing the time a bad write survives, and making its effects reconstructible. In the ledger example, a reconciliation that ran on a shorter cycle would have cut nineteen re-runs to a handful, and that is a cheaper structural win than any additional pre-release checking. **Detection latency is the real variable.** "Earlier" is a proxy. What you actually control is how long a defect survives undetected and how much dependent work accumulates in that window. Framing the ask as reducing that window keeps the argument valid whether the intervention sits before the code is written or minutes after it ships. ## Step six: make the case falsifiable Commit up front to what should change and by when — for example, that state-corrupting escapes and the repair hours attached to them fall over the next two quarters — and state what result would make you withdraw the investment. A quality argument that no evidence could ever refute is indistinguishable from advocacy, and experienced stakeholders treat it accordingly. Offering the stopping condition yourself is what makes the rest of the case believable.