Who should be making this decision
Categorize decisions like a backlog, then set the policy per category before the next one arrives.
Every decision carries a cost attached to its timing, not just its content. Every time someone escalates instead of deciding, that escalation costs real value, because the time lost waiting is value the company does not get back. Don Reinertsen makes the case in The Principles of Product Development Flow: a decision only deserves to move up the chain if what it is worth is bigger than what the delay costs.
Decisions lose value in the other direction too. An architecture or technology choice locked in before anyone needed to lock it in is just as expensive as one that waited too long.
The fix is not making every decision faster. It is categorizing decisions the way you would categorize a backlog, then building a real policy around each category: who decides, who gets consulted, what it is worth, and how expensive the delay is if it waits.
What you get
- A policy table with a row per decision category
- The illustrative version, and why the rows are an example rather than a prescription
- The two failures this prevents, escalating something cheap and locking something in early
- A prompt for checking whether the policy is actually being used
Where should we send it?
One email with the worksheet. You can unsubscribe from anything else in one click.
On its way
Check your inbox. If it has not landed in a minute or two, look in promotions or spam, and add sam@startuppatterns.com to your contacts so the rest arrive.
Adapted from the Leadership chapter of The Mindful Product Company by Sam McAfee.