Problem-Solving Methodology
Roy fixes the conditions that create problems, not just the problems themselves. Process:- Identify the actual problem (not the stated problem)
- Find root causes (not symptoms)
- Design a solution that prevents recurrence
- Build systems where the right action is the easiest action
- Validate with real users
Example: Precision Nutrition knowledge base
Stated problem: “We need better documentation.” Actual problem: Knowledge was fragmented across Google Docs, Slack threads, and people’s heads. Finding information usually involved first tracking down the person who would most likely know and then ask them. More documentation wouldn’t fix this without a system change. Solution: Built a centralized knowledge base with taxonomy, search optimization, and governance. Changed the capture process so documentation happened at creation time, not retroactively. Updates went to the knowledge base first, then Slack with links. Result: 20% reduction in support tickets. Faster onboarding. Information that stayed current.Frameworks
| Framework | Application |
|---|---|
| First principles | Question assumptions. Ask why until you hit bedrock. |
| Second-order thinking | If you solve this problem, what problem does that create? Design for consequences of consequences. |
| Inversion | Ask “what would make this fail?” and avoid those things. Easier to prevent failure than force success. |
| Feedback loops | Build mechanisms that surface problems early. Don’t wait for crises to learn what’s broken. |
Learning Approach
Roy learns by doing, failing, asking questions, and building mental models. He treats learning as a skill, not a trait. Process:- Identify what the problem requires
- Find best sources (docs, experts, direct experimentation)
- Build working understanding fast
- Test through application
- Refine based on what breaks
Example: Chialisp developer education
Chia Network needed developer education for Chialisp, a new programming language. Roy had no blockchain development or functional programming background. How he learned: Read existing technical docs. Wrote simple programs. Asked engineers when stuck. Taught what he learned to surface gaps in his own understanding. Identified disconnects between what engineers knew and what beginners needed. Goal: Not to become an expert. To become knowledgeable enough to design a progressive curriculum for beginners. Result: 9-part video series with 4 engineer SMEs. 46k+ views. Noticeable reduction in ad-hoc engineer support.Frameworks
| Framework | Application |
|---|---|
| Mental models | Learn principles, not just facts. Reusable thinking tools transfer across domains. |
| Analogical reasoning | Map new knowledge to existing knowledge. Note where the analogy breaks. |
| Progressive complexity | Start simple, layer incrementally. Don’t try to understand everything at once. |
| Teaching to learn | Explaining surfaces gaps. If you can’t explain it clearly, you don’t understand it. |
Design Philosophy
Roy designs for real humans: busy, distracted, and unlikely to read instructions. If a system requires perfect user behavior to work, the system is broken.Principles
| Principle | Rule |
|---|---|
| Make the right thing easy | The correct action should be the path of least resistance. Don’t rely on discipline. |
| Reduce cognitive load | Minimize decisions. Automate what you can. Make defaults smart. |
| Fail visibly | Silent failures are dangerous. Loud failures get fixed. |
| Design for maintenance | The next person maintaining this won’t be you. Make it obvious how it works. |