How should reversibility change the process applied to a decision, and which decisions are commonly misclassified?

How it should change the process

Reversible decisions deserve a decision and a measurement. Make the call quickly, instrument the outcome, and change it if the evidence says so. Deliberating extensively over something you can undo in a sprint spends more than the mistake would cost.

Irreversible decisions deserve genuine analysis — options, evidence, a written rationale, and consultation with people who will live with the consequences. These are worth weeks.

Applying equal effort to both is the dominant cause of slow decision-making, and it simultaneously under-serves the decisions that matter.

Commonly misclassified as reversible

• Data model and schema. Once data exists in a shape and other systems depend on it, changing it is a migration with coordination. The least reversible decision in most systems.
• Public interfaces. A contract shipped to customers or partners cannot be changed unilaterally, and ecosystem tools update slowly.
• Tenancy and identity model. Retrofitting an organisation layer or a tenant boundary is a rebuild.
• The shard key, which determines what can be queried without a scatter-gather and cannot be changed without rewriting the dataset.
• Event schemas, which are immutable once published and must remain interpretable for as long as the events are retained.
• A long capacity commitment, which outlives the architecture and becomes an argument against changing it.

Commonly misclassified as irreversible

• Language and framework within one service, which one team can change in a quarter with nobody outside needing to know.
• Cloud provider for a stateless workload, where the difficulty is usually the data rather than the compute.
• Internal module structure, changeable as a code change rather than a migration.
• Most technology choices behind a stable interface, which is what the interface is for.

The practical technique

Ask what it would take to undo this in eighteen months, concretely: whose code changes, what data moves, which external parties are affected, and how long the migration takes.

That question is far more useful than an instinct about permanence — and it frequently reveals that the decision everyone is agonising over is cheap to reverse, while one being made casually is not.