Restructure at the friction point, in the moment — not system-wide, not later
Restructure hierarchies at the specific node causing friction during the moment you feel the friction, rather than conducting proactive system-wide reorganizations, to keep restructuring costs small and diagnostic signals fresh.
Why This Is a Rule
System-wide reorganizations are expensive, disruptive, and poorly targeted. You spend a day restructuring 200 folders, including 180 that worked fine, while the 20 that caused friction get attention proportional to the other 180 rather than proportional to their impact. The reorganization is proactive — it changes things before they break — which means it's guided by theory about what should be better rather than by data about what's actually causing problems.
Friction-point restructuring inverts this: you restructure the specific node that caused friction, during the moment you feel the friction, while the diagnostic signal is fresh. The friction tells you exactly what's wrong (this specific item is in the wrong place, or this specific level doesn't help navigation). The fix is small (move one item, flatten one level), immediate (costs 30 seconds), and perfectly targeted (addresses the exact problem).
This is the kaizen approach (Improve one thing every time you touch a note — kaizen for knowledge bases) applied to hierarchies: small, continuous improvements at the point of friction rather than large, periodic reorganizations that disrupt everything.
When This Fires
- When you experience navigation friction in a hierarchy (can't find something, wrong folder, confusing choice)
- Instead of scheduling "reorganization time" for your knowledge base
- When the instinct is "I need to redo my whole folder structure" (usually overkill)
- During any moment of hierarchy friction where the problem and fix are both clear
Common Failure Mode
Noting the friction and planning to "fix it later during the next reorganization." By later, the diagnostic signal — exactly what was wrong and where — has faded. You remember "the folder structure is messy" but not "I couldn't find the API spec because it was filed under 'Design' instead of 'Engineering.'" Fix it now while the signal is crisp.
The Protocol
When hierarchy friction occurs: (1) Notice the friction: what were you trying to find or file? Where did the hierarchy fail? (2) Fix the specific node now: move the item, rename the folder, flatten the unnecessary level, add the missing category — whatever resolves the friction. (3) Time budget: 30-60 seconds. If the fix would take longer, note it for your next review session. (4) Over time, friction-driven micro-restructuring converges on an optimized hierarchy without ever requiring a disruptive system-wide reorganization.