Decision Log Template: Fields, Formats, and Examples for Operators

Most organizations make far more decisions than they document. A three-person leadership team making five meaningful decisions a week will have logged over 250 choices in a year — most of which exist only as a memory in whoever was in the room. When that person leaves, gets promoted, or simply forgets, the reasoning disappears. The next team member facing the same situation starts from scratch, relitigates settled questions, or quietly reverses a decision no one knew had already been made. A decision log does not prevent bad decisions. It prevents the same bad decision from being made twice, ensures accountability is clear at the moment of choice, and creates the raw material for honest retrospectives on whether your reasoning was sound.

This post provides practical, ready-to-use decision log templates for strategic, operational, and technical decisions — along with field definitions, worked examples, and guidance on when to use which format.

Why decision documentation matters more than most teams admit

Research on decision quality consistently points to the same gap: organizations that document their decision-making processes — capturing context, options, and rationale — outperform those that rely on institutional memory and verbal consensus. A McKinsey survey on organizational decision-making found that companies where decisions are clearly documented and ownership is explicit report 25% higher project success rates. The mechanism is not mysterious. Documentation forces clarity before a decision is made, not after. The act of writing down the options and the rationale reveals gaps in reasoning that live discussion tends to paper over.

Amazon built "Have Backbone; Disagree and Commit" into its leadership principles for exactly this reason. The principle requires leaders to challenge decisions before they are made and then commit fully once a direction is chosen — neither capitulating early to avoid conflict nor undermining the decision after the fact. The documentation layer underneath that principle is what makes it operational. When the reasoning behind a decision is written down, the "disagree" phase has something concrete to engage with. Without it, the debate is about opinions rather than evidence.

Engineering organizations figured this out early. Architecture Decision Records (ADRs), popularized by Michael Nygard and now formalized in AWS and Microsoft Azure guidance, are lightweight documents that capture a single technical decision — the context, the options considered, and the chosen approach — and store them alongside the code they describe. The format has been adopted well beyond engineering because the underlying problem is universal: decisions made without a written record degrade the quality of every subsequent decision that depends on them.

The one-way vs. two-way door triage

Before building a decision log, it is worth establishing a triage framework. Not every decision warrants the same documentation overhead. Jeff Bezos introduced the one-way/two-way door metaphor in Amazon's 2015 shareholder letter, and it remains the most practical filter for operators deciding what deserves full documentation.

One-way door decisions are largely irreversible. Walking through them and walking back is either impossible or extremely costly. These include pricing model changes, acquisitions, entering or exiting a market, major org restructuring, key executive hires, and any commitment that creates a contractual or legal obligation. These decisions warrant the full log treatment: complete fields, named approver, documented dissent if applicable, and a scheduled retrospective review.

Two-way door decisions can be undone. Piloting a new tool, testing a process change, running a pricing experiment, or restructuring a team meeting cadence are all reversible at low cost. These still belong in the log — so the organization knows what was tried and what was learned — but they can be captured in a shorter format without a formal approval chain.

The practical rule: if a new COO or senior operator joining your team in six months would need to understand why a decision was made to do their job effectively, it belongs in the log. If the answer to that question is "they'd figure it out in a week," a brief note is sufficient.

Decision log roles: DACI, not RACI

Most teams default to RACI when they think about accountability frameworks. RACI is the right tool for mapping task execution — who does the work, who owns delivery, who gets consulted during execution, who gets the status update. It is the wrong tool for decision logs, where the question is not "who is responsible for completing this task" but "who has authority to make this call."

DACI — Driver, Approver, Contributor, Informed — maps decision authority, not task ownership. Each role means something specific:

The most important discipline in DACI is that there is exactly one Approver. Teams that list multiple approvers have not made a decision — they have created a committee. Committees produce either consensus (slow) or the appearance of consensus with unresolved dissent underneath. Neither produces good outcomes at the speed operators need to move.

Core decision log fields

Every decision log entry — regardless of type — should capture the same eight core fields. Optional fields can be added for specific decision categories. If your log has more than twelve fields, it will not get filled out consistently.

Template 1: Strategic decision log entry

Strategic decisions involve material resource allocation, market positioning, org design, or product direction. They are typically one-way door decisions with a 60–180 day impact horizon. The full template applies.

Template 2: Operational decision log entry

Operational decisions govern process design, vendor selection, team structure, and resource allocation within an existing strategic direction. They tend to have shorter impact horizons (30–60 days) and may be two-way door decisions, but they still need documentation to prevent process drift and enable retrospectives.

Template 3: Technical decision log entry (ADR format)

Architecture Decision Records follow a lighter format adapted from Michael Nygard's original template. They are stored alongside the code or system they describe — in a docs/decisions/ folder in the relevant repository. ADRs are append-only: when a decision changes, a new ADR supersedes the old one rather than overwriting it. This preserves the history of architectural reasoning even as the system evolves.

Decision log retrospective: closing the loop

A decision log without retrospective reviews is a repository of intentions, not a learning system. The review date field on every entry exists for one purpose: to force the question of whether the reasoning was correct, not just whether the decision was executed.

At the review date, return to the original entry and fill in the Actual Outcome field with three things: what actually happened, what the variance was from the expected outcome, and why. The "why" is the only part most teams skip — and it is the only part that improves the next decision.

Retrospective review format

The four possible outcomes of a retrospective are more instructive than most teams realize. A correct decision that produced the expected outcome validates the reasoning process. A correct decision that underperformed indicates flawed implementation, not flawed reasoning. A flawed decision that worked anyway points to luck or unmeasured variables — neither of which should generate false confidence. A flawed decision that failed is the most valuable: it shows exactly where the reasoning broke down.

Where to store your decision log

Format matters less than consistency and discoverability. The log that gets used is the one that lives where decisions already get made — alongside the documents, tools, and systems that prompted the decision in the first place.

Notion or Confluence (recommended for operators)

A single database with the core fields as properties allows filtering by category, owner, date, and status. Every entry is a page, so the context and options fields can be as long as needed without cluttering the index view. Tag decisions with the relevant team or initiative for cross-referencing. This is the right format for strategic and operational decisions where prose context matters.

Git repository (recommended for technical decisions)

ADRs belong in docs/decisions/ inside the relevant repository, versioned alongside the code they describe. When the code changes, the decision record is visible in the same pull request review. This is what makes ADRs actually useful — the reasoning is present at the moment someone is about to change the system it describes.

Spreadsheet (acceptable for small teams)

A shared Google Sheet with one row per decision works for teams making fewer than five logged decisions per month. Add a tab for retrospectives. The limitation is that context fields become cramped and the document does not scale past ~100 entries. Migrate to a proper database before it becomes unmanageable.

Common implementation failures

Logging decisions after they have already been made from memory

The value of a decision log degrades sharply with time. A decision logged a week after the fact has lost the specific reasoning, the options that were genuinely on the table, and the data that was actually cited. The log becomes a post-hoc rationalization rather than a faithful record. Entries should be drafted at the point of decision — even if cleaned up slightly before filing.

Listing every meeting discussion as a decision

Over-logging is as damaging as under-logging. If the log contains 200 entries after three months, most of them trivial, the signal-to-noise ratio falls below the threshold where anyone bothers to search it. Apply the triage framework: log decisions that set precedents, commit resources, or define constraints for future decisions. Everything else is operational execution that belongs in a task tracker, not a decision log.

Using team names instead of named individuals

"Engineering approved" or "the leadership team decided" are not accountable entries. Accountability requires a named individual. When accountability is diffuse, it is effectively absent. Every entry must have a named Approver — a specific person who can be asked at the retrospective whether the decision achieved what they expected.

Skipping the retrospective

A log of decisions with no retrospective completion is a document of good intentions. Review dates that pass without entries become evidence that the organization does not hold itself to account on outcomes. The retrospective loop is what separates a decision log from an archive.