General
Teaching Tools
Case Materials
The Search to Affix Blame
This pitfall can masquerade as the (sometimes reasonable) search for malign motivation mentioned above. It is also a version of simplification. If we can just find a culprit to blame we feel as though we have found a satisfying explanation. Preferably, there is only one culprit, but if there are several, they should be in a conspiracy together. But consider for a moment: it is completely feasible that LaRue and Saia in the Hughes case are acting independently, are both guilty of at least skirting the truth, but have not explicitly conspired together. If you are not convinced of this read the Saia gets a call scenario to see how Saia might put pressure on LaRue to skip required tests, but not explicitly encourage it.
This search for a psychologically satisfying explanation may be fine for coffeehouse conversation, but engineers responsible for the operation of the system should look beyond it for two reasons. First, if safety is a system property (as Safety Engineering and the ImpactCS model imply), then focussing on only one level of the system will mislead us about the complexity of the issues. Simply blaming Machado for the email harassment does not lead us to look for the more complex ways that the culture of information sharing made this harassment easier. Nor does it help us make a more secure system. Second, a focus on individual or corporate blame implies only one kind of solution: people should be more careful or they will be punished. We can blame Hughes for its mistakes in inspection. But this will lead us to overlook the production pressures produced by the system of military contracts. The better approach is to look at the system to determine what people should be careful about. What can be modified in the system to increase those values about which we care?