Skip to content

Bad news arrives after people start using the work

This is one result from the free test Is Evidence Keeping Up With Your Output? Your checking is not the problem. It works. It finds genuine mistakes, and it finds them from a source that can genuinely disagree. It reports after someone has already relied on the work, which converts a correction into an incident.

The same finding has two different values

A warning delivered while you still have the work open changes the work. The same warning delivered after release changes a schedule, a relationship, and someone else's afternoon. The content is identical. The cost is not.

Two things drive the difference. The first is context: your own memory of why you made a choice decays within hours, so a late finding forces you to reconstruct reasoning before you can act on it. The second is exposure: once the work is out, the fix has to travel to everyone who received it, and someone has already made a decision on the old version.

Industry estimates of this gap are wide and imprecise, but they all point the same way. Defects found in production are commonly reported to cost tens of times more than the same defects found during development. You do not need the exact multiple. You need to notice that your discovery point sits on the expensive side of it.

How work ends up here

Usually it is not a decision anyone made. It is what happens when the only reliable source of truth is real use.

The only honest oracle is downstream

For a lot of work, reality is the only thing that knows the answer: whether the customer understood the email, whether the query returns what the analyst meant, whether the feature makes sense to someone who did not build it. So the check waits for reality, and reality arrives after release.

The check exists but runs on a different clock

A weekly report, a monthly reconciliation, a quarterly audit, a batch job overnight. Each is genuinely capable of catching the error. Each runs on a cycle longer than the release cycle, so it is always reporting on work that has already left.

Nobody named a deadline

The check has no stated latest useful moment, so it finishes whenever it finishes. Without a deadline, "before someone uses it" is a hope rather than a constraint.

Two shapes of the same problem

A pricing change is validated by monitoring conversion. That validation is sound. It also means the first evidence of an error is a week of underpriced orders.

An AI-drafted onboarding sequence is proofread properly, but the check that matters is whether new users complete setup. That signal exists, and it arrives after four hundred people received the confusing version.

Both are cases where the evidence is good and its arrival time is wrong. Neither is fixed by checking harder.

Do not try to make the late check early

The instinct is to take the downstream signal and somehow run it sooner. Usually you cannot, because what makes it trustworthy is exactly that it comes from real use.

The move is different: put a smaller, earlier check in front of it, and make real use a deliberate first step rather than the full release. You are not replacing the late signal. You are ensuring it is no longer the first thing that could have told you.

Three changes that move the return

  1. Name the latest useful moment. For the one check that would change your decision, write down the time its result must arrive by, and place that time before anyone can receive the work. A result after that time stops the send instead of explaining a failure.
  2. Finish one check in the same working session. Pick the check that can complete before you close the task. Returning a failure while the work is still open costs you minutes. Returning it next Tuesday costs you a reconstruction.
  3. Make small real use the first release. If reality is your oracle, give it a smaller slice: one customer, one internal team, one limited setting, with a stop condition written before you start. You keep the trustworthy signal and cut the exposure by an order of magnitude.

You know it is working when a failed check reaches the person who can change the work while they still have it open, and when the number of people affected by a late discovery is a number you chose in advance.

What would be premature here

Do not build a gate that blocks release on a check that structurally cannot finish before release. That produces a gate everyone learns to override, and an overridden gate is worse than no gate because it looks like protection.

Do not add more checks either. Your existing checks are good. Adding a second late check adds cost without changing the arrival time.

If your checks also do not include situations nobody listed at the start, moving them earlier will surface less than you expect. And if the real risk is that a check gets skipped entirely when the week gets tight, read The check can disappear on a rushed day next, because a deadline on an optional check is still optional.