Measure feedback delay in actual time units before improving — unmeasured delays appear shorter than they are through habituation

Why This Is a Rule

Feedback delay — the time between performing an action and receiving a signal about its quality — is the single most important parameter in any feedback loop. Short delays (seconds to minutes) enable rapid learning: you adjust on the next iteration. Long delays (days to months) cripple learning: by the time feedback arrives, the context has changed, the memory has degraded, and the causal connection between action and outcome is obscured.

Habituation causes people to systematically underestimate their actual feedback delays. When you've been living with a 2-week delay for months, it feels normal — "feedback is reasonably fast." Measuring it concretely — "14 days between writing code and receiving review comments" — makes the delay visible and often shockingly long. You don't improve what you don't measure, and you don't measure what you've habituated to.

The measurement must be in concrete time units, not subjective assessments. "Feedback is pretty quick" might mean 2 hours or 2 weeks depending on your reference frame. "48 hours" is unambiguous and comparable to an improvement target.

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.