You make uncountably many decisions in the pursuit of day-to-day life and in pursuit of projects (both personal and interpersonal). Every big decision is made up of a never ending hierarchy of littler decisions that look at parts of it. If you're not careful, big decisions will be made unintentionally through the net effects of the thousands (or more) of tiny decisions in aggregate. It's impossible to holistically consider [[What is a Strategy|strategy]] in all decisions. Similarly, it's difficult to determine the effectivity of a path chosen through these uncountably many decisions on the performance of the [[What is a System|system]] as a whole. Both of those issues are resolved through the creation of good, unambiguous **big** choices that guide (or constrain) the many _little_ choices made along the way. This is the [[Pareto Principle]] in action. It gives you a smaller set of levers and knobs to consider when you're evaluating system (e.g. business) performance. A really good practice is to **make the decision that informs all subsequent decisions**, be that through the use of some sort of a [[Manifesto]], [[Mission Statement]], [[Enterprise Architecture]], and/or simply a couple of clearly-stated [[Guiding Principles]]. You need to be able to articulate to your future self (and/or to others) something that is easy to (1) **access**, (2) **interpret**, and (3) **apply**. Related: the decision that _constrains_ all future decisions. You can use [[Precommitment Device]]s to remove decisions from your future self. You can do things like set up automated investing. Unlike the rest of this note, these don’t have a “fixed ceiling” in number. Do as many as necessary. They won’t really water each other down. # Effectiveness If "the decision that drives the decisions" is hidden, too difficult to understand (too abstract or too vague), or not actionable, it won't influence subsequent decisions and may as well not exist. See also: [[Access, Interpret, & Apply]]. ## Access The decisions made need to be "a click away" pretty much all times. If you're in an office setting, post your guiding principles on the wall. If you're building a digital system, keep a link in the top-level menu. These should be highly discoverable. It's also possible (and perhaps preferable) to _bake-in_ decisions into [[Intermediate Packets]] like templates and [[Checklists]]. When possible, build the [[Pit of Success]]. ## Interpret The decisions made need to be stated plainly and clearly. They should [[Avoid Jargon]] and be written without need for context or specialized knowledge. Write them like you were [[Feynman Technique|Feynman]] explaining them to a child. **Limit the number**.[^1] Each one is diluted by all the others. Probably no more than 5. ## Apply The decisions needs to be generic enough to apply to significant portions of the system of interest,[^2] but specific enough to adequately constrain the set of choices available to the agent making them to those choices that align with it. This is a [[Balance|balancing]] act. # Simple Examples - In [[Notion]] - Everything is block. - In [[Obsidian]] - Everything stores in [[Markdown]] and other durable, open formats in a folder on the users computer - For Southwest Airlines - We don't have 'hubs', we fly point-to-point, for as cheap as possible - For my notes & blog - I will write for myself and not in pursuit of money/notoriety **** ## Source - Stringing together related notes ## Related - [[Mission Statement]] - [[Guiding Principles]] - [[Feynman Technique]] - [[Pit of Success]] [^1]: This doesn't really apply when you're making templates that you can co-locate with the work to be done. Go nuts there. Limiting the number of decisions only aids in the interpretation of those types of decisions you need to read and internalize. [^2]: Significant portions here could be in terms of _volume_ (i.e. lots of potential for use) or _importance_ (i.e. things that aren't hit on frequently, but are vital to align).