Unit 06.03: Approval fatigue and how it arrives

Approval fatigue is not a failure of diligence. It is what happens to any control asked too often.

Eight weeks to zero

Requests, approvals, edit rate and time on screen, tracked over two months.

The example below shows the trajectory.

 week  requests  approved  edited  reading time
    1        40        39      3%  45s each
    4        40        40      1%  12s each
    8        40        40      0%  3s each

By week eight every request is approved, nothing is edited, and each takes
three seconds. The control is still in the diagram and has stopped existing.

Two defences. Keep the gate count low so each one carries weight, and track
edit rate and reading time as metrics -- both falling towards zero is the
signal that approvals have become reflexive.

By week eight every request is approved, nothing is edited, and each takes three seconds. The gate is still in the architecture diagram and has stopped existing as a control.

Both numbers falling towards zero is the signal, and both are cheap to collect - you are already recording the approval. Edit rate is the more sensitive of the two, because a reviewer who is genuinely reading will occasionally change something.

The mistake this prevents

The mistake is responding to this by adding training or reminders. The cause is the request rate, so the fix is fewer gates - combine adjacent ones, and remove any gate on an action that turns out to be reversible.

Takeaway

Track edit rate and time on screen. Both falling towards zero means approvals have become reflexive, and the fix is fewer gates rather than more diligence.

Mark complete