How I Solve Problems
Clarity first, truth always, foresight before speed.
Philosophy
My problem-solving approach is grounded in systems thinking and influenced by The Great Mental Models and Shane Parrish's Clear Thinking (see especially chapter 4). I aim for clarity first, truth always, and foresight before speed—so we solve the problem at hand and build habits that prevent similar ones from returning. This ties directly to how I lead: mental models, second-order effects, and designing guardrails before issues arise.
Problem-Solving Process
I begin by asking "What could go wrong?" That question helps me understand a system's failure modes early so I can design guardrails before issues arise. It's preventive thinking—building resilience into the system and the team.
When a problem surfaces, I define it by clarifying:
- What outcome are we actually trying to achieve?
- What obstacles are preventing that outcome?
Only when these are clear do I move to solutions.
I then ask "What would have to be true for this problem not to exist in the first place?"—a root-cause lens that forces us to imagine success and work backward to discover what the system is missing.
I live by Admiral James Stockdale's lesson:
"You must never confuse faith that you will prevail in the end with the discipline to confront the most brutal facts of your current reality."
That helps me keep a clear head—facing hard truths while maintaining confidence in our ability to fix them.
I balance short-term fixes with long-term solutions using two questions:
- First level: "How do we stop the pain today?"
- Second level: "And then what?"—which tests whether today's solution creates tomorrow's problem.
Example: SQL Server Performance Spikes
A real example of this approach was recurring SQL Server CPU and memory spikes during production. The incidents looked random until I asked "What could go wrong with our data access layer?" and mapped how ORM-generated queries interacted with real-world data volumes.
We found that developers had relied on ORM autogenerated queries that were fast on local datasets but scaled poorly in production—first-level thinking that neglected Big O implications like O(n²) joins and unindexed lookups.
I reframed the problem:
- Desired outcome: stable database performance under realistic load.
- Obstacle: query inefficiencies from ORM abstraction and lack of scalability awareness.
- What would have to be true for this not to exist? Developers would need visibility into how ORM queries translate to SQL and how they perform at production scale.
From there we took tactical and strategic action:
- Added query performance monitoring and alerting to catch regressions early.
- Created reproducible staging datasets to simulate production size.
- Ran short training sessions on SQL query plans, indices, and Big O in ORM contexts.
We mitigated the immediate spikes quickly; the bigger win was second-level thinking—shifting the team's mental model around performance so they design with scale in mind.
How This Shows Up in My Work and Leadership
- Architecture and planning: I push explicit assumptions, pre-mortems, and simple decision rules so we avoid thrashing and see second-order effects.
- Crisis and incidents: I focus on clarity and root cause before jumping to fixes—aligned with "define the problem" and "what would have to be true?"
- Team development: I share these mental models so engineers think more critically and anticipate failure modes early.
What You Can Expect From Me
When we're solving a hard problem together, you can expect me to insist on clarity of outcome and obstacles before solutions, to ask "and then what?" before locking in an approach, and to balance stopping the pain today with not creating tomorrow's problem.
This approach draws on Clear Thinking, chapter 4, by Shane Parrish (Penguin, 2023).