83,544
edits
Template:M intro design System redundancy: Difference between revisions
Jump to navigation
Jump to search
Template:M intro design System redundancy (view source)
Revision as of 15:11, 17 July 2023
, 17 July 2023no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
=== It’s the long run, stupid=== | === It’s the long run, stupid=== | ||
[[Taylorism]] and just-in-time efficiency | [[Taylorism]] and just-in-time efficiency | ||
A snapshot of the process, when it is at minimum stress, fair weather, all is operating well. But efficiency must be measured over an appropriate life cycle measured by the frequency of the worst possible negative event. The efficiency of a process must take in all | A snapshot of the process, when it is at minimum stress, fair weather, all is operating well. But efficiency must be measured over an appropriate life cycle measured by the frequency of the worst possible negative event. The efficiency of a process must take in ''all'' parts of the cycle — the whole gamut of the four seasons — not just that nice day in July when all seems fabulous with the world. There will be other days; difficult ones, on which where multiple unrelated components fail at the same moment, or where the market drops, clients blow up, or tastes gradually change. There will be almost imperceptible, secular changes in the market which will demand products be refreshed, replaced, updated, reconfigured; opportunities and challenges will arise which must be met: your window for measuring who and what is ''truly'' redundant in your organisation must be long enough to capture all of those slow-burning, infrequent things. | ||
The skills and operations you need for these phases are different, more expensive, but likely far more determinative of the success of your organization over the long run. | The skills and operations you need for these phases are different, more expensive, but likely far more determinative of the success of your organization over the long run. | ||
| Line 7: | Line 7: | ||
The [[Simpson’s paradox]] effect: over a short period the efficiency curve may seem to go one way; over a longer period it may run perpendicular. | The [[Simpson’s paradox]] effect: over a short period the efficiency curve may seem to go one way; over a longer period it may run perpendicular. | ||
The perils, therefore, of data: it is necessarily a snapshot, and we | The perils, therefore, of data: it is necessarily a snapshot, and in our impatient times we imagine time horizons that are far too short. A sensible time horizon should be determined not by reference to your expected regular income, but to your worst possible day. Take our old friend [[Archegos]]: it hardly matters that you can earn $20m from a client in a year, consistently, every year for twenty years ''if you stand to lose five billion dollars in the twenty-first''. | ||
Then, your time horizon for redundancy is not one year, or twenty years, but ''two-hundred and fifty years''. Quarter of a millennium: that is how long it would take to earn back $5 billion in twenty million dollar clips. | |||
In peace-time, things looked easy for [[Credit Suisse]], so they juniorised their risk teams. This, no doubt, marginally improved their net peacetime return on their relationship with [[Archegos]]. But those wage savings — even if $10m annually, were out of all proportion to the incremental risk that they assumed as a result. | |||
(We are, of course, assuming that better human risk management might have averted that loss. If it would not have, then the firm should not have been in business at all) | (We are, of course, assuming that better human risk management might have averted that loss. If it would not have, then the firm should not have been in business at all) | ||