The most common mistake in action is jumping from a problem directly to a proposed solution in a nanosecond — without spending the hours required to properly diagnose and design a solution. Dalio calls this the primary source of bad decisions that don't actually address the problem. ## The Anti-Pattern "It is a very common mistake for people to move directly from identifying a tough problem to a proposed solution in a nanosecond without spending the hours required to properly diagnose and design a solution. This typically yields bad decisions that don't alleviate the problem. Diagnosing and designing are what spark strategic thinking." The urgency bias that drives this: jumping to solutions feels like action. It relieves the discomfort of uncertainty. But it's false action — it consumes resources on the wrong problem. ## The Discipline: Thinking as Action Dalio: "Don't act before thinking. Take the time to come up with a game plan. Take at least a few hours to think through your plan. Those hours will be virtually nothing in relation to the amount of time that will be spent doing, and they will make the doing radically more effective." Thinking is not a delay before action — it is a form of action. "The action of thinking" — thinking as active, deliberate, intentional, coordinated process. ## Planning Questions Framework Before committing to any significant campaign: - What am I trying to achieve here? - Why am I trying to achieve it? - How will I know I'm successful? - When do I want this complete? - Time and budget estimate? - Most likely pitfalls? - Key advantages to build early? - What scares me most / would make me unlikely to finish? - Track record at similar things? - Checkpoints and allies? - Conditions under which I'd abandon this plan? - How much effort before reviewing/changing? ## Cross-Domain Applications **Software architecture**: The pull request that changes the database schema without diagnosing the query bottleneck first. Symptoms → immediate fix → root cause untouched. **Client work**: Proposing a Rails upgrade before auditing what's actually breaking. The diagnosis (what's causing the pain?) must precede the design (how do we fix it?). **Product**: Building features because a user complained once, without diagnosing whether the complaint represents a pattern or an edge case. **Personal habits**: Installing a new productivity system before diagnosing why the previous one failed. Fixing the symptom (no system) rather than the cause (wrong task selection, poor energy management). ## Related Concepts - [[Deliberateness as Anti-Chance Strategy]] — the broader principle; diagnosis-design is its application to problem-solving - [[Operational Base Readiness]] — precondition check that also belongs before action - [[Reflective Control]] — the state required to actually think through diagnosis without autopilot taking over - [[Simple Disciplined Thinking]] — related discipline in the Decision Making topic ## Source Sebastian Marshall, *Gateless*, "The Cognitive Lever" — via [[Conative Knowledge]] --- *Created: 2026-04-10*