Measure feedback delay in actual time units before…
Before attempting to improve any feedback loop, measure the current delay between action and signal in concrete time units (seconds, minutes, hours, days) rather than accepting vague assessments, because unmeasured delays appear shorter than they actually are through habituation.
When This Fires
- Before attempting to improve any feedback loop — measure current delay first
- When a feedback loop "feels like it's working" but improvement has stalled — check for hidden delay
- When comparing feedback loops across different activities to identify which ones need shortening
- During systems audits when mapping the delay structure of your workflows
Common Failure Mode
Attempting to improve feedback quality without measuring delay: "Let's make code review comments more specific." This improves signal quality but ignores that the signal arrives 2 weeks after the code was written — by which time the developer has moved on and can barely remember the reasoning. Reducing the delay from 2 weeks to 2 days would produce more improvement than any quality enhancement applied at the 2-week delay.
The Protocol
(1) For each feedback loop you want to improve, measure the current delay: timestamp when the action occurs, timestamp when the feedback signal arrives. Calculate the gap in concrete units. (2) Compare against what's achievable: could this delay be shortened? What's the theoretical minimum? What's the practical minimum given current constraints? (3) Prioritize delay reduction over signal quality improvement. A rough signal at 1-hour delay outperforms a precise signal at 1-week delay for most learning purposes. (4) After measuring, set a specific delay reduction target: "Reduce code review turnaround from 14 days to 3 days." (5) Re-measure after intervention to verify the delay actually shortened — intended improvements don't always produce actual improvements.