Making Technical Decisions When There Is No Perfect Answer

Some decisions are easy. There is a right answer, someone on the team knows it, and the conversation takes four minutes.

The ones that consume your week are the other kind. Three options, each wrong in a different way, no data that settles it, and five people with reasonable opinions pointing in three directions. Meanwhile the work is blocked and everyone is looking at you.

The instinct is to keep investigating until the answer becomes obvious. It usually does not. Here is what works instead.

First: how expensive is it to be wrong?

Before evaluating any option, classify the decision. This single question determines how much time it deserves, and most teams get it backwards — agonising over reversible things and rushing irreversible ones.

Spend your decision-making energy in proportion to the cost of being wrong, not the interestingness of the problem.

A surprising number of stalled debates are about cheap decisions. Naming a thing. Choosing between two libraries that both work. The cost of the discussion has already exceeded the cost of picking the worse option and moving.

Write down what you are optimising for

Most deadlocked technical arguments are not disagreements about facts. They are disagreements about priorities that nobody has said out loud.

One person is optimising for time to ship. Another for long-term maintainability. A third for not introducing a dependency. All three are right, given what they are each weighting, and they will argue past each other indefinitely.

The unblock is to name the criteria first, before discussing options:

For this decision, in priority order:
  1. Must be maintainable by the whole team, not just whoever builds it
  2. Must not block the November release
  3. Should minimise new dependencies
  4. Nice to have: reusable for the reporting module later

Half the time, agreeing that list resolves the argument without anyone discussing an implementation at all — because it becomes obvious which option wins on the things that matter most.

Ask what each option costs when it fails

Comparing options by their benefits is where you get stuck, because the benefits are usually comparable. Compare them by failure instead.

That fourth point is the one that changes most often when you move from engineer to lead. The technically strongest option that only you fully understand is frequently the worse choice, because the team has to live in it when you are unavailable.

Reduce uncertainty cheaply, then stop

When the disagreement is genuinely factual — “will this scale?”, “is that library workable?” — do not argue. Time-box a spike.

Two rules keep spikes from becoming projects. Fix the duration before you start: two days, not “until we know”. And write down what would change your mind beforehand — “if it handles 10,000 rows under 200ms we go with it”. Without that, a spike produces more opinions rather than fewer.

The thing to accept: at some point more investigation stops adding information. If two days of work has not separated the options, they are probably close enough that the choice matters less than the delay.

Prefer the decision you can walk back

When two options are genuinely close, the tie-breaker is which one leaves you more room.

A concrete version of this: if you are unsure whether you need a shared service or duplicated logic in two places, duplicate first. Duplication is easy to consolidate later once you can see what is genuinely common. A premature abstraction is much harder to unwind, because everything has already been bent to fit it.

Same principle with dependencies, data shapes and integration points. Ask which option would be cheaper to regret.

Then actually decide, and say so

This is where leads most often fail, and it is the failure that costs the most.

An undecided decision is not neutral. It has an ongoing cost: the work is blocked, people re-litigate it in standup, and two engineers quietly start building toward different assumptions. A decision that is seventy percent right, made today, usually beats one that is ninety percent right, made in two weeks.

When you decide, be unambiguous. “Let us go with option B” — not “I am leaning towards B”, which is an invitation to keep arguing.

Write down why, in fifteen minutes

This is the highest-return habit in this entire article, and almost nobody does it consistently.

# Eligibility caching strategy

Date: 12 September 2026
Status: accepted

## Context
Vendor eligibility calls take 1.5–4s. Enrolment needs them on three
screens. Vendor rate-limits us at 50 req/s.

## Options
A. Call the vendor every time — simplest, but slow and rate-limited
B. Cache for 24h — fast, but stale data can show wrong coverage
C. Cache for 1h + invalidate on webhook — fast, mostly fresh, more moving parts

## Decision
C.

## Why
Staleness on coverage is a client-facing correctness problem, so B is out
despite being simpler. A does not survive open enrolment traffic.

## What we are accepting
The webhook is a new failure mode. If it stops firing we serve up to an
hour of stale data silently. Mitigation: alert if no webhook in 2 hours.

## What would make us revisit
If the vendor publishes a bulk endpoint, or if webhook reliability
drops below ~99%.

Fifteen minutes. What it buys you:

• The same argument does not get had three times over two years
• When someone asks “why is it like this?”, the answer is not your memory
• New joiners learn the reasoning, not just the result
• The “what would make us revisit” section means changing your mind later is a plan, not a reversal

That last section is the one people skip and the one that matters most. A decision with a stated trigger for revisiting is not a commitment — it is a bet you are consciously placing, with an exit condition.

Being wrong is not the failure

You will make calls that turn out badly. That is unavoidable when you are deciding under uncertainty, which is the whole job.

What matters is whether you notice. A decision record with a revisit trigger, plus something that actually measures the thing, means you find out in three months rather than in an incident. That is a functioning process, not a mistake.

The failure is not choosing wrongly. It is choosing slowly, choosing without saying why, or never checking whether you were right.

The short version