Run Five Questions Before You Lock In or Defer a Decision

This is the full playbook from “Know Which Decisions to Make Early and Which to Delay.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Use the Decision Classification Worksheet the next time someone says “let’s keep our options open” or “we need to lock this down now.” Don’t accept either instinct. Run the decision through five questions first.

1. Map the dependencies. Count the components, teams, and downstream decisions that depend on this one, and name them. Not “a lot” or “not many.” A short, specific list means a late-binding candidate. A list that’s hard to finish, because the decision touches almost everything, means early-binding, whatever the room feels.
2. Price the reversal. If this decision is wrong, what does changing it cost in six months, and what does it cost in eighteen? Flat cost means you can defer. Sharply growing cost means bind early. The cost grows as more work gets built on the decision and more teams depend on it. That curve tells you to decide even without full confidence in the choice.
3. Identify what you’re waiting for. Name the specific information, customer signal, or business alignment the decision waits on, and give a date or a trigger event by which that input must exist. If you can’t name the input, you’re not late-binding. You’re avoiding the decision.
4. Assign the owner and the trigger. Every genuine late-binding decision needs one named person who makes the call when the trigger fires, plus a calendar reminder or milestone that surfaces it again. Don’t rely on memory. A late-binding decision with no owner and no trigger gets made by default, usually badly, at the worst moment, by whoever is in the room when the cost comes due.
5. Check the execution cost as well as the decision cost. How long does the work take once the decision is made? If that window is much shorter than it was, use the new number in Step 2. A decision that needed early commitment only because the work was slow may not need it now. Check that against the dependency map from Step 1: faster execution doesn’t shorten a dependency chain, only the cost of the work sitting on top of it.

Try this with AI.

“I’m about to argue that we have to decide this now. Pressure-test me. What information arrives in the next six weeks that I’d be throwing away, and what would it actually cost to hold the option open until then?”

Run every meaningful architecture, infrastructure, or product decision through these five steps. After a few cycles the debate in the room changes. It stops being “should we decide now or wait,” which mostly measures who is least comfortable with ambiguity, and becomes “what are we waiting for, and who makes sure we don’t wait past it.” That’s how you confirm the flexibility you claim buys you something, instead of giving indecision a better name.

All of the playbooks are listed on the playbooks page.