82,891
edits
Normal Accidents: Living with High-Risk Technologies: Difference between revisions
Normal Accidents: Living with High-Risk Technologies (view source)
Revision as of 19:32, 31 August 2020
, 31 August 2020no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 29: | Line 29: | ||
Furthermore, in our efforts to pre-solve for catastophe, we tend ''not'' to simplify: to the contrary, we add prepackaged “risk mitigation” components: [[Policy|policies]], [[taxonomy|taxonomies]], [[key performance indicator]]s, [[tick-boxes]], processes, rules, and [[Chatbot|new-fangled bits of kit]] to the process in the name of risk management. To be sure, these give our [[middle management]] layer comfort; they can set their [[RAG status]]es green, and it may justify their planned evisceration of that cohort of troublesome [[subject matter expert]]s who tend to foul up the mechanics of the [[Heath Robinson machine]] — but who will turn out to be just the people you wish you hadn’t fired when the shit hits the fan. | Furthermore, in our efforts to pre-solve for catastophe, we tend ''not'' to simplify: to the contrary, we add prepackaged “risk mitigation” components: [[Policy|policies]], [[taxonomy|taxonomies]], [[key performance indicator]]s, [[tick-boxes]], processes, rules, and [[Chatbot|new-fangled bits of kit]] to the process in the name of risk management. To be sure, these give our [[middle management]] layer comfort; they can set their [[RAG status]]es green, and it may justify their planned evisceration of that cohort of troublesome [[subject matter expert]]s who tend to foul up the mechanics of the [[Heath Robinson machine]] — but who will turn out to be just the people you wish you hadn’t fired when the shit hits the fan. | ||
Here is the folly of elaborate, [[complicated]] safety mechanisms: adding components to any complex system ''increases'' its complexity. That, in itself, makes dealing with [[system accident]]s, when they occur, ''harder''. The safety mechanisms beloved of the [[middle management]] layer derive from experience. They secure stables from which horses have bolted. They are, as Jason Fried elegantly put it, “organisational scar tissue. Codified responses to situations that are unlikely to happen again.”<ref>{{br|Rework}}, {{author|Jason Fried}}</ref> | Here is the folly of elaborate, [[complicated]] safety mechanisms: adding components to any complex system ''increases'' its complexity. That, in itself, makes dealing with [[system accident]]s, when they occur, ''harder''. The safety mechanisms beloved of the [[middle management]] layer derive from experience. They secure stables from which horses have bolted. They are, as {{author|Jason Fried}} elegantly put it, “organisational scar tissue. Codified responses to situations that are unlikely to happen again.”<ref>{{br|Rework}}, {{author|Jason Fried}}</ref> | ||
They are, in a word, ''linear'' responses to what | They are, in a word, ''linear'' responses to what will be, when it happens, by definition a ''non-linear'' problem. | ||
Not only do linear safety mechanisms exacerbate or even create their own accidents, but they also afford a degree of false comfort that encourages managers, who typically have financial targets to meet, not safety ones — to run the system harder, thus increasing the tightness of the coupling between unrelated components. That same Triple A rating that lets your risk officer catch some zeds at the switch encourages your trader to double down. ''I’m covered. What could go wrong?'' | Not only do linear safety mechanisms exacerbate or even create their own accidents, but they also afford a degree of false comfort that encourages managers, who typically have financial targets to meet, not safety ones — to run the system harder, thus increasing the tightness of the coupling between unrelated components. That same Triple A rating that lets your risk officer catch some zeds at the switch encourages your trader to double down. ''I’m covered. What could go wrong?'' | ||