Decision-Making System

The problem

Decisions went up the org chart by default. Capable people escalated calls they should have owned, because nobody had written down which calls were theirs. Then the decisions that did get made disappeared into meetings. Months later nobody could say who decided, on what evidence, or whether it worked. Nobody wrote down what a decision was supposed to achieve, so nobody went back to check, and bets that weren't working kept running.

The solution

A decision system in three parts. First, a decision-rights map, which I helped a cross-functional working group shape: for each recurring type of decision, who owns it, the guardrails they decide within, and the specific triggers that send it up a level. Reversible decisions get pushed down to whoever is closest to the customer, and the executive team keeps the irreversible ones. Second, a standard way to make the decisions that matter: classify the door (one-way or two-way), score the options against weighted criteria, rate the risk, write down the hypothesis, and set the date the decision will be reviewed. Third, a decision ledger. Every decision becomes one structured record with an owner, rationale, risk, and a review date. Claude extracts decisions from meeting notes and threads, and a scheduled review grades each one against what actually happened and calls the next move: keep, scale, pivot, or stop.

How it works

1. Rights before process. Each decision type maps to an owner level, a short list of guardrails, and named escalation triggers, such as three or more teams affected, more than one VP's remit, or spend above a set threshold. Inside the guardrails, the owner decides and consults up for context, not approval.
2. Size the door first. Two-way-door decisions move fast with one owner at 70–80% confidence. One-way-door decisions get the full treatment: options scored against criteria whose weights add to 100, a likelihood-by-severity risk grid, and a round of votes where everyone explains theirs before the owner decides.
3. Write it down at decision time. The record captures the decision, the owner, who aligned, the door type, the risk, the hypothesis ("if we do X, we expect Y by Z"), the threshold that would stop it, and a pre-set review date. Accountability attaches to the reasoning, not only the result.
4. Capture without asking. Claude reads meeting notes and team-chat threads, pulls out decisions, checks them against existing records so nothing gets logged twice, and writes them in the same schema. Every write is validated, so a malformed record never reaches the ledger.
5. Grade on a schedule, then act. When a review date arrives, a scheduled review grades each decision against the evidence that has built up since and gives it a next move: keep, scale, pivot, or stop. Stopping a bet that missed its own threshold counts as the system working.

The results

• Decision rights went from "ask your VP" to a written map with owners, guardrails, and escalation triggers for the company's recurring calls. One early test of the pattern moved ownership of a release phase down to product directors.
• More than a hundred decisions recorded with an owner, a rationale, and a review date, in one format that has outlasted two rebuilds of the automation around it.
• Reviews end in a call, not a status update. Every decision comes back on its date as keep, scale, pivot, or stop, measured against the threshold its owner set up front.
• The lesson I took into the rebuild: extracting decisions is the easy part. The value is in the review loop (a date, a threshold, a next move), which runs on a schedule and fails loudly.