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 07:42, 17 July 2023
, 17 July 2023→It’s the long run, stupid
Amwelladmin (talk | contribs) Tags: Mobile edit Mobile web edit |
Amwelladmin (talk | contribs) Tags: Mobile edit Mobile web edit |
||
| 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 | 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 realistic parts of the cycle, including the difficult ones where components fail, revenue drops, clients blow up, and it must be long enough to capture slow secular changes in the market over which products must be refreshed, replaced, updated, reconfigured, challenges must be met and competitors are developing new and better products. | ||
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. | ||
The Simpsons paradox effect: over a short period the efficiency curve may seem to go one way; over a longer period it may run perpendicular. | The [[Simpsons 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 inevitably draw a “relevant time horizon” that is far too short. That time horizon is determined not by your regular income, but by your worst possible day. It does not matter that you can earn $20m a year every year for twenty years if you stand to lose $5bn in the 21st. Then, your time horizon is not one year, or twenty years, but ''two-hundred and fifty years ''. 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 risk that they assumed as a result. | The perils, therefore, of data: it is necessarily a snapshot, and we inevitably draw a “relevant time horizon” that is far too short. That time horizon is determined not by your regular income, but by your worst possible day. It does not matter that you can earn $20m a year every year for twenty years if you stand to lose $5bn in the 21st. Then, your time horizon is not one year, or twenty years, but ''two-hundred and fifty years ''. 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) | ||