Most teams think their alignment problem is a communication problem. It isn’t. It’s a decision record problem. Decisions get made in conversations that newer team members weren’t in, and nobody records them.

A decision that isn’t recorded is a decision that will be made again. The same question surfaces in a meeting six months later.

Someone remembers the original answer. Someone else remembers it differently. Thirty minutes is spent re-adjudicating a decision that should have been implemented.

The Operational Decision Log closes the gap between “we decided” and “everyone knows what was decided and why.” This article is for the scaling team where the same decisions keep surfacing for discussion.

Why Decisions Get Relitigated

The obvious failure mode: a decision is made in a meeting. It’s not recorded. Three months later, a new team member asks why things work a certain way.

Nobody can explain it clearly. The question surfaces in a broader team discussion. The decision gets relitigated.

The less visible cost is the overhead of relitigated decisions. Each relitigated decision doesn’t just cost the time in the meeting. It costs the credibility of the original decision-maker, it costs the attention of everyone present. It often produces a slightly different decision with no clear reason for the change.

The deepest failure is the organizational pattern it creates. A team that regularly relitigates decisions without clear records learns that no decision is final until it’s relitigated again. Decision-making slows. Everyone waits to see if the decision will stick.

The Three-Domain Operational Decision Log

The operational decision log is distinct from the feature decision log from The Feature Decision Log That Saves Hours of Re-Explanation Every Quarter, Article 19. The feature log covers product-specific decisions. The operational log covers everything else.

Domain 1: Commercial decisions

Commercial decisions cover pricing changes, contract terms, vendor commitments, and partnership structures. These are the decisions that have financial consequences and that new team members need to understand without lengthy context briefings.

For each commercial decision, record:

  • What was decided and when
  • The financial impact or commitment
  • Who made the decision and who was consulted

Domain 2: People decisions

People decisions cover hiring, role changes, performance actions, and compensation changes. These decisions have significant downstream effects and are the ones most commonly assumed to be confidential and therefore never recorded in any accessible form.

Recording people decisions doesn’t require sharing sensitive compensation data. It requires recording the fact and rationale at the level of “we promoted X to lead engineer in March because the team needed a technical lead as we scale toward 20 people.”

Domain 3: Process decisions

Process decisions cover how the team works: which tools, which rhythms, which standards. These decisions are often informal and therefore highly subject to drift and re-litigation.

For each process decision, record:

  • What was decided (the process or standard adopted)
  • Why this approach rather than the alternative
  • When it’s expected to be revisited

How the Living Library Maintains the Operational Decision Log

Six months in, a new ops hire asks why the team approves refunds the way it does. Nobody can quite remember the reasoning behind the rule. The Operational Decision Log exists so that answer never goes missing. It sits in the Living Library next to the product and team decision logs, so every kind of organizational decision lives in one place.

As decisions get made, they land in the log with their rationale and the person who made them. No one runs a quarterly documentation sprint to catch up. The entry is written when the decision is fresh, which is the only time the reasoning is still intact.

When the new hire asks “why do we do it this way?”, the Conductor brings back the decision record and the reasoning behind it. Kiluma’s context-aware AI answers from the log, so the team member gets the context without pulling a senior person off their work.

Log the Last Three Significant Decisions Before They Become Undocumented History

Before the next team meeting, identify the three most significant operational decisions made in the past 60 days. For each, write one sentence on what was decided and one sentence on why.

Those six sentences are the foundation of the Operational Decision Log. The next decision adds to it. The log that exists now is always better than the perfect log planned for the future.

The Operational Decision Log Is the Memory the Team Otherwise Loses

Decisions recorded are decisions that the team can act on consistently. Decisions unrecorded are decisions the team relitigates. The Operational Decision Log is the system that converts the former into an organizational standard and prevents the latter from wasting the team’s time. Try Kiluma free for 14 days at kiluma.ai.