Why Your Team Keeps Making the Same Decision Twice (And How to Stop It)

May 5

Comparison of ADR, DACI, RFC and RACI decision frameworks

The decision was made in a sprint planning session. Engineering built to it. The feature shipped.

Six months later, a new engineer reviews the system and asks why it was built this way. No one in the room has a complete answer. The original participants have moved on, the thread is buried in message history, and the reasoning behind the decision was never recorded in a usable form.

The discussion reopens.

This is not a failure of the original decision. It is a structural failure of institutional memory.

The team did not make a bad call. They made a call without preserving the context that made it defensible. When that context disappears, even correct decisions become vulnerable to being questioned, reversed, or rebuilt.

The Real Problem Is Not Decision Quality

Most teams interpret repeated decisions as a sign of poor judgment.

They are not.

They are a sign that the organization has no system for preserving decision context.

A decision that is not recorded in a structured way does not persist. It degrades into partial memory, fragmented notes, and disconnected conversations. Over time, the outcome remains, but the reasoning disappears.

At that point, the organization is no longer operating on decisions. It is operating on artifacts of decisions.

This is why teams that appear aligned still revisit the same questions. The alignment existed in the moment, but it was never converted into something durable.

How Teams End Up Making the Same Decision Twice

The pattern is consistent across teams.

A decision is made under a specific set of constraints. Those constraints are not captured in a structured way. Over time, the people involved move on, and the context disappears.

What remains is the outcome.

When that outcome is encountered again, it appears arbitrary. A new team, or even the same team under different conditions, revisits the decision without access to the original reasoning. The same trade-offs are evaluated again, often leading to the same conclusion, or a different one based on incomplete information.

This is not iteration.

It is rework.

Without a system for preserving decision context, the organization is forced to reconstruct its own thinking repeatedly. Each reconstruction consumes time, creates friction, and introduces inconsistency in how decisions are applied.

What Is a Decision Log?

Most teams already have a way of making decisions. What they lack is a way to make those decisions persist.

A decision log is not a list of outcomes. It is a structured record of the context in which a decision was made.

It captures:

The problem that required a decision
The alternatives that were considered
The constraints that shaped the trade-offs
The person responsible for the decision
The expected outcome at the time

Without this structure, decisions exist only in meetings, messages, and informal notes. Over time, they disappear.

When that happens, teams are forced to rely on memory. Memory is incomplete, biased, and unstable under change. As the organization evolves, the gap between what was decided and why it was decided continues to widen.

A well-maintained decision log creates a shared system of record. It allows teams to revisit decisions with full context, rather than reconstructing them from fragments.

Decision Frameworks Exist to Preserve Context

Decision frameworks are often presented as tools for improving decision quality.

Their primary value is different.

They provide a consistent structure for capturing decisions so that they remain interpretable over time.

Most teams already make reasonable decisions. What they lack is a way to preserve the reasoning behind them.

Without a framework, a decision log becomes a list of conclusions. With a framework, it becomes a record of judgment.

Each framework addresses a different failure mode.

Which Decision Framework Should You Use?

The framework that fits a team depends on the situation in which decisions are being made, not on familiarity or convention. Different environments produce different failure modes, and each framework addresses a specific one.

ADR: For Technical Decisions That Get Revisited

Engineering teams operate in systems where decisions accumulate.

Architecture choices made early can shape the system long after the original context has changed. When those decisions are not documented, the question “why is this structured this way” resurfaces in conversations where no one present was involved in the original call.

Architecture Decision Records (ADR) address this directly. They document the decision, the context, and the known consequences in a lightweight format that lives close to the codebase.

Their strength is persistence. Their limitation is that they do not explicitly define ownership roles, which matters in cross-functional decisions.

DACI: For Decisions With Unclear Ownership

In cross-functional teams, the primary failure mode is not lack of information. It is lack of clarity about who decides.

Product, engineering, and design all contribute input, but without a clear decision-maker, the process either stalls or resolves through informal influence.

DACI introduces structure by assigning roles:

Driver: runs the process and maintains momentum
Approver: holds final decision authority
Contributors: provide input before the decision is made
Informed: notified of the outcome

The critical element is the single Approver. It removes ambiguity and allows decisions to move forward without requiring consensus.

DACI ensures decisions are made with clarity. It does not capture the full reasoning behind them. That requires a decision log.

RFC: For Async and Distributed Teams

In distributed environments, decisions often emerge from ongoing discussions rather than discrete meetings.

Threads evolve, feedback accumulates, and conclusions are reached without a clear point of resolution. This makes it difficult for others to understand what was decided and why.

Request for Comments (RFC) provides a structure for this environment. A proposal is written, feedback is collected over time, and the final decision is documented as part of the process.

Unlike ADR, which documents decisions after the fact, RFC structures the decision-making process itself. It is most effective when alignment cannot rely on synchronous interaction.

RACI: For Governance, Scale, and Accountability

As organizations grow, decisions involve multiple teams and carry broader implications.

In these contexts, accountability becomes critical.

RACI introduces a distinction between execution and accountability:

Responsible: executes the work
Accountable: owns the outcome
Consulted: provides input
Informed: receives updates

The separation between Responsible and Accountable becomes necessary at scale. It enables governance, auditability, and clarity across teams.

RACI is structurally heavier and not suited for teams optimizing for speed. Its value emerges when decisions must be defensible beyond the immediate team.

What a Decision Log Actually Needs to Contain

Regardless of which framework a team uses, the decision log itself has consistent requirements. A decision documented without these five elements will get reopened, because the log will contain a conclusion without the context that makes it defensible.

Problem context. What prompted the decision — the constraint, the tradeoff, the customer signal, the architectural pressure that existed at the time. Not what was decided, but why the decision needed to be made at all. Without this, the conclusion looks arbitrary to anyone who was not present.
Alternatives considered. What other options were evaluated, even briefly. A decision with no documented alternatives cannot be assessed in retrospect. When circumstances change and the decision is revisited, the absence of alternative documentation means the original reasoning cannot be tested against new information.
Decision ownership. Who made the call and in what role — not just who was in the meeting, but who held approval authority. This is what makes a log useful for governance review and for establishing accountability when outcomes diverge from expectations.
Expected outcome. What would have to be true for this to have been the right call. This is the commitment the decision-maker made at the time. It creates a testable standard against which later outcomes can be measured.
Actual result. What actually happened — filled in after enough time has passed to evaluate. This is the most commonly skipped element and the most valuable. A log without outcome data is a record of intent, not a record of judgment. It is also where institutional memory compounds: a team that tracks outcomes builds pattern recognition about which decision types it calls correctly and which it consistently misreads.

Which Framework Fits Your Situation

The four frameworks cover different territory. They are not interchangeable, and selecting by familiarity rather than fit produces process overhead without the corresponding benefit.

Framework	Best For	Ownership Clarity	Async-Friendly	Governance Fit	Template
ADR Architecture Decision Records	Engineering teams revisiting technical choices; version-controlled codebases	Implicit — tied to who submitted the ADR	✓ High — lives in the repo, asynchronous by design	Low — no formal approval role	Coming soon
DACI Driver · Approver · Contributors · Informed	Cross-functional teams with unclear decision ownership; speed-priority environments	✓ High — Approver role is explicit	✓ Moderate — roles can be assigned async	Moderate — suited to team and product-level decisions	Coming soon
RFC Request for Comments	Distributed or async-first teams; proposals requiring broad input before resolution	✓ High — resolution role documented in the record	✓ High — structured for async review and comment	Moderate — audit trail exists, no formal approver tier	Coming soon
RACI Responsible · Accountable · Consulted · Informed	Large organizations, regulated environments, cross-departmental initiatives	✓ Highest — separates Responsible from Accountable	Low — typically requires synchronous alignment to resolve roles	✓ High — built for auditability and executive visibility	Coming soon

rodriguezjimmy.com

The "Template" column reflects what is currently available on the Resources page. Decision log templates for each of these frameworks are in development for the Notion marketplace and will be listed as they publish.

The Mistake That Makes Every Framework Stop Working

Teams implement the framework without implementing the habit.

A DACI template in Notion is not a decision-making system. It is a tool that produces value only if it is used before decisions are made, not after. Two failure modes appear consistently in practice.

Retrospective documentation

The team records decisions after they are made, often after the outcome is already visible. This strips out the uncertainty and the alternatives that make a decision log useful. A log written after the fact is a narrative: it describes what happened in a way that makes the outcome appear more deliberate than it was. The reasoning is reconstructed rather than captured.

Selective adoption

The framework gets used for large, visible decisions but abandoned for smaller ones. The log becomes a collection of the team's most significant choices, with nothing in between. Institutional memory does not accumulate from quarterly decisions alone. It accumulates from the pattern of decisions made under similar constraints, which requires consistent documentation of decisions that seemed routine at the time.

Both failure modes share a structural cause: the framework was adopted without being integrated into an existing workflow. The same dynamic appears in OKR adoption. As how to set goals that actually drive decisions covers, the goal-setting infrastructure that makes OKRs actionable requires an architectural commitment to usage, not just a template that is available to use.

The practical correction is narrower than it sounds. Pick the most common recurring decision the team makes, and commit to using the framework for that type for 30 days before expanding. The habit forms on one decision type before the system is extended, which prevents the framework from being adopted at scale and abandoned at scale simultaneously.

When Not to Use a Framework

Not every decision warrants documentation.

Amazon's Type 1 / Type 2 distinction is useful here not as a documentation framework but as a filter. Type 2 decisions are reversible and low-risk. They can be made and corrected within a sprint. Applying DACI or RFC to a product decision that can be undone in two weeks creates governance overhead without the corresponding value. The documentation burden should be proportional to the cost of being wrong.

Type 1 decisions are irreversible or difficult to reverse: pricing changes, architectural commitments, vendor contracts, team structure. Irreversible bets require documentation, review at the director or leadership level, and governance appropriate to the stakes involved. These are the decisions that warrant a framework.

The filter is not about decision size. It is about reversibility. A small decision with permanent consequences deserves more documentation than a large initiative that can be course-corrected after the next sprint review.

Decision Log Templates

If you want to apply these concepts in practice, the starting point is a structured decision log.

A well-designed template reduces the friction of documentation and increases the likelihood that decisions are captured at the moment they are made, rather than reconstructed later. It provides a consistent format that aligns with the frameworks described above while remaining flexible enough to adapt to different team contexts.

A free Team Decision Log template is available to help teams capture context, ownership, and outcomes in a single system. Framework-specific templates for ADR, DACI, RFC, and RACI are in development and extend this structure to match each use case.

Jimmy Rodriguez https://www.rodriguezjimmy.com