Notion is powerful enough to be everything — wiki, project tracker, CRM, knowledge base, meeting notes archive. That’s also its biggest risk. Most teams set up Notion, fill it with pages for three months, and end up with a disorganized mess where nobody can find anything and new hires stare at the sidebar in bewilderment.
We’ve restructured our Notion workspace twice. The current setup has survived 18 months, three new hires, and zero “where is that doc?” Slack messages in the last quarter. Here’s the structure, the decisions behind it, and what we deliberately chose not to do.
The top-level structure
Our Notion sidebar has exactly five top-level pages. That’s it. Everything else lives underneath them.
- Team Handbook — policies, norms, how-we-work documentation
- Projects — active and archived project spaces
- Knowledge Base — reference material organized by domain
- Meeting Notes — weekly syncs, 1:1s, retrospectives
- Templates — reusable templates for common document types
Each top-level page has a clear owner: one person responsible for keeping it organized. Ownership doesn’t mean they write everything — it means they notice when something’s in the wrong place and move it.
Why five pages
We tried both fewer and more. Three top-level pages meant cramming too many things into “Knowledge Base.” Eight pages meant nobody could remember the taxonomy. Five is the number where people can hold the full structure in their heads without checking.
The PARA method (Projects, Areas, Resources, Archives) is a popular framework for this. Our structure is similar in spirit — separate active work from reference material, and keep archives accessible but out of the way.
Inside each section
Team Handbook
This is the first thing new hires read and the primary reference for how our team operates. It contains:
- Communication norms — our async-first stack, Slack structure, response time expectations
- Meeting norms — weekly sync format, 1:1 structure, how to schedule a meeting
- Time & leave — time off policy, time zone expectations, overlap hours
- Tools & access — list of every tool we use, who has access, how to request access
- Onboarding guide — the 30-day checklist plus role-specific setup instructions
Every page in the handbook has a “last reviewed” date at the top. If a page hasn’t been reviewed in 90 days, its owner checks whether it’s still accurate. Stale docs are worse than no docs — they create false confidence.
Projects
Each active project gets its own page, created from a template. The project page contains:
- Brief — what are we building, why, for whom, what does done look like
- Decision log — a simple table: date, decision, rationale, who was involved
- Resources — links to Figma files, repos, external docs, relevant Slack channels
- Status updates — a running log of async updates (we post these weekly)
Archived projects stay in the Projects section but are moved to an “Archive” toggle. We don’t delete them — decision logs from old projects are frequently useful.
We use a Notion database (not nested pages) for the project index. Each project is a database entry with properties for status (active, paused, archived), team, and start date. This lets us filter the view to “active projects only” — which is what you want 95% of the time.
Knowledge Base
This is reference material that isn’t tied to a specific project. Think: how to set up a development environment, brand guidelines, vendor contacts, the company’s approach to code review.
We organize the knowledge base by domain, not by team. A page about “How we do code review” lives under Engineering, but “How we write help articles” lives under Content. The reason: people look for information by topic, not by org chart.
Each knowledge base page follows a consistent format:
- Title — what this is about
- Last updated — date
- Owner — who maintains this page
- Content — the actual information
- Related — links to related pages
The “Related” section is important. It creates a web of connected documents that helps people discover related information. Without it, the knowledge base becomes a flat list where every page is isolated.
Meeting Notes
Meeting notes are stored in a Notion database, not nested pages. Each entry has properties for: date, type (weekly sync, 1:1, retro, ad hoc), participants, and a link to the relevant project if applicable.
Why a database: it makes meeting notes searchable and filterable. “Show me all the weekly syncs from Q1” is a one-click filter. “Find the 1:1 where we discussed the hiring timeline” is a search query. Nested pages can’t do this.
For our weekly sync format and the template we use, see running a weekly sync in 25 minutes.
Templates
We maintain templates for recurring document types:
- Project brief
- Decision record
- Weekly async update
- Meeting notes (by type)
- Knowledge base article
- Onboarding checklist
Templates are stored in Notion’s built-in template system (the “New” button in databases can use templates) and also duplicated as pages in the Templates section for reference. The Templates section is the canonical source — if someone wants to customize a template for their context, they duplicate it from there.
Permissions and access
Notion’s permissions can get complicated quickly. We keep it simple:
- Workspace level: Everyone on the team has edit access to the entire workspace. We don’t restrict by team.
- Guest access: External collaborators get access to specific pages only. We use Notion’s “Share” feature for this, not workspace invitations.
- No private team spaces. Everything is visible to everyone. This prevents information silos and means any team member can find any document. The only exception is HR-sensitive material (performance reviews, salary data), which lives in a separate, restricted section.
Some teams use Notion’s team spaces feature to create private areas for each department. We tried this and found it created the same silo problem we were trying to avoid. Unless you have a regulatory reason to restrict access, default to open.
What we chose not to do
These are features and patterns we explicitly avoid:
No task management in Notion. We use Linear for task and project tracking. Notion databases can technically do this, but they’re not great at it — the board view is clunky, there’s no native sprint concept, and notification reliability for assigned tasks is poor. Use a purpose-built tool for task management.
No inline databases for small data. When you only have 5-10 items, a bulleted list is clearer than a database. We use databases when we need filtering, sorting, or relations — not for every list.
No heavy nesting. Our deepest page hierarchy is three levels: top-level section → category → page. If you need a fourth level, the content probably belongs in a different section or the page should be split.
No Notion comments for discussions. Comments in Notion are unreliable for real-time discussion — notifications are inconsistent, threads get lost, and there’s no threading within comments. We use Slack for discussions and Notion for the resulting decisions and documentation. If a Notion page needs feedback, we share it in a Slack thread with a link.
No custom emojis or elaborate formatting. Some teams spend hours making their Notion workspace visually polished with custom icons, cover images, and callout blocks. This looks nice but creates maintenance burden and discourages contribution — people don’t want to “mess up” a beautifully formatted page. We use plain formatting and accept that a wiki should look like a wiki, not a magazine.
Maintenance rhythm
A Notion workspace without maintenance degrades within weeks. Here’s our schedule:
Weekly (5 minutes): The meeting notes database is checked — are recent meetings logged? Are decisions from the weekly sync captured?
Monthly (30 minutes): Each section owner scans their section for stale content, broken links, or pages that have drifted out of their correct location. The checklist: check that every page has a “last reviewed” date and it’s within 90 days, verify internal links between pages still work, flag anything that’s clearly outdated, and move any pages that have drifted into the wrong section. This is usually done during a quiet Friday afternoon.
Quarterly (1 hour): The whole team reviews the top-level structure. Is it still working? Are people finding what they need? Are there recurring “where is X?” questions that signal a navigation problem? This review has led to our two restructurings — both of which were worth the effort.
The maintenance costs more than the initial setup. A beautiful Notion workspace on day one means nothing if it’s a graveyard by month six. The structure above is designed to be low-maintenance — flat hierarchy, clear ownership, database views instead of nested pages — but it still needs regular attention.
Start with the five sections, create the templates, and enforce ownership. The rest will follow as your team adds content. Resist the urge to build elaborate systems before you have content to put in them — structure should follow content, not the other way around.