Before adding depth, try flattening + tags first — deep hierarchies cost more than flat ones with rich links
Before adding another level of nesting, first attempt to flatten the hierarchy one level and use tags or links to preserve relationships, as deep hierarchies are more expensive to maintain than flat hierarchies with rich cross-references.
Why This Is a Rule
Depth is expensive. Each level of nesting adds maintenance cost (items must be placed correctly at each level), navigation cost (one more click/decision per retrieval), and reorganization cost (restructuring deep hierarchies is harder than restructuring flat ones). Tags and links are cheap: they can be added, removed, and modified without restructuring the hierarchy.
The flatten-first approach treats depth as a last resort: before adding a subfolder, try putting the items at the current level with distinctive tags. If 30 items in a flat folder with good tags are navigable, the subfolder was unnecessary depth. If the flat structure genuinely becomes unmanageable (>20 items with no tagbased differentiation), then the nesting is justified.
Flat hierarchies with rich cross-references outperform deep hierarchies with sparse cross-references because retrieval in PKM tools is increasingly search-driven, not navigation-driven. Tags and links serve search; nested folders serve navigation. As search improves, the value of navigation depth decreases while the cost remains constant.
When This Fires
- When you're about to create a new subfolder in an existing hierarchy
- When a folder feels "too full" and the instinct is to create subfolders
- During hierarchy design when considering how many levels to create
- Any time depth is being added to solve an organization problem that tags might solve
Common Failure Mode
Defaulting to depth because it's visually tidy: subfolders look organized. But tidy navigation and effective retrieval are different things. A flat folder with 25 well-tagged items is faster to search than a three-level hierarchy with 25 items distributed across 8 subfolders — because the search finds the item directly while the navigation requires three correct choices.
The Protocol
Before adding a nesting level: (1) Attempt flat organization first: keep items at the current level. (2) Add tags or metadata to differentiate items that the proposed subfolder would have separated. (3) Test retrieval: can you find what you need via search or tag filtering without the subfolder? (4) If yes → don't add the level. (5) If no (genuinely unmanageable at the current level) → add the nesting, accepting its maintenance cost as justified.