One framework per decision type

The idea

Create a specific framework for each recurring decision type.

You have been sold a single model for making decisions. Gather information, list options, weigh pros and cons, choose the best one. It shows up in business school curricula, self-help books, and corporate training decks. It sounds reasonable. It is also wrong — not because it never works, but because it treats all decisions as the same kind of problem.

They are not.

An example

You use the same agonizing deliberation for choosing a database as you do for choosing lunch. One decision shapes your architecture for years. The other is reversed by walking to a different restaurant tomorrow. When you apply a single generic process to both, you either over-invest in trivial choices or under-invest in consequential ones. The fix: build a specific framework for each type of decision you encounter repeatedly, so the right level of rigor activates automatically.

Where it goes wrong

Building one master decision framework and applying it to everything. This is the 'man with a hammer' error Munger warned about. You will either slow to a crawl on low-stakes decisions or dangerously simplify high-stakes ones. The failure feels like productivity — you have 'a system' — but the system ignores the structure of what it is processing.

Make it stick

Maintain a decision framework library — a living document or folder where each recurring decision type has its own page. Include: decision type, typical stakes, criteria that matter, process steps, time budget, and historical outcomes. Before any significant decision, check the library first. If no framework exists for this type, that is your signal to build one.