A team lead in a small product-management community posted a number recently that landed harder than it should have. He had tracked his team's meetings for a month. Fifteen to twenty percent of the calendar was spent on some version of wait, why are we doing it this way? — followed by someone trying to reconstruct the reasoning from memory, followed by a debate that mostly landed in the same place it had landed before.
His framing was the sharp part: it was not a documentation problem. The ticket existed. The PRD existed. What did not survive was the rationale — why approach A beat approach B, what constraints were in play, what was explicitly ruled out. The output got captured. The thinking that produced the output did not.
That is the tax. It scales linearly with team size, communication volume, and the rate at which the world around the team changes — which, in 2026, is high on all three axes.
The 15% tax, named
Call it the re-litigation tax. The cost of a small team paying it shows up in three places at once.
First, calendar time. Fifteen percent of an engineering manager's meetings means roughly six hours a week the team is having a conversation it has already had. At a loaded cost per engineer-hour, a ten-person team is burning the equivalent of one full-time salary on retreading old ground.
Second, decision quality. When you reconstruct a decision from memory, you reconstruct it without the constraints. The senior engineer who knew that the third-party API does not support refunds in the EU has moved teams. The PM who knew that legal had blocked the original design has been promoted. The new debate happens in a context that is missing the load-bearing facts, and the team ships a worse version of the same choice, because the original reasoning is gone.
Third, trust. When the same question keeps getting re-opened, no decision feels settled. People stop investing in execution because nothing seems durable. The behavior that follows — over-arguing, defensive documentation, design-by-committee — is rational under the conditions, but the conditions are the problem.
The natural reaction is to write more, faster, in better templates. Decision logs. Architecture Decision Records. RFC documents. The genre has been around for a decade. Every team we talk to has tried at least one of them. And the tax is still there. Why?
Why decision logs and ADRs do not save you
Michael Nygard's original 2011 essay on Architecture Decision Records is a beautiful piece of writing. The format is genuinely good. The problem is not the format. The problem is that the format assumes three things small teams almost never have, and ignores the dynamics that actually break the system.
Failure mode one — write-only documentation
ADRs and decision logs presume someone will write them when a decision is made. In a five-to-fifteen-person team, the moment a decision is made is also the moment everyone moves on. The pressure to ship is higher than the pressure to document. The PM who would write the log is in the next meeting. The engineer who would write the ADR is unblocked and back in the editor. The decision exists, fully formed, in three people's heads — and in zero artifacts.
You can mandate that decisions be logged. You will get the kind of log that survives mandates: a one-line entry that satisfies the policy and contains none of the reasoning. The system technically works. The information you actually needed is still gone.
Failure mode two — no read path
Even when the log exists and is good, nothing in the team's daily workflow surfaces it at the moment a question gets re-asked. The PM in the meeting cannot remember which decision document covered authentication. The engineer in the PR review cannot remember whether the existing approach to error handling was deliberate or accidental. The doc sits in a folder in Notion that no one is browsing, indexed only by titles no one wrote with future search queries in mind.
This is the most damning failure. Documentation without a read path is performance art. The team that wrote the perfect ADR and the team that wrote nothing end up in the same re-debate, because neither team's process reaches into the meeting and hands them the prior reasoning.
Failure mode three — no trigger to revisit
Most decision logs treat decisions as either open (still being discussed) or closed (final). Real decisions are neither. Every decision is implicitly conditional on a set of facts — a customer constraint, a vendor capability, a team's hiring trajectory, a regulatory environment. When the facts change, the decision should be reopened. When the facts have not changed, the decision should not be relitigated.
ADRs and logs are silent on this. They tell you what was decided. They do not tell you under what conditions you should reopen this. So every meeting is implicitly a meeting where any decision is eligible for reopening, and any unease — usually a new team member's unfamiliarity with the original reasoning — is enough to trigger the re-debate.
We have written about this exact gap before — specs decay within 48 hours of being written, not because PMs are sloppy, but because the spec lives in one tool and the work lives in five others. Decision logs decay for the same reason, faster.
What a decision actually contains
Before we propose an alternative, it is worth being precise about what a decision really is. Most decision logs capture one field: the chosen option. The interesting information is in the four fields they do not capture.
A complete decision has:
- The choice itself — the thing you are going to do.
- The alternatives ruled out — and specifically, why each was ruled out. This is what people need when they re-open the debate, because it is almost always one of these alternatives someone is re-proposing.
- The constraints that drove the choice — the load-bearing facts. The vendor limitation, the legal requirement, the team's skillset, the budget envelope. These are the things that should trigger a re-open if they change, and should not trigger one if they have not.
- The dissent — who disagreed, what their objection was, what would change their mind. Suppressed dissent does not go away; it surfaces as the third meeting that re-opens the decision. Recorded dissent is metabolized.
- The reopening condition — the explicit statement of when this should be revisited. Reopen if the vendor adds bulk-write support. Reopen if we hire a second iOS engineer. Reopen if the customer count crosses 10,000. Without this, every meeting is implicitly a reopening meeting.
Capture all five and you have something the team can use. Capture only the first and you have a log entry that loses the next debate.
From logs to threads
The shift the small-team world needs is not write better logs. It is stop writing logs and start writing threads.
A decision thread lives where the decision was made. If the decision came out of a spec discussion, the thread is attached to the spec. If it came out of a PR review, the thread is attached to the PR. If it came out of a Slack debate, the thread is attached to the Slack message — and the spec, and the PR. The artifact follows the work, instead of waiting in a separate tool for someone to come find it.
A thread is queryable. Not by typing the right title into a folder search, but by being adjacent to the artifact you are already looking at. The new team member opening the auth module gets the thread in their face. The PM about to re-open the refund-flow debate gets last quarter's reasoning surfaced before they form the meeting agenda.
A thread is revisitable. It carries its reopening condition with it. When the condition fires — vendor capability added, customer count crossed, team composition changed — the thread surfaces, and the team revisits the decision with the original reasoning in hand, instead of from a blank page.
What this looks like in practice
We have been building toward this shape for the last year. The components that make decision threads work — in our product, but also in any product that intends to solve this problem — are not exotic. They are four properties that have to be present together, because any one of them in isolation fails.
Decisions live next to the artifact they decided. Specs carry their own version history, their own discussion thread, their own linked feedback. When a new acceptance criterion goes in, the conversation that produced it is one click away. When a piece of customer feedback is what justified the criterion, the original signal is linked. The why is not in a separate folder; it is on the same surface as the what. This is the same principle behind spec-driven development — the spec is alive, the spec is the source of truth, and the spec carries its own context.
Decisions notice when reality drifts. A decision is only durable if the system tells you when the world has moved out from under it. Drift detection watches PRs and surfaces the moment a piece of code violates an explicit decision in the spec — before the merge, while the conversation that produced the original decision is still recoverable. We have written about what drift detection actually does; the version of it that matters for re-litigation is that it makes the reopening condition an automatic trigger, not a manual remembering.
Decisions stay attached to the work. Every spec and every kanban card carries an org-scoped ticket number. PRs reference the ticket. The ticket references the spec. The spec references the customer feedback that justified it. The full chain — we shipped this code, because of this spec, because of this customer signal, after this debate — is traversable from any point in the chain. No information loss event at any handoff. We have written about why the disconnected PM tool stack creates this fragmentation and what the connected version looks like.
Decisions show their dissent and constraints. This is the part we are still learning to do well, and the part the open-source world has not really solved either. First-class capture of which alternative was ruled out, which constraint was load-bearing, and who dissented and why — surfaced in the editor as the spec is being written, not as an afterthought — is what separates a decision thread from a glorified comment field. The honest state of the art is that most teams approximate this with conventions and review templates; the next generation of tools will make it a primitive.
The honest checklist
If you want to know whether your team is paying the 15% tax, run this checklist against the last three significant decisions you made.
For each one, can a new team member who joins next week:
- Find the decision without asking anyone? (Read path test.)
- See which alternatives were considered and why each was ruled out? (Alternatives test.)
- Identify the two or three facts the decision depends on? (Constraints test.)
- Know who disagreed at the time, and what their objection was? (Dissent test.)
- Find a stated condition under which the decision should be reopened? (Reopening test.)
If the answer is no on three or more questions for any of the three decisions, you are paying the tax. The size of the tax scales with the size of your team and the rate of context change. For a five-person team in a slow domain, it is tolerable. For a fifteen-person team shipping at AI speed, it is the largest hidden cost on the org chart.
The good news is that seeing the tax is most of the work of paying it down. The teams that have named the problem — even imperfectly — recover most of the calendar time within a quarter, simply by becoming intolerant of the meeting pattern. The teams that have not named it keep paying.
What to do on Monday
Three small moves, in order, that do not require any new tool to start.
Run the checklist above on your last three decisions. Do it with the team in the room. The shared recognition of how much information is already gone is the unlock; you cannot delegate it.
Add two fields to your decision template, today: what was ruled out and why, and under what condition should we reopen this. Two fields. Not five. Two. The marginal cost is thirty seconds at decision time and several hours of meeting time saved later.
Pick the one re-debate your team has had three times this quarter, and write the thread for it now. Walk back the reasoning, the constraints, the alternatives, the dissent. Attach it to whatever surface the team will actually look at. The next time the question comes up — and it will come up — you will be debugging a thread, not redoing a debate.
The teams that win the next five years will not be the ones that decided fastest. They will be the ones whose decisions stayed decided without staying frozen — durable, surfaceable, revisitable on the right triggers. The 15% tax is the most expensive recurring cost most teams are not measuring. Stop paying it.