There's a heuristic I keep coming back to: before you agonize over a decision, ask how much it costs to change your mind.
If the answer is "not much," the decision is reversible, and you should make it fast. Spend maybe ten minutes thinking it through, name a rollback plan, and move. Reversible decisions that aren't made are just delayed reversible decisions — they don't improve with time.
If the answer is "a lot," the decision is irreversible (or costly-to-reverse, which is close enough), and you should treat it like a bet: write your assumptions down, assign rough confidence, name what would have to be true for it to go wrong, and set a time to check whether you were right.
Why this matters more than decision difficulty
Most frameworks treat decision quality as a function of how hard the decision is. The reversibility frame cuts orthogonally: it's not about difficulty, it's about downside asymmetry.
A hard reversible decision (should we refactor this messy service?) should be made quickly, because being wrong costs you a week and you can course-correct. A seemingly-simple irreversible decision (what shape should our data take once it's live?) deserves much more care, because being wrong costs you a migration.
The mistake I've seen most often — in myself and in teams — is applying the same process to both. Teams paralyzed by reversible decisions waste hours on low-stakes analysis. Teams that treat irreversible decisions casually, because they feel "obvious," pay the migration tax later.
A data migration makes the line concrete
When I migrated a set of aviation operational systems from relational databases to MongoDB, the reversibility frame did real work in separating two decisions that felt like one.
Whether to migrate at all was, within reason, reversible. You can move incrementally, watch behavior, and stop or roll back a collection if it goes badly. So I used an incremental, dual-write rollout precisely to keep it reversible — each step independently undoable — rather than betting everything on one cutover.
The document model — what to embed, what to reference, what the aggregation pipelines precompute — was the irreversible part. Once live operational data is written in a given shape and the integrations depend on it, changing that shape is itself a migration. So that decision got the bet treatment: model around the real read patterns, name the assumption that the workload is read-dominated, and commit deliberately.
Naming which half was which is what kept the project from being either reckless or paralyzed.
What to write down for an irreversible decision
The minimum viable record:
- What we're choosing, stated clearly enough that future-you recognizes it
- Why — the two or three reasons it's the right call given what we know now
- The assumptions — what has to stay true for this to hold up; this is your early-warning system
- Confidence (even rough — 70%? 40%?), because putting a number on it forces you to feel the uncertainty
- When to revisit — a date or trigger, or you never will
This is essentially an ADR. They feel bureaucratic because people reach for them on every decision. They feel reasonable when you reserve them for the irreversible ones — which is exactly what the case studies on this site try to do, one Decision Record at a time.
The failure mode I watch for
The frame can be misused to under-think things. "We can always change it" is sometimes true and sometimes a rationalization for not thinking hard enough.
The test: would changing your mind require a migration, a customer communication, an org re-alignment, or a serious chunk of engineering time? If yes, it's irreversible and deserves the bet treatment regardless of how confident you feel.
Confidence is not a substitute for reversibility. You can be 90% sure about something irreversible and still owe it to future-you to write down what the other 10% looks like.