Why Your Team Keeps Relitigating the Same Decision

A decision that keeps coming back was not badly made. It was badly stored.

That distinction matters because teams usually respond to relitigation by trying to decide harder — more analysis, wider consensus, a longer document. None of that helps, because the problem is not the quality of the original call. It is that the reasoning behind it is no longer reachable, so the question is genuinely open again to everyone who encounters it.

What a round actually looks like

The sequence is remarkably consistent:

Someone raises it. Nobody can immediately say why the current approach exists. A thread starts. Two people half-remember different parts of the original reasoning, and neither is confident enough to close it. Somebody suggests a quick call. The call reconstructs perhaps two thirds of the original argument, discovers one constraint nobody had remembered, and lands — often — on the same decision.

And then it is not written down, because it was not a new decision. It was a re-confirmation, and re-confirmations feel like nothing happened.

Eight months later, it happens again.

The cost, counted honestly

The hours are easy to underestimate because they are spread across people and never appear on anyone's plan. A single round, roughly — and treat these as illustrative rather than measured:

Thread: 5 people, ~20 min each of reading and replying	~1.5 h
Call: 4 people × 45 min	3 h
Reconstruction — someone digging through old threads beforehand	1 h
Delay to whatever was blocked while it was open	2–5 days elapsed

Five or six hours of direct time, plus the elapsed delay, for a conversation whose output already existed. Twice a year, across the handful of decisions any product has that are worth arguing about, and it is a meaningful fraction of a quarter.

But the hours are not the real cost.

The second round is worse than the first

This is the part that makes relitigation genuinely expensive rather than merely wasteful.

The first debate happened with everyone who knew why the alternatives failed. The second happens with a partial roster and a partial reconstruction — the person who raised the killer objection has moved teams, and the constraint they knew about is not in anyone's summary.

So the second decision is made against a smaller set of facts than the first. Sometimes it lands in the same place anyway. Sometimes it does not, and the team reverses a decision without knowing it is reversing one — reintroducing a problem that was already solved, for reasons that were already considered and rejected.

Decisions do not just repeat. They drift, and they drift in the direction of whatever the current room happens to remember.

Four triggers, all legitimate

Worth noticing that nothing on this list is somebody being difficult:

A new person arrives with fresh eyes. Healthy, and exactly what you hired them for. It should cost two minutes to answer, not two weeks.

A constraint appears to have lifted. "We're on Stripe now, so can we revisit the seat model?" This is the best possible reason to reopen something — and it is unanswerable unless someone recorded that the seat model was the constraint.

Someone is annoyed by a consequence without knowing it was a decision. They experience it as a flaw, not a trade-off, because nothing marks it as deliberate.

Leadership or team composition changes. The new arrival has no reason to assume the current shape was chosen rather than accumulated.

Every trigger is reasonable. The failure is that none of them can be answered quickly.

What a decision log is not

Not a wiki section. Not a ceremony. Not an ADR process with a template and a review step — those work in engineering orgs that already have the habit, and die everywhere else within a quarter.

It is an append-only list of short entries, stored next to the work. Append-only is the property that matters: you never edit an entry, you supersede it. The superseded version stays, because "we used to do X and changed to Y in June because Z" is exactly the artifact that answers the question when it returns.

Editing history is what documentation does, and it is why documentation cannot serve this purpose — updating a doc to the current state deletes the thing you needed.

The five-minute version

Lower the bar until it actually happens. Four lines, written the day the decision is made:

2026-08-26 · Invite limit stays at 20
Why: seat model can't express per-seat proration above the plan cap.
Rejected: 50 (billing can't bill it), unlimited (support load, no cap on abuse).
Revisit if: we move to per-seat pricing, or billing ships proration.

Thirty seconds to write. The fourth line is the one that converts a future argument into a check — someone can answer "has billing shipped proration?" without reopening anything.

Two rules make it stick: write it at the moment, not later — a decision recorded a week on is a justification, not a record — and put it where the work is, because a log in a separate tool is a log nobody opens.

The test

You will know it is working when a decision gets raised again and someone answers in under a minute, from the record, in the thread where it came up.

Note that the good outcome is not "the question stops being asked." It is that the answer arrives fast and correct — and sometimes that answer is yes, that constraint really has lifted, let's reopen this properly.

That is the point worth ending on. The goal is not to prevent your team from changing its mind. It is to make changing its mind cheap and well-informed, rather than expensive and half-remembered. A team that never revisits decisions is not disciplined, it is stuck; a team that revisits them from scratch every time is not open-minded, it is amnesiac.

The log is what lets you be neither.

FAQ

What is a decision log? An append-only list of decisions with reasoning, rejected options, and a revisit condition. You supersede entries, never edit them.

Is relitigating always bad? No. The problem is cost. A ninety-second revisit is healthy; a two-week reconstruction is the same conversation at a hundred times the price.

Why is the second debate worse? Fewer people remember the constraints, so it optimises against fewer facts. Decisions drift toward whatever the current room recalls.

How much detail? Four lines. Longer will not get written when it matters.