intermediate 2 min answer

A team must decide quickly under uncertainty. How should decisions be classified so that speed is applied where it is safe?

growwreversibilityspeeddecisionsrisk
Show the full answer Hide the answer

The classification

By the cost of reversal, not by how important the decision feels.

Expensive to reverse — decide carefully, gather evidence, write it down: the data model and the meaning of core entities · the tenancy or partition key · the identity and permission model · a public API contract given to customers · what the audit record contains, if a regulator will ever ask · which store is the system of record.

Cheap to reverse — decide quickly, close to the work, with a bias to action: whether this is one service or three · which queue technology · caching strategy and layers · which managed service · the internal structure of any module · almost every performance optimisation.

Why this classification and not others

Importance is a poor guide, because an important decision that is cheap to reverse should still be made quickly — the cost of being wrong is a week, and the cost of deliberating is often longer.

Most stalled architectural disagreements are about reversible decisions being treated as irreversible, and pointing that out is frequently the whole intervention.

The corollary for the expensive category

Spend the design effort there, and only there. A team that agonises over the service boundary while accepting a schema that cannot express the second market has allocated its attention exactly backwards — and that is the most common expensive mistake in a fast-growing company.

The mechanism that makes a decision more reversible

  • An interface where variation is plausible, so a provider, a store or a strategy can be swapped rather than excavated.
  • A feature flag, so the change can be reverted in seconds rather than in a deployment.
  • Data captured that you do not yet use — a jurisdiction column, a tenant identifier, an effective date — because retrofitting a dimension into a live schema is one of the genuinely painful migrations and an unused column costs nothing.

The recorded output

For the expensive category, an ADR with the rejected options and the conditions that would change the answer. For the cheap category, a commit message. Applying the heavyweight process to both produces an archive nobody reads and devalues the records that matter.