REDUNDANCY: GOOD OR BAD?
…and its effects on (anti)fragility.
(thread)
1/ Due to ergodicity (the need to avoid gameover, explained 👇), redundancy is a necessity.
And necessities shouldn't be judged on "efficiency".
…and its effects on (anti)fragility.
(thread)
1/ Due to ergodicity (the need to avoid gameover, explained 👇), redundancy is a necessity.
And necessities shouldn't be judged on "efficiency".
2/ Just like you don't say "it was inefficient to spend my money on that fire extinguisher, I never got to use it".
3/ Lack of redundancy is a cost by itself. The more you have redundancy, the more you can take risks with high payoffs without risking gameover.
3/ Lack of redundancy is a cost by itself. The more you have redundancy, the more you can take risks with high payoffs without risking gameover.
4/ Antifragility necessitates redundancy.
The more you have redundancy, the more a stressor hitting you is likely to cause non-fatal damage, moving the green area to the right (in the chart below).
Making you more likely to exhibit an antifragile response in the future.
The more you have redundancy, the more a stressor hitting you is likely to cause non-fatal damage, moving the green area to the right (in the chart below).
Making you more likely to exhibit an antifragile response in the future.
5/ However, too much redundancy is bad: the more you have redundancy, the larger the yellow area, the less likely is a weak stressor to cause you (small) harm.
If no harm for too long, you weaken.
Too much redundancy → too little harm → fragilization.
If no harm for too long, you weaken.
Too much redundancy → too little harm → fragilization.
6/ The seemingly contradictory two tweets above are resolved as follows:
Have a lot of redundancy but only use it to absorb large stressors (where you'd risk gameover). Keep yourself exposed to small stressors (which surface problems & make you improve).
A practical example👇
Have a lot of redundancy but only use it to absorb large stressors (where you'd risk gameover). Keep yourself exposed to small stressors (which surface problems & make you improve).
A practical example👇
7/ In a manufacturing plant, if you have a warehouse full of components, you can prevent small stressors (such as a supplier's truck arriving one day late) from hurting you (having to stop production due to a lack of components).
However…
However…
8/ However, if you always use your warehouse (the source of redundancy) to absorb the shock from small stressors preventing your company from getting harmed, you will never work on solving problems.
Trucks will keep arriving inconsistently
Until one day they are one week late…
Trucks will keep arriving inconsistently
Until one day they are one week late…
9/ …forcing you to stop production for a few days and incurring chaos and angered customers.
Protecting yourself from smaller stressors makes you unpreparated to larger ones.
Protecting yourself from smaller stressors makes you unpreparated to larger ones.
10/ Instead, great companies *selectively* remove buffers (redundancies) in order to surface problems to solve them before they are too big.
11/ Problems grow the size they need for you to acknowledge them.
You want to use redundancy to protect yourself from the consequences of your biggest problems, not for hiding them (causing them to grow even further).
Redundancy works when not used unless absolutely necessary.
You want to use redundancy to protect yourself from the consequences of your biggest problems, not for hiding them (causing them to grow even further).
Redundancy works when not used unless absolutely necessary.
12/ Redundancy is *efficient*, not inefficient.
As t → 0,
marginal redundancy → marginal inefficiency.
As t → ∞,
marginal redundancy → marginal efficiency.
As t → 0,
marginal redundancy → marginal inefficiency.
As t → ∞,
marginal redundancy → marginal efficiency.
13/ A few caveats:
- Some activities have t as a bounded interval. Depending on the boundaries, redundancy can be efficient or inefficient.
- Some activities have bounded consequences. If "gameover" is impossible, then redundancy can be both efficient or not (depends).
- …
- Some activities have t as a bounded interval. Depending on the boundaries, redundancy can be efficient or inefficient.
- Some activities have bounded consequences. If "gameover" is impossible, then redundancy can be both efficient or not (depends).
- …
14/ (continues from above)
- Some activities require multiple redundancies. If the resources to "buy" those redundancies are limited, then having "too much" of one redundancy is inefficient in the measure it limits the available amount to acquire other necessary redundancies.
- Some activities require multiple redundancies. If the resources to "buy" those redundancies are limited, then having "too much" of one redundancy is inefficient in the measure it limits the available amount to acquire other necessary redundancies.
15/ But, in general:
In unbounded environments, redundancy is good, and is even better if you have it but don't use it unless necessary for survival.
In unbounded environments, redundancy is good, and is even better if you have it but don't use it unless necessary for survival.
16/16 I wrote more about redundancy, ergodicity, antifragility & adaptation in my 2018 book "The Power of Adaptation" gum.co/powerofa
17/ Optimal optimization requires redundancy (due to inevitable variances in the environment and nonlinearities in the fitness function).
Optimization without adequate redundancy is overoptimization (maladaptation): adaptation to temporary lack of volatility.
Optimization without adequate redundancy is overoptimization (maladaptation): adaptation to temporary lack of volatility.
18/ True and wise "predictions" of future environment advice for an increase in redundancy (as they are not fooled by a temporary absence of volatility).
Intelligent-yet-idiotic predictions instead advice for a reduction in redundancy.
Intelligent-yet-idiotic predictions instead advice for a reduction in redundancy.
19/ (Predictions that advise for a reduction in redundancy are only good in bounded fields).
20/ More on how antifragile entities manage redundancy:
