Blaming individuals stops improvement

What it is

The blame attribution trap here is not about why "human error" fails as a conclusion on cognitive grounds — that argument is already made elsewhere. It is about the concrete consequence inside an industrial safety management system: once an investigation's finding stops at an individual, the machinery that is supposed to turn a finding into an actual change is never triggered, and the latent condition that produced the event stays exactly where it was until the next event exposes it again.

Why it happens

A safety management system's standard path for handling an investigation finding is to turn it into one or more corrective actions, logged in a corrective action tracking system with an owner, a due date, and closure criteria. That tracking system only does real work when the action points at a specific system condition — revising a procedure, adding an interlock, changing how a metric is calculated. If a finding reads "operator carelessness" or "procedure not followed," the corrective action it generates is usually retraining that operator, or a plant-wide refresher. That kind of action closes cleanly in the tracking system and produces a record that "the issue has been handled," but it generates no change request against equipment, procedure, interface, or metric design. No change request means the modification never enters the formal workflow that requires engineering evaluation and budget approval, so it is never allocated engineering resources or funding. The system condition that actually enabled the event — an interface prone to a specific slip, a margin compressed to a critical level — is therefore never touched. It stays in the system in exactly the same form, waiting for the next similar operating sequence to expose it again, and that next exposure often lands on a different operator, because the condition itself has nothing to do with who happens to be at the controls.

Studying it

Checking whether an SMS has fallen into this trap means auditing the structure of the corrective action tracking system's own records, not re-litigating whether any single finding was correct: count, over some period, how many corrective actions consist of training, warnings, or discipline versus how many contain a specific change against equipment, procedure, interface, or metric; then check whether the same category of event recurs across different personnel and crews. Recurrence paired with individual-directed corrective actions each time is direct evidence that the system condition was never actually touched. This kind of audit depends on the tracking system's own record quality — if there is no mandatory field classifying action type, the analysis has to fall back on reading free-text action descriptions, and its reliability is bounded by how detailed those descriptions are.

Where it stops holding

This analysis of corrective-action tracking cannot be used to excuse deliberate violation or willful misconduct — that kind of behavior still needs to go through a disciplinary process, and that process should be kept as a separate record trail from the safety-learning process, so the evidence chain for discipline does not get tangled with the evidence chain for system improvement. It is also not enough for the tracking system to show that a system-directed change request was generated — the request can still be rejected or shelved indefinitely during engineering review for cost or feasibility reasons, in which case the process looks correct on paper while the latent condition remains genuinely unfixed. The downstream status of the change request has to keep being tracked; generating the request is not itself the endpoint.

Applying it

• Add a mandatory classification field to every entry in the corrective action tracking system (individual-directed vs. system-directed), and disallow "retraining" or "verbal reminder" as the sole content of an action without also stating whether a system-level change is needed.
• For events involving personal safety, require the finding to answer, before it can be closed, "would an equally qualified operator under the same conditions have done the same thing." If yes, the corrective-action field must include at least one system-directed change request, or the investigation cannot close.
• Track the downstream status of system-directed change requests through engineering review rather than stopping at "submitted," so a shelved request does not quietly disappear from view.
• How to check: pull one to two years of corrective-action records, classify them as individual-directed or system-directed, and cross-check against the recurrence rate of similar events. If individual-directed actions dominate and the same category of event keeps recurring across different personnel, the conversion from finding to corrective action is not actually functioning, and the closure criteria for investigations need revision.

Related

• Same group: Y7.01.1 Accidents usually result from simultaneous failure of multiple defences · Y7.01.2 Organizational decisions create latent conditions
• Nearby: A10.09 Human reliability and blame culture · Y7.02 Error reporting
• Search terms: corrective action tracking · blame culture · organizational accident