Video of Bezos talking about this: https://www.youtube.com/watch?v=rxsdOQa_QkM.
IMO it’s a useful decision making strategy at times, mostly to not overthink the easily reversible.
Only difference is time. Much like an eventually consistent transactions, recoverable decisions have propagation latency.
The breaking part here is that will you able to survive until the recovery is complete?
> Conventional leadership advice suggests looking at decisions as reversible or non-reversible. Many important, non-reversible, decisions are recoverable, though.
So imo it’s splitting hairs over the same outcome.
An example - say you introduce 5 day return to office. Half you staff leaves and you now go back to a flexible work from home model. You don’t “undo” the damage done, but you can recover. It was a costly 2-way door.
Great Clips or Weldon Barber, are you feeling lucky?
In the last 15–20 years, many people have been forced into an uncomfortable moment due to job loss (Great Recession, COVID, AI etc). They have learned to recover. Could this be why we see more entrepreneurs than ever before now?
Second point is: You don't need to reverse the decision you took, instead you may find a way to fix the impact but not the root-cause.
It's like when one fucks up the MySQL replication and the data consistency is corrupted. One can manually (and slowly) fix the inconsistency with downtime. Or, spin up a whole new cluster from an existing well-known node/state. Some entities may be missing, but you could gradually add them back later.
Not a reversible, but recoverable decision.
Amazon goes by with one-way vs two-way door decisions internally. Sometimes adding much bureaucracy to the equation. Just-do-it/Bias-for-action aspect usually don't go as far as the recovery period prolongs.
(Also works well with LLMs, for risk assessments)
That mindset has served me well both personally and professionally.
as a solo dev, i used to agonize over stack choices, architecture patterns, even naming conventions. then i realized that in a small codebase, almost everything is a two way door. you can rewrite a service in a weekend. you can swap a database before you have real users. the actual irrecoverable decisions for early stage stuff are almost always about time and opportunity cost, not technical choices.
the one that gets people is when a recoverable decision feels irrecoverable because of sunk cost. you spent three weeks building something, so changing direction feels like throwing away work. but the work is already spent regardless, the only real question is what's the best move from here.