what? this article is making a different point if you read past the title.
> Conventional leadership advice suggests looking at decisions as reversible or non-reversible. Many important, non-reversible, decisions are recoverable, though.
I don’t think it’s different. Recoverable == Reversible to an extend. Unless you take reversible in the strictest sense of “undo” it’s different. But you can’t “undo” a leadership decision, all you can do is later correct it and recover.
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 concept. Culturally, I think we are better at understanding this than ever before.
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?
The main difference being the time it takes to recover/reverse the decision.
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.
I've often thought along similar lines. I've found that indecision is almost always worse than a bad one. Very few choices are so decisive that you can't course-correct later.
That mindset has served me well both personally and professionally.
agreed on indecision being worse than a bad decision, with one caveat: i think people systematically underestimate how many decisions are actually recoverable.
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.
It becomes more difficult if you lean into and build upon the specific things that your stack choices give you. If you use everything very generically yes it's easier to swap to something else.
https://www.goodreads.com/author/quotes/402425.Steve_Blank#:...
Often framed as “one vs two-way doo decisions” at Amazon.
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.
(delayed)
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?
what? this article is making a different point if you read past the title.
> Conventional leadership advice suggests looking at decisions as reversible or non-reversible. Many important, non-reversible, decisions are recoverable, though.
I don’t think it’s different. Recoverable == Reversible to an extend. Unless you take reversible in the strictest sense of “undo” it’s different. But you can’t “undo” a leadership decision, all you can do is later correct it and recover.
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.
Timing is everything. A bad haircut decision right before the most important job interview of your life might not be recoverable.
Great Clips or Weldon Barber, are you feeling lucky?
Great concept. Culturally, I think we are better at understanding this than ever before.
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?
For some reason before reading I thought this was going to be an AI thought leadership piece but it's even better than I expected.
The main difference being the time it takes to recover/reverse the decision.
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.
I actually like hats, haircuts, and tattoos. Seldom we have irrecoverable decisions--except death. https://jamesclear.com/quotes/i-think-about-decisions-in-thr...
(Also works well with LLMs, for risk assessments)
I've often thought along similar lines. I've found that indecision is almost always worse than a bad one. Very few choices are so decisive that you can't course-correct later.
That mindset has served me well both personally and professionally.
agreed on indecision being worse than a bad decision, with one caveat: i think people systematically underestimate how many decisions are actually recoverable.
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.
It becomes more difficult if you lean into and build upon the specific things that your stack choices give you. If you use everything very generically yes it's easier to swap to something else.