Engineering decisions are bets, not proofs

Most engineering decisions are not proofs.

They are bets.

You choose a direction with incomplete information, under time pressure, and with trade-offs you cannot fully test in advance.

That does not make the decision weak.

It makes it real.

In a previous post, I wrote about how design by committee leaves engineering change unfinished. The deeper reason is simple: many organisations treat technical decisions as though they should be certain before the work begins. But most meaningful engineering decisions are not certainties. They are bets.

Annie Duke puts this well in Thinking in Bets. Decision-making is more like poker than chess. In chess, everything is visible. In poker, you are working with hidden information, incomplete knowledge, and the influence of luck. You can play the hand perfectly and still lose.

Engineering decisions work the same way. You are choosing a direction based on what you know now, not what you will know in six months. The quality of a decision is not whether it later turned out to be right. It is whether it was a good bet given the information available at the time.

The outcome trap

Teams often judge decisions by outcomes alone: good outcome, good decision; bad outcome, bad decision.

But that is too simple. A good decision can have a bad outcome. A bad decision can get lucky.

Norman Kerth put it well in his Prime Directive for retrospectives:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

If the team made a reasonable bet with the information they had, the fact that it did not work out does not mean the decision was wrong. It means the context changed, or something was unknowable.

I have seen teams adopt a framework that later proved the wrong fit, and conclude that the decision-making process itself was broken. But when you looked back at the information they had at the time, the decision was reasonable. What changed was the context. New requirements appeared. The team's needs shifted. The framework's maintainer abandoned it.

I have also seen teams make a questionable architectural choice that happened to work because the product never scaled past the point where the weakness mattered. That is not a good decision. That is luck.

If you only evaluate decisions by results, you learn the wrong lessons. You punish reasonable bets that did not pay off and reward reckless ones that happened to land. The right response is to update the bet, not to blame the people who made it.

What good bets look like in engineering

Why now?

Not every decision needs to be made upfront. Some are better deferred until you know more. But when a decision does need to be made, there should be an honest answer to "why this, why now."

What are the trade-offs?

Not just the upside, but what you are giving up. What becomes harder. What you are accepting as a known risk.

How small can we make the bet?

A good bet does not try to solve everything at once. It solves enough to move forward and learn.

How will we test it?

If you are betting that Kubernetes will simplify your deployment, what does the first service migration teach you? If you are betting on event-driven architecture, what does the first event contract tell you about the integration pain?

What would make us change our mind?

If the bet turns out to be wrong, or the context changes, the team knows how to revisit it. This is where ADRs can be genuinely useful. A short record that says what we believed, why we believed it, and what would trigger a rethink.

Is it reversible?

Not every decision can be reversed cheaply, but the ones that can should be treated differently from the ones that cannot. A reversible bet deserves less ceremony and faster action. An irreversible one deserves more care.

Some teams formalise this by constraining time and scope. Basecamp's Shape Up process, for example, treats projects as bounded bets: decide how much time something is worth, shape the work to fit, and if it does not ship within six weeks it does not automatically get more time. The principle is simple. Smaller bets create faster learning.

The learning loop

The learning loop is straightforward. You make a decision, observe the outcome, separate what was skill from what was luck, and update your beliefs.

Most teams skip the middle step. They see a result and immediately conclude either "we were right" or "we were wrong" without asking how much of the outcome was down to the decision itself versus circumstances outside their control.

At University Press, when we migrated services onto a new platform, we treated each service as a bet. We expected some of our assumptions to be wrong. The point was not to be right the first time. It was to make being wrong early cheap.

One team discovered that their networking assumptions were off. Another found that the deployment configuration needed to be more flexible than anyone had anticipated. Those were not failures. That was the loop working.

The lesson should not be "we should have known." It should be "we learned, and now we update."

Two heads are better than one, but not twenty

Getting a second perspective helps you spot blind spots, challenge assumptions, and test whether your reasoning holds up. Duke calls this the "buddy system" and I think she is right about it.

Two or three people pressure-testing a decision is valuable. But there is a threshold where adding more people stops improving the decision and starts slowing it down. That threshold is lower than most organisations think.

The best engineering decisions I have been part of involved a small group who understood the problem, had the relevant context, and were willing to disagree with each other. The worst involved large groups where nobody had enough context to push back meaningfully, so the discussion became about politics and risk aversion rather than trade-offs and evidence.

This is the same dynamic that turns ADRs into bureaucracy. The instinct is to involve more people to reduce risk. But past a certain point, involvement does not reduce risk. It diffuses ownership.

Pre-mortem and backcasting

In her book there are two techniques Duke discusses.

A pre-mortem starts with a simple question: imagine this decision failed. Why? This forces the team to think about risks they might otherwise dismiss because they are optimistic about the outcome. It is not about pessimism. It is about preparation.

Backcasting asks the opposite: imagine this decision succeeded. What did we do to get there? This helps identify the steps that actually matter and separates them from the busywork that feels productive but does not move the needle.

Both work backwards from reality rather than forwards from assumptions. They are also quick. A fifteen-minute pre-mortem before a significant decision is worth more than a two-hour planning meeting that tries to account for every scenario.

ADRs as bet records

If you think of decisions as bets, ADRs become something different. They are not proof that the team thought carefully. They are a record of the bet.

What did we believe at the time? What information did we have? What were the alternatives? What trade-offs did we accept? What confidence level did we have? And what would cause us to revisit this?

That is a useful document. It helps future teams understand not just what was decided, but the state of knowledge at the time. It makes it easier to judge whether the decision should be revisited because the context has changed, or whether the original reasoning still holds.

The key is brevity. A bet record should be short because the bet itself should be bounded. If the ADR is long, the decision is probably too big.

Show, don't tell

The best engineering teams do not wait to prove a decision right in theory. They make a bounded bet, observe what happens, and adapt.

The quality of an engineering decision is not whether it later looks right in hindsight. It is whether the team was honest about what it knew, explicit about the trade-offs, and disciplined about keeping the bet small enough to learn from.

Strong teams do not wait for certainty. They make the next good bet, learn quickly, and adjust.