Centralizing knowledge: the team wiki
The team's memory must not live in one head
In a young team, critical information often sits in the founder's brain: how invoicing works, where the access credentials are, why a given decision was made. As long as it's in a head, every question depends on their availability, and every departure loses memory. The answer isn't one more meeting, it's a knowledge base: a single, searchable place where what must outlive conversations lives.
If a piece of information can only be found by asking someone, it isn't documented — it's held hostage.
Knowledge base tools
The central tool of modern collaboration is often the team wiki. The options:
- Notion is the Swiss army knife: pages, wikis, databases, templates. Free plan for a small team, then ≈ $8-10/user/month. Ideal when you want a single tool for docs and light tracking.
- Google Workspace (Docs + Drive) is unbeatable for real-time co-writing and simplicity; less structured than a wiki (≈ $6/user/month).
- Confluence targets larger and technical teams, structured but heavier.
- Slite or Coda are Notion alternatives, one more focused on team docs, the other on "programmable docs".
Which tool for which need
| Need | Recommended tool | Indicative cost |
|---|---|---|
| Wiki + light tracking in one tool | Notion | free → $10/u/mo |
| Real-time co-writing, simplicity | Google Workspace | ~$6/u/mo |
| Structured wiki, technical team | Confluence | ~$6/u/mo |
| Polished team documents | Slite / Coda | free → paid |
What deserves to be documented (and what doesn't)
Documenting everything kills documentation: no one reads it anymore. Write down what is reused or costly to re-explain:
- Recurring procedures: onboarding, invoicing, publishing a piece of content.
- Decisions and their reasons: why you chose a tool, an audience, a price.
- Access and references: where the accounts, links and key contacts are (without storing passwords there — see below).
- The "how we work": naming conventions, rituals, who decides what.
:::tip[Tip: document as you go] The best docs get written the moment you answer a question for the second time. Instead of answering privately, write the answer in the wiki and share the link. The third person will serve themselves. :::
A simple structure that lasts
A wiki quickly becomes an attic without a clear tree. A skeleton that works for most small teams:
Home
├── Team (who does what, rituals, conventions)
├── Procedures (onboarding, invoicing, publishing…)
├── Projects (one page per active project)
├── Decisions (dated log of important choices)
└── Resources (access, links, contacts)
What matters isn't a perfect tree, but that there's a single official place and everyone knows it.
Access security: what does NOT go in the wiki
:::danger[Never do this: store passwords in plain text] No password, API key or secret should sit in a Notion page or a shared Google Doc. Use a team password manager — 1Password, Bitwarden (open source, free tier possible) or Dashlane — which encrypts and logs access. The wiki says where the account is; the vault keeps the key. :::
The trap of rotting docs
Wrong documentation is worse than none: it erodes trust and misleads. Two habits keep it alive: date the sensitive pages and assign an owner per section, responsible for updating it. A page without an owner always ends up stale.
Key takeaways
Get the team's memory out of heads and chat threads: set up a single knowledge base (Notion for all-in-one, Google Workspace for co-writing), document what is reused or costly to re-explain, and structure it into a few clear sections each with an owner. Keep secrets in a password manager, never in the wiki. Once knowledge is centralized, the work itself remains to be organized: on to running projects and tasks.