Irreversible decisions need a different process

A technology leader’s biggest mistake isn’t deciding wrong. It’s using the same process to decide everything.

When every decision goes through the same ritual, two things happen at once. Reversible decisions get slow, buried in ceremony. And irreversible decisions go through too fast, because nobody noticed they were irreversible.

The distinction is old. Using it isn’t

The idea isn’t new. Jeff Bezos popularized it with the image of doors: the two-way door, which you can walk through and come back at low cost, and the one-way door, where going back is expensive or impossible.

Everyone agrees with the distinction. Almost nobody takes the step it requires: classifying the decision before choosing the process.

In practice, the process is picked by organizational habit, by the committee’s calendar or by the anxiety of whoever asked. Rarely by the cost of getting it wrong.

In technology, the examples are concrete

Reversible:

• which library to use for a new feature;
• how a campaign is configured;
• an A/B test;
• the order of next sprint’s backlog.

Irreversible, or nearly so:

• the choice of e-commerce platform;
• the ERP;
• the core data model;
• the integration architecture between systems;
• a long-term contract with a critical vendor.

The first group deserves speed. Getting it wrong costs days, and learning is worth more than analysis. The second group deserves something else: time, data, options compared side by side, and the people who will have to live with the decision sitting at the table.

The cost shows up late

The problem isn’t making the wrong decision. Wrong decisions are part of the job.

The problem is applying the wrong process and only seeing the cost when undoing it has become the most expensive option on the table. A platform chosen at the pace of a campaign decision sends the bill two years later, in the form of a migration.

The opposite costs too. An organization that treats everything as irreversible freezes. Every small choice becomes a committee, and the team learns that it’s safer not to propose anything.

The test I use

Before starting any relevant decision, I ask one question:

If we get this wrong, how much does it cost to fix? Weeks? Months? Budget already committed? The trust of a key stakeholder?

If the answer is “weeks”, the decision should be fast, made close to the people who execute it, and revisited with real data.

If the answer is “months” or more, the process needs to be more robust, not faster. That means alternatives compared in writing, explicit assumptions, named risks, and a decision record that someone can read two years from now and understand why it was made.

What changes for whoever leads

Classifying decisions is leadership work that shows up nowhere. Nobody thanks you for the reversible decision made in an afternoon, or for the irreversible one that got three more weeks of analysis.

But that work is what determines whether the team moves fast where it can and carefully where it must. Speed and rigor aren’t opposites. They’re tools for different doors.