The check can disappear on a rushed day
This is one result from the free test Is Evidence Keeping Up With Your Output? Your check is good. It looks at the right thing, it comes from a source that can disagree, and it returns in time. It also depends on a person choosing to start it, which means the days it is most needed are the days it is least likely to run.
Your protection is only as strong as your worst week
Ask what your checking looks like on an ordinary Tuesday and the answer is usually reassuring. Ask what it looks like on the Thursday before a launch, with two people out and a client waiting, and a different answer appears.
The second answer is the real one. Rare, hurried, unusual work is where mistakes concentrate, so an optional check is absent exactly when its expected value peaks. Averaging across normal weeks hides this completely.
Worse, the skip usually leaves no trace. Nobody records "we did not verify this one." The work arrives looking the same as work that was verified, and afterwards nobody can tell which pieces were which.
The incentives are pointing at the skip
This is not a discipline failure, and treating it as one is why the problem survives repeated commitments to do better.
The reward for skipping is immediate and personal
Skipping gives you the afternoon back today. Checking gives you an avoided problem you will never observe, because it does not happen. One of those is felt. The other is invisible by construction.
Finding a problem is punished locally
A defect you find before release becomes work you have to do, inside your current commitment. The same defect found later becomes a separate incident, often carried by someone else, on a separate budget. Nobody designs this arrangement, and almost every team has it.
The work looks finished, which reads as permission
When a tool produces polished output in one pass, it arrives wearing the appearance of completion. A separate decision to verify has to overcome that appearance, and the appearance is winning most of the time.
Three ordinary versions
A team has a written pre-send checklist for client reports. It is used for every report except the urgent ones, which are the ones written fastest and reviewed least.
An engineer runs the full test suite locally before pushing. Usually. The Friday hotfix skips it, because the point of a hotfix is speed, and the suite takes eleven minutes.
A writer verifies quotes and figures before publishing. The piece that goes out during a news cycle is the one where verification loses to timing, and it is also the one with the most readers.
Stop trying to remember. Change what triggers the check
The principle: a check that requires a separate decision will be lost under pressure, so attach it to a decision that already happens. Saving, committing, submitting, sending, publishing, and handing over are all steps that occur anyway. A check bound to one of those inherits its reliability.
There are three strengths of fix, and they escalate. Pick the weakest one that matches the consequence.
- Automatic start. Connect one important check to a step that already happens, so nobody has to remember it. This alone removes most rushed-day losses.
- Blocking on failure. For the check whose failure would change the decision, make sending unavailable while it is failing or unfinished. Use this sparingly. A gate on a low-stakes check trains people to route around gates.
- A recorded skip. Where blocking is wrong, require anyone skipping to write the reason, the risk accepted, and who reviews it later. This does not prevent the skip. It converts a silent gap into a visible decision you can count.
You know it is working when you can answer "was this piece checked" without asking anyone, and when the number of skips over the last month is a number you can produce.
What not to do
Do not add a policy. A policy is another thing to remember, and the failure mode you have is forgetting under pressure. Policies raise the guilt of skipping without lowering the rate.
Do not automate all of your checks at once either. Automating a weak check gives you a reliable source of no information. Pick the single check whose failure would have changed a decision in the last three months, and attach that one.
If your checks are not just skippable but also arrive after use, sequence matters: read Bad news arrives after people start using the work, because automating a check that reports too late makes lateness reliable rather than fixing it.