Keep every option open, and you eventually stop moving forward

“Let’s keep both for now.”

It’s a rather reassuring sentence.

It avoids deciding too fast, leaves a door open, and lets you keep moving as long as you don’t have all the information.

In R&D, it’s often a good decision.

The problem is that all the information will never arrive.

At some point, keeping several solutions in parallel no longer protects the project from a bad decision. It simply starts to cost it time.

Exploring is necessary #

Early in a project, it would be dangerous to decide too fast.

You don’t yet know which sensor will give the best results. Two architectures look possible. Several algorithms deserve testing. One technology looks promising, but another is simpler to integrate.

That’s normal.

This period of exploration is exactly what lets you confront ideas with reality before committing to a direction. You test. You measure. You rule some leads out. You sometimes discover others no one had thought of at the start.

Trying to remove that uncertainty from the outset would mean deciding before you’ve learned.

But exploration is only valuable if it lets you, sooner or later, reduce the number of options.

Keeping an option open isn’t free #

Two solutions are still on the table. So you keep both.

The code is designed to support both architectures. The tests have to work with both. The documentation describes both possibilities. The technical discussions keep comparing their advantages.

And every new decision now has to account for both scenarios.

Then a third possibility appears. You could set it aside, but it has an interesting advantage. So you add it too, “for now”.

The project gradually becomes able to do everything. Except move forward simply.

Because an option you keep has a cost, even when it’s never used. It adds code, interfaces, test cases, conditions, documentation. But above all, it adds something far less visible: it increases the number of future decisions that still depend on a decision you haven’t made.

Waiting for certainty is a decision #

There’s a fairly natural reason for this: no one likes choosing the wrong solution.

So you wait for one more piece of information.

• A test.
• A benchmark.
• User feedback.
• A new version of the component.
• A more precise measurement.

And sometimes that information genuinely deserves to be waited for. But you also have to ask what it could change.

If the next test can really reverse the decision, let’s run it. If it will probably only confirm, with a little more precision, what we already know, waiting any longer may no longer bring much.

This is where the search for certainty becomes deceptive. You can always run one more test. There will always be an edge case we haven’t tried, one more data point to measure, or a hypothesis we could dig into further.

So the question isn’t whether we know everything. The question is whether what we don’t know yet justifies delaying the decision.

Not every uncertainty is worth resolving #

Take two technical solutions.

The first works well, meets the known constraints and relies on a mastered technology.

The second might be slightly better, but would take several more weeks of work to prove it.

It’s tempting to carry on. After all, why choose today if we might find something better tomorrow?

Because those weeks have a value too. And above all because the possible difference between the two solutions may have no real consequence for the product.

It’s fairly easy to fall into this trap in R&D. A technically interesting problem appears and you keep digging because there’s still something to understand. It’s no longer necessarily the project that requires it. Sometimes it’s simply the engineer who would like to know the answer.

I know the temptation well. But at some point, you have to accept that a question can stay open without stopping the project from continuing.

Deciding doesn’t mean being certain #

A technical decision is rarely made with 100% of the information you’d want. It’s made with enough information to consider the remaining risk acceptable.

That’s very different.

You can choose an architecture while knowing another might have given better results. You can select a component without having tested all its competitors. You can stop optimising an algorithm while knowing full well you could still shave off a few milliseconds.

That isn’t giving up on rigour. It’s recognising that the goal isn’t to find the best solution imaginable. The goal is to find a solution good enough for the problem, the constraints and the level of risk you accept.

And to keep going.

You also have to know how to close doors #

There’s something quite comfortable about keeping every option open. As long as no final decision is made, no decision can really be wrong.

But a technical project is also built with the doors you agree to close.

• We’ll use this component.
• We’re going with this architecture.
• This lead is dropped.
• This performance is enough.
• This use case won’t be handled in this version.

From there, many other decisions suddenly become simpler. The team can stop designing for several possible futures and start building for the one that was chosen.

Of course, some decisions can be revisited later if the context changes. But that’s no reason to put them off today.

Knowing when you’ve learned enough #

This is probably one of the hardest boundaries to find in R&D.

Stopping too early risks missing a better solution. Continuing too long risks turning exploration into paralysis.

There’s no universal threshold to decide. But one question often helps: what can the next experiment still change in our decision?

If the answer is clear, the experiment is probably worth running. If no one can really answer, perhaps the project no longer needs a new experiment.

It needs a decision.

In R&D, moving forward isn’t about knowing everything before you choose. Sometimes you simply have to know when you know enough to decide.