Making Decisions

A framework for navigating complex trade-offs and escalations.

When You Need This

Use this framework when:

A decision is a one-way door (hard to reverse)
Two teams disagree and need resolution
The trade-offs are complex and contested
You need leadership input to move forward

If you can easily reverse the decision later, just pick one and move. This framework is for the hard calls.

The Core Structure

Distill the debate to a single statement, options, and pros/cons:

We are debating whether to do X, Y, or Z.

Option A (Recommended by [Person/Team]):
[Brief description]
- Pros: ...
- Cons: ...

Option B (Recommended by [Person/Team]):
[Brief description]
- Pros: ...
- Cons: ...

Option C (Not recommended):
[Brief description]
- Pros: ...
- Cons: ...

Template

Decision: [One-sentence framing of the choice]

Context: Why is this decision needed now? What's the cost of delay?

One-way door? Yes/No. Can we reverse this easily if we're wrong?

Options:

Option	Description	Pros	Cons	Recommended by
A
B
C

Recommendation: [Your recommendation and why]

What we need: [Decision? Input? Escalation path?]

Principles

Represent all positions fairly

If two parties disagree, present both positions in the best possible light. This builds trust and often reveals the real crux of disagreement.

Lead with data

The debate should be grounded in evidence, not opinions. What data supports each option? What's missing?

Razor the debate

Simplifying the decision and its data-driven factors often illuminates the answer without escalation at all. If you can't state the trade-off simply, you don't understand it yet.

Explain why it's hard

If the decision were obvious, you wouldn't need this framework. Make explicit why reasonable people disagree.

Anti-Patterns

Straw-manning: presenting the other side weakly to make your recommendation look better
Kitchen sink: listing 7 options when there are really 2-3 viable ones
Hidden recommendation: burying your actual opinion; just state it clearly
Escalating too early: use this framework to clarify your own thinking first; sometimes that resolves it

One-Way vs. Two-Way Doors

One-Way Door	Two-Way Door
Hard or expensive to reverse	Easy to reverse
Requires careful analysis	Bias toward action
Get more input	Decide and iterate
Examples: architecture choices, public commitments, team restructures	Examples: UI copy, feature flags, most experiments

For two-way doors, don't over-invest in decision frameworks. Just try something.

The goal isn't to avoid decisions. It's to make them well when they matter, and make them fast when they don't.