When to Pay for Speed

Written by Adrian Maharaj

(Views mine, not Google’s.)

Step 1 Put a price on waiting
Cost of Delay (COD) reframes “go faster” into economics: $/week of value lost. Consider: revenue timing, risk reduction, and option value (what earlier shipping unlocks). Short primer: https://www.productplan.com/glossary/cost of delay/

Step 2 Price acceleration paths

  • People: senior contractors, internal tiger team, proven vendor.

  • Platform: managed services vs primitives; feature flags to decouple deploy from launch.

  • Scope: ship the “thin slice” that earns learning per day, not per quarter.

Step 3 — Decide with math
If one week of delay threatens $250k and the tiger team + platforms run $120k/week, you fund it. If not, you fix flow (queues, batch size) rather than add spend. Little’s Law reminder (WIP ↓ → cycle time ↓): https://www.columbia.edu/~ww2040/4615S15/LittlesLawNotes012715.pdf

Guardrails
Use DORA metrics so “speed” doesn’t become instability: lead time, deployment frequency, MTTR, change fail rate. https://dora.dev/research/2023/

Example
NRR wobbling from reliability incidents? If weekly churn risk ≈ $400k, fund a 4‑week reliability sprint (SLOs, error budgets, incident practice, smaller batches) and review weekly against CoD. Stop if the curve doesn’t bend.

Further reading
Cost of Delay: https://www.productplan.com/glossary/cost of delay/
DORA 2023: https://dora.dev/research/2023/
Little’s Law: https://www.columbia.edu/~ww2040/4615S15/LittlesLawNotes012715.pdf

Previous
Previous

Decision hygiene for CeOs

Next
Next

From Command to Context Why Tomorrow’s Leaders Must Become Systems Architects