Decision-Making Frameworks

Decisions waiting for you is one of the most common bottlenecks in any operation. And it’s one of the most solvable.

Most decisions that pile up on your desk aren’t genuinely complex. They’re routine choices that someone else could make if they had clear criteria and permission. The problem isn’t the decision. It’s the absence of a framework.

What a Decision Framework Does

A decision framework answers three questions:

1. Who has authority to decide?
2. What criteria should guide the decision?
3. When does the decision need to escalate?

With those three answers, most decisions happen at the point of action instead of floating up to you. The person closest to the situation — who usually has the most context — makes the call using clear criteria. Only genuinely unusual or high-stakes situations reach you.

Designing the Framework

Step 1: Identify Recurring Decisions

Not every decision needs a framework. One-time, high-stakes, novel decisions should probably involve you. But recurring decisions — the ones that come up repeatedly in similar form — are perfect candidates.

Look at the decisions that regularly wait for you:

• Customer requests that need approval
• Spending decisions under a certain amount
• Quality judgment calls
• Process exceptions
• Priority conflicts between competing demands
• Scheduling and resource allocation

These aren’t unique situations. They’re pattern-based. And patterns can be codified.

Step 2: Define the Criteria

For each type of recurring decision, what criteria should guide it? What would you consider if you were making the call?

Write it down in if-then format:

• “If the customer refund is under fifty dollars, process immediately.”
• “If a deadline conflicts with quality, prioritize quality and communicate the timeline change.”
• “If spending is under five hundred dollars and within the approved category, authorize without escalation.”
• “If a new opportunity requires less than ten hours of investment, the person who identified it can pursue it.”

These criteria don’t need to cover every possible scenario. They need to cover the common ones. The exceptions are what escalation is for.

Step 3: Define Escalation

Escalation is the safety net. When the criteria don’t apply, when the situation is unusual, when the stakes are too high for autonomous decision-making — the decision goes up.

Good escalation rules are specific about:

• What triggers escalation (dollar amounts, risk levels, novelty)
• Who it escalates to (not always you — could be a peer or a specialist)
• How fast it needs to happen (urgent vs. next check-in)
• What information should accompany the escalation

Bad escalation rules are “when in doubt, ask me.” That’s not a rule. That’s a backdoor to you remaining the bottleneck for everything ambiguous. “When in doubt” is always in doubt.

Better: “Escalate when the decision involves commitments over five thousand dollars, could affect a customer relationship we’ve identified as strategic, or involves a situation we haven’t encountered before.”

Step 4: Document and Share

A framework that lives in your head is just you. A framework that’s documented and shared is a system.

Write it up. Share it with everyone who makes decisions. Walk through examples. Make sure they understand not just the rules but the reasoning. When people understand WHY the criteria are what they are, they make better calls on the edge cases.

The Trust Factor

Delegating decisions requires trust. And trust is built through experience, not through faith.

Start with low-stakes decisions. Let people make calls where the downside of a wrong decision is small. As they demonstrate judgment, expand the scope. Move the escalation threshold outward as trust grows.

This isn’t “trust them or don’t.” It’s a calibrated expansion of authority based on demonstrated capability. Like gradually loosening the reins as a horse proves it can run true.

Decision Documentation

One often-missed piece: document the decisions that get made. Not so you can second-guess them. So everyone can learn from the pattern.

When someone makes a decision using the framework, note what they decided and why. Over time, this creates a case library that informs future decisions. “Last time we had a similar situation, here’s what we did and here’s what happened.”

This turns individual decisions into organizational learning. The operation gets smarter with every call.

Today’s Practice

Build one decision framework for your operation.

1. List recurring decisions that currently wait for you. Pick the ones that come up most often.
2. For the most frequent decision type: What criteria should guide it? Write them in if-then format.
3. Define escalation: What situations go beyond the criteria? Who do they escalate to? How urgently?
4. Document the framework. Clear enough that someone can use it without asking you to explain.
5. Share it. Walk through it with the relevant people. Use real examples to illustrate how the criteria apply.

One framework. Covering one type of recurring decision. Test it for a week. See what happens when decisions get made without your direct involvement. Adjust the criteria based on results.

Then build the next one. And the next. Each framework you create removes one more bottleneck from your operation.