You would not be able to tell whether it worked
Add people to check things and then ask what would show you they were catching anything. Nothing would.
The third reason, and it is the one that survives any disagreement about the other two. Suppose you added the checkers and could afford them. What would tell you it had worked?
Work through what would move. Throughput would go down slightly, because more work is waiting on people. Time-to-ship would go up. Queue depth would go up. Every number on your panel would get worse, and the thing that got better — the remainder — is the quantity with no gauge on it.
| what you would see | what it means |
|---|---|
| throughput down | the intervention is being felt. Not that it is working |
| time to ship up | the same. This is the cost, not the benefit |
| reviewer load up | you spent the money |
| fewer of the failures from step six | the actual benefit, arriving quarters later, indistinguishable from luck, and impossible to attribute |
So the position you would be in is: a visible cost, an invisible benefit, and no way to tell whether you bought anything. That is a bad position to be in even when the intervention is correct, and it is why this remedy gets tried, quietly abandoned after two quarters, and remembered as not having worked.
There is a fourth reason, and this volume does not lean on it. There is research suggesting the checkers themselves degrade when most of what they see is correctvigilance and automation-complacency researchunverified. If that holds up it makes everything on this page worse — but it is a single unverified citation, and the three reasons above are arithmetic and mechanism you can check yourself. Treat it as a reason to take part four seriously rather than as evidence for anything here.