A reversible technical decision doesn't deserve three weeks of debate

Some technical decisions trigger meetings, comparisons, prototypes and sometimes weeks of discussion.

Library A or library B?

Which framework?

What structure for this module?

Which component among three similar references?

The intent is legitimate: making the right decision.

But not every decision deserves the same effort.

Because they don’t all carry the same cost when they turn out wrong.

The risk isn’t being wrong #

In R&D, being wrong is inevitable.

The real question is rather: how much will discovering our mistake cost?

Choosing a software library you can replace in a few hours isn’t the same as choosing an architecture that will shape the product for five years.

Selecting a component available from several suppliers isn’t the same as designing an entire system around a proprietary technology.

Both are technical decisions.

But their level of commitment is nothing alike.

Some decisions close doors #

A decision becomes structural when it makes going back difficult.

The cost can be financial.

But it can also be technical: a major rewrite, new electronics, a mechanical change, re-running the tests or an architecture change.

It can be organisational: new skills required, a change of supplier or dependence on a partner.

And in some sectors, going back can even force you to repeat part of the validation process.

These decisions deserve time.

You have to identify the assumptions, compare the alternatives and understand what each choice will make difficult tomorrow.

Other decisions are simply temporary #

Conversely, some decisions can be made quickly.

Not because they don’t matter.

But because they’re easily reversible.

If two solutions look reasonable, their difference is still hard to measure, and you can move from one to the other at low cost, immediately searching for which is “the best” sometimes brings little value.

You can pick one.

Build.

Measure.

And decide again once more information is available.

The decision then becomes an experiment in itself.

The level of analysis should depend on the cost of going back #

Before a technical decision, a simple question can save a lot of discussion:

“If in three months we find this choice was wrong, what will we have to redo?”

If the answer is “almost nothing”, deciding quickly is probably reasonable.

If the answer involves six months of development, new electronics or a deep rethink of the product, a few extra days of analysis can be extremely well invested.

This distinction also helps focus the team’s energy where it really counts.

Because time spent securing an easily reversible decision is no longer available to study the ones that aren’t.

Deciding fast doesn’t mean deciding at random #

A reversible decision must still respect the known constraints.

It must be technically plausible.

Documented enough to understand why it was made.

And above all, its reversibility must be real.

A seemingly harmless decision can gradually become structural if other choices come to rest on it.

That’s why it’s useful to explicitly distinguish two categories: the decisions you can still easily change, and the ones you’re turning into foundations.

The first category mainly calls for action.

The second deserves thought.