How would you measure ROI on QA's investment in CI/CD infrastructure?

Three measurement axes:

Axis 1 — bug escape rate.

• Track: bugs found in production vs. bugs found in CI/staging, per quarter.
• A reduction in escape rate is real money: prevented incidents (eng time + customer credits + brand), reduced support load, lower churn from "this product is buggy" perception.
• Baseline before-and-after a CI investment; the delta is your number.

Axis 2 — developer cycle time.

• Metric: PR-pipeline p95 duration. Goal: < 10 min.
• Why it matters: every minute over 10 = lost dev focus. A team of 50 engineers losing 20 min/day on pipeline waits = 250 dev-hours/month = > 1 FTE.
• Frame as "we recovered 1 FTE of capacity by halving pipeline time."

Axis 3 — MTTR (mean time to recovery).

• When something does break, how fast does CI catch it and route it to a fix?
• Synthetic monitoring + smoke + good observability cut MTTR from hours to minutes. For high-revenue services, every minute of downtime has a number — multiply by the MTTR delta.

Total ROI framing:

Annual savings = (prevented incidents × cost per incident)
               + (dev hours saved × loaded cost per hour)
               + (MTTR reduction × downtime cost per hour)

Annual investment = infra + headcount + tooling + maintenance

ROI = savings / investment

Concrete example (mid-size SaaS, 50 eng):

• Pre-investment: 6 P1s/year @ £200k each = £1.2M; pipeline 25 min average; 12 hours/eng/month on CI debugging.
• Post-investment (1 SRE + tooling at £250k/year): 2 P1s/year (saved £800k); pipeline 8 min (saved 50 eng × 2 hr/week × 52 = 5,200 dev-hours @ £75 = £390k); MTTR cut 2 hours per incident.
• Net: £1M+ savings vs. £250k spend. > 4x ROI.

Counter-arguments to anticipate:

• "We have no incidents to compare against" — count near-misses, time spent firefighting, P2/P3 bugs that should've been caught earlier.
• "Infra costs are concrete; savings are speculative" — every metric here can be tracked over a real before/after window. The hard data exists.
• "This is just a tax on shipping" — invert the question: what's the cost of shipping bugs faster? Most CTOs price this honestly when shown a P1 retro alongside the CI bill.

Senior leadership signal: framing in money and time saved, with a concrete control test ("what if we cut CI investment in half?"), and citing the dev-cycle-time multiplier. Pipelines aren't infrastructure cost — they're capacity multipliers.