Decision Records

Good decisions require clear thinking. Clear thinking requires structure. But structure without flexibility becomes bureaucracy.

A decision record is a tool to think through problems and solutions systematically—not a bureaucratic requirement. Use it when it helps. Skip it when it doesn't.

When to Use Decision Records

Use them for:

• Type A decisions (hard to reverse)
• Problems affecting multiple people or systems
• Decisions that need shared context
• Anything you'll need to explain later
• When you want feedback before committing

Don't use them for:

• Obvious or trivial decisions
• Urgent situations requiring immediate action
• Decisions you can test in an hour
• Your own small, reversible experiments

Scale the depth to match the decision type. A Type B decision might need 30 minutes and half a page. A Type A decision might need a week and deeper analysis.

The Basic Format

1. Problem Stack

How does this connect to our mission?

Map the problem upward:

• Ultimate goal/mission
• ↓ Strategic priority
• ↓ Key result or objective
• ↓ This specific problem

If you can't draw this line, question whether this is actually important.

2. Problem Description

What is the problem, why is it a problem, and why now?

Be specific:

• What's happening (or not happening)?
• Who is affected and how?
• What's the impact if unsolved?
• Why is this a problem now? Or is it just something to monitor?

If it's something to watch rather than solve immediately, say so. Not every problem needs immediate action.

3. Supporting Data

What evidence shows this is a problem?

Bring the data:

• Metrics, numbers, observations
• User feedback, system logs, incidents
• Trends over time
• What triggered awareness of this problem?

If you don't have data, say so—and note that as part of the problem. Sometimes "we don't have visibility" is the real issue.

4. Solution Hypothesis

What's the North Star for solving this?

State your best guess for how this should be solved:

• The ideal solution (even if not feasible right now)
• A directional hypothesis to explore
• An entry point for discovery

This doesn't have to be right. It's a starting point for discussion. Even "I don't know, but here's where I'd start looking" is valid.

5. Options

What are the possible ways to solve this?

List the options you can think of:

• Known solutions from other teams or companies
• Ideas worth exploring
• Quick hacks vs. proper solutions
• Doing nothing (always an option)

Early stage: These can be rough guesses. Get feedback before investing weeks in detailed specs.

Iterate tangibly. Share rough ideas, sketches, or prototypes early. Don't disappear into an ivory tower for 10 weeks. Discovery is about exploration, not perfection.

6. Observation & Monitoring

How do we know if the solution actually works?

Define upfront:

• What metrics indicate success?
• How will we observe effectiveness?
• What does "problem solved" look like?
• What might break or regress?

This should be solution-agnostic where possible. No matter which option you pick, you need to know if it worked.

7. Triggers & Acceptance Criteria

When do we revisit this? When is it solved?

Set clear triggers:

• When to check if the solution is working
• When to re-evaluate the approach
• When the problem is considered solved
• When to declare it "no longer a problem"

Don't let decisions drift into eternity. Know when you're done.

8. Decision Matrix

How do we compare options objectively?

Create a simple comparison framework:

Important: Decision matrices are tools for guidance, not absolute truth. They help you think and compare—they're not canon. Use them to structure discussion, not to avoid judgment.

Always consider:

• Build cost — time and resources to implement
• Maintenance cost — ongoing operational burden
• Reversal cost — what if we need to change later?

9. Recommended Decision

What's your best guess for the winning option?

Pick one. Always propose a specific recommendation.

Even if you're uncertain, make your best guess. This gives everyone a concrete discussion point. You're not declaring the final answer—you're starting the conversation with a clear position.

Don't be scared to be wrong. The point is to have a plan to discuss, not to have already made the perfect choice.

The DRI Principle

One person is the Directly Responsible Individual (DRI).

The DRI:

• Owns the decision
• Gathers input and feedback
• Makes the final call
• Can be overridden only in rare, critical cases

Everyone else: Listen → Challenge → Commit

• Listen to understand
• Challenge with better ideas or concerns
• Commit once the decision is made

The DRI is not a dictator, but they break ties. Consensus is great; paralysis is not.

Scale Appropriately

This is a tool, not a religion.

The depth of your decision record should match:

• Type A decision? → Deep analysis, multiple perspectives, thorough documentation
• Type B decision? → Quick writeup, fast feedback, move on

Don't create bureaucracy. Don't slow down reversible decisions. Don't write a 10-page document for something you can test in a day.

Effectiveness is the measure of truth. If this process helps you make better decisions faster, use it. If it's slowing you down without adding value, adjust it.

The Questions to Always Ask

"Does this decision warrant a record?" "Am I scaling this appropriately?" "Who's the DRI?" "Do I have enough to start a discussion?"

Don't overthink the format. The structure exists to help you think clearly and share context efficiently. Use what helps. Skip what doesn't.

Your goal isn't perfect documentation. It's effective decisions that stick, with shared understanding of why—and the ability to revisit them when the world changes.

---

Once you have structure for thinking, decisions become clearer. But remember: the structure serves you. You don't serve the structure.

---

Christian Blank
San Francisco · Updated May 2026
christian@blank.dev | www.blank.dev
Co-written and formatted with AI