Link Notes by Question Instead of Topic Sprawl. Topic folders grow forever. Question hubs stay useful because they match how you search.
Step 1 — List five questions you already ask out loud
Write questions you typed in Slack last month under stress—not academic topics. Elena started with: What breaks if we delay launch? Who owns API rate limits? What did we promise Enterprise in Q1? If you cannot think of five, read sent messages for a week before building hubs.
Title hubs as questions you actually ask under pressure. Launch is a topic; What breaks if we delay launch? is a retrieval cue.
Elena kept a scratch list in sent mail for five days before creating hubs. Real questions beat imagined curriculum.
Step 2 — Create one hub note per question
Title the hub exactly as the question. Inside, write a one-sentence scope: Facts that inform go/no-go on launch date—not general product strategy. Hubs are not folders; they are lenses.
Start with at most five hubs. More hubs feel productive and recreate topic sprawl with nicer titles. Add a hub only when the same question appears three times in a month.
Step 3 — Link facts upward, not sideways spaghetti
When a meeting produces a relevant bullet, append it to the hub with date and source: 2026-04-02 — Priya — load test failed at 2x expected traffic. Link project notes → hub. Avoid peer-only hairballs where every note links to every other note.
When you reopen the hub, the question frames the facts. Attach facts upward into the hub rather than weaving links with no reason string.
Elena adds links in thirty seconds after meetings—batch on Friday for gaps only. Capture stays fast; structure catches up on timers, not at capture time perfectionism.
Step 4 — Split and merge hubs by editing behavior
Split hubs that secretly answer two questions. Merge hubs you always open together on one screen—that is one hub with a better title. The test is editing behavior, not ontology debates.
If two hubs are always on screen at once, they are probably one hub with a clearer question title.
Step 5 — Friday: two hubs, one missing link each
Elena spends eight minutes on hubs she touched that week, adding one missing link each. Batch linking beats aspiring to perfect links at capture time. Capture stays fast; structure catches up on a timer.
Measurable signal: time-to-answer when someone asks a hub question in chat. Under two minutes means the hub works; over ten means gaps or wrong question title.
Step 6 — Delete facts that answer no live question
Not every fact deserves a home in the graph. If a bullet does not help a question you care about this quarter, leave it in capture or delete. Private maintained hubs beat public wikis that impress visitors and stale internally.
If a fact answers no question you care about, it is entertainment—not graph furniture.
Elena’s fifth hub waited until Who approves security exceptions? appeared three times in April. Before that, exceptions lived as orphan bullets in project notes—findable only if you remembered which project.
Elena’s launch hub — one week of maintenance
Elena created What breaks if we delay launch? on a Monday after a heated thread. By Friday she had seven dated lines—load test failure, legal sign-off pending, marketing asset slip. When exec asked for risks in standup, she pasted the hub link. Meeting shortened because facts were pre-aligned.
Maintenance was eight minutes Friday plus thirty seconds after each relevant meeting. No graph visualization, no plugin—just a question title and dated lines.
When the launch shipped, Elena archived the hub after copying two lines into a postmortem ref note. Hubs can retire—they are not permanent monuments.
Monthly hub review: untouched thirty days → retire or refresh. Stale hubs harm decisions more than no hub.
Copyable hub line format
YYYY-MM-DD — Source — fact in one sentence. Example: 2026-04-05 — Legal office hours — exceptions need CISO sign-off for vendors without SOC2. Consistent lines make hubs scannable on a phone between meetings. Prose paragraphs in hubs are a failure mode—they hide facts under style.
When Elena paste a hub link into Slack, the question title frames the thread. Fewer side debates; faster yes/no.
Hubs fail when they become reading assignments. If a hub exceeds one screen, split the question—not the facts across ten prose paragraphs.
Wrong hub title — when search fails silently
Elena once titled a hub Launch risks and kept missing it when she searched delay. Renaming to What breaks if we delay launch? matched her Slack vocabulary; retrieval fixed without new links.
Hub titles should match words you type under stress, not words that look professional in a folder tree. Say the question aloud before naming; if title and speech diverge, fix the title.
Elena paste hub links in chat instead of paraphrasing—fewer corrections, faster threads. The question title frames the answer before facts arrive.
Hub retirement — when the question dies
After launch, Elena archived What breaks if we delay launch? but kept Who owns API rate limits? active. Retired hubs get two lines copied to ref; the rest deletes. Questions end; facts survive in ref.
Keeping dead hubs creates search noise—people open outdated risk lists and argue from stale facts. Retirement is maintenance, not loss.
Review hub list monthly: any hub untouched thirty days moves to retire-or-refresh decision.
Hubs match how you search under pressure
Start with one hub tomorrow—the question that burned you last week. Link today’s notes upward before building a second hub.
When reopening a hub feels like reading a novel, the hub is too broad. Narrow the question until the first screen answers it.
Linking is maintenance, not capture luxury. Eight minutes on Friday beats perfect links you never add.
Public wikis without owners go stale. Private hubs you maintain beat impressive graphs you neglect.
Questions change; hubs retire. Facts survive in ref notes when the question dies— that is success, not loss.
Wrong hub titles fail silently—rename to match the words you type in chat under pressure, not folder aesthetics.