Team Knowledge
How to set up a team wiki — a practical guide for teams starting from scratch or reorganizing from chaos, covering tool selection, initial structure, content seeding, and the contribution habits that keep a wiki alive after launch.
A team wiki is one of the most frequently attempted and most frequently abandoned productivity investments. Teams set them up with high expectations; adoption is strong for the first few weeks; within two months, only the people who created the wiki are contributing; within six months, the wiki is an archive of outdated pages that nobody trusts.
The failure pattern is predictable: the wiki was set up before content was created, or content was created but contribution habits weren't established, or both. The tool is not the problem. The tool is often fine. The problem is the sequencing: most teams build the structure first and hope content follows. It doesn't.
The sequence that works: decide why you need the wiki and what questions it should answer, write the content that answers those questions, then choose the tool and structure that makes the content findable, then establish the habits that keep it current. Tool last, not first.
A team wiki without a defined purpose is a filing cabinet: it holds things, but nothing is organized to answer any specific question.
Before choosing a tool or creating any pages, answer these questions:
Who will use this wiki? Your team only? Cross-functional partners? New employees? All of the above? The answer affects what content to prioritize and how to structure navigation.
What questions should this wiki answer? List the 10 questions that your team members, new employees, or partners ask most frequently. The wiki's initial content should answer these 10 questions. If the wiki can't answer these questions on day one of launch, it's not ready to launch.
What is the primary use case? Onboarding new team members? Reference for recurring processes? Institutional memory? Cross-team transparency? Most team wikis serve multiple purposes, but one is primary. Build for the primary use case first.
What would make this wiki fail? Outdated content. Nothing useful at launch. Content no one can find. Contributors unclear on what goes where. Identifying failure modes before launch creates the opportunity to design against them.
Tool selection should follow purpose and team context, not hype or what a different company uses. The three choices that cover most team wiki use cases:
Notion: Best for: Teams starting from scratch, small-to-medium teams (under 100 people), teams that want to start quickly and don't have complex access control needs.
Notion pages are flexible (text, databases, embeds), easy to create, and support multiple views of the same content (table, gallery, board). The learning curve is low; most people can create and edit pages without training.
Limitations: Search quality decreases as the workspace grows. Permissions are less granular than Confluence. Database-heavy structures can become hard to navigate if not maintained.
Confluence (Atlassian): Best for: Teams already using Jira or other Atlassian products, organizations that need fine-grained permissions, teams of 100+.
Confluence has robust search, page history, detailed permission controls, and strong integration with Jira (for linking pages to tickets). It's designed specifically for documentation and knowledge management.
Limitations: Higher contribution friction than Notion. Creating a well-formatted page requires more effort. The interface feels heavier.
GitHub Wiki / docs/ folder in a repository:
Best for: Engineering teams that want documentation co-located with code; teams with a docs-as-code preference.
Documentation in a repository is version-controlled, reviewable via PR, searchable via code search, and visible to anyone with repository access. Changes to documentation can be required alongside code changes.
Limitations: Navigation is limited (essentially a flat list of files). Not accessible to non-technical team members without GitHub familiarity. No database-style views.
The default recommendation: For most teams starting fresh, Notion is the best balance of ease-of-use, flexibility, and organizational power. For teams already in Atlassian, Confluence. Don't switch tools because the current tool "doesn't work" — the tool is rarely the problem; structure and contribution habits are.
The most common wiki structure mistake: organize by department or org-chart structure. "Engineering," "HR," "Marketing," "Sales" — one section per team. This mirrors the organization's structure, not how people search for information.
People search for information based on:
Structure the wiki around these entry points:
How-to guides section: Process documentation organized by task. "How to submit an expense report." "How to request a new software license." "How to create a project in Asana." Task-based titles, step-by-step content.
Reference section: Information organized by subject. Team roster, tool directory, policy summaries, glossary of internal terms, external vendor contacts. Reference content is dense and scannable, not tutorial-style.
Teams and functions section: One page per team or major function describing what they do, who's on them, how to reach them, and what they're responsible for. This is the "who to contact for what" map.
Standards and norms section: Decisions the team has made about how it works. Communication norms. Meeting expectations. Documentation standards. Code review processes. Working hours. The implicit rules made explicit.
Projects and history section: Documentation of past and current projects. Meeting notes archive. Decision log. Past initiatives with outcomes. This is the institutional memory section — used less frequently but valuable when needed.
This five-section structure works for most teams of up to 100 people. Adjust as the team's needs become clearer; don't over-engineer the structure before you have content to put in it.
A wiki that launches empty sends the message: "this is a filing system that doesn't yet have files." Adoption won't happen because there's nothing to use.
The minimum viable content set at launch:
For the how-to section: 5-10 step-by-step guides for the most common recurring tasks. These should be the tasks that generate the most recurring questions. If "how do I submit an expense report?" is asked 20 times per month, that's the highest-priority how-to guide.
For the reference section: Team roster with roles, at least one system reference page (for the most-used internal system), and any external-facing reference material (vendor contacts, partner details).
For the teams section: A page per team with the bare minimum: what does this team do, who's on it, and how to contact them.
For the standards section: 2-3 pages covering the team's most important norms: communication standards, meeting expectations, and any process or policy that's frequently asked about.
Total at launch: 15-25 well-written pages. This is achievable in 2-3 weeks with 2-3 contributors. The launch wiki should feel sparse but useful — every page someone visits should give them something they need, and there should be no pages that exist only as placeholders.
The hardest part of running a team wiki is not creating content — it's maintaining the culture of contribution after launch. The practices that sustain a wiki need to be established before or at the same time as the wiki itself.
The "answer once, add to wiki" norm: Any time a team member answers a question in Slack, email, or a meeting, and the question is one that could be asked again, the answer goes in the wiki. Not a full page — even a paragraph. This is the most important contribution habit because it grows the wiki with the content people actually need.
The PR checklist item (for engineering wikis): Any PR that changes a system or process covered by the wiki includes a wiki update as a checklist item. The PR is not complete until the documentation is current.
The named owner model: Every significant wiki page has a named owner responsible for its accuracy. Not a team — a person. When the process or system changes, the owner updates the page. When a page is wrong, someone knows to contact.
The onboarding feedback loop: New employees are explicitly asked, after 30 days, to update any wiki page they found incorrect or unclear during their onboarding. This creates a continuous improvement mechanism tied to the highest-value use case.
Wiki pages that are hard to find don't get used. Consistent naming makes pages findable by search and by browsing.
Effective naming conventions:
For how-to guides: Start with "How to [verb] [object]." "How to Submit an Expense Report." "How to Request Time Off." "How to Add a New User to [System]." The title matches the question the reader is asking.
For reference pages: The name of the subject. "Team Roster." "Software License Directory." "Vendor Contact List." "Expense Policy."
For project and initiative pages: "Project: [Name] (YYYY-QN)" — e.g., "Project: CRM Migration (2026-Q4)." The date context prevents confusion between a current project page and a historical one.
For meeting notes: "[YYYY-MM-DD] [Meeting name]" — e.g., "2026-10-18 Weekly Team Sync." Chronological naming makes the archive sortable by date.
The search test: Before naming any page, ask: "What would someone search for to find this page?" The name should contain those words. "Expense Policy" should appear in the name of the expense policy page; "expense" is what people search.
Announce the wiki at the point when it has enough content to be useful. The announcement should:
Say what it is and why it exists. "We've built a team wiki as the single source of truth for [team name] processes, policies, and knowledge. If you have a question about how we work, this is where to look first."
Show people where to start. Link the home page. Highlight the 3-5 pages most relevant to the broadest audience. Give people an immediate entry point.
Set the contribution expectation. "When you find something missing or incorrect, please add or fix it. When you answer a Slack question that should be documented, please add it to the wiki. This only works if we all contribute."
Acknowledge that it's incomplete. "We've seeded it with the most common reference material, but it's not comprehensive yet. That's by design — the wiki grows with what the team needs, not with what we thought you needed in advance."
Even with good contribution habits, a wiki requires periodic review to catch pages that have drifted from reality without anyone noticing.
Quarterly review process (30 minutes):
The quarterly review produces two outputs: a wiki that's more trustworthy (stale content updated or archived) and a prioritized list of new content to add.
Setup: A 12-person customer success team. They're moving from a mix of Google Docs, Slack-pinned messages, and personal notes to a team wiki. Goal: reduce onboarding time for new CSMs and reduce the number of Slack questions that senior CSMs field from junior ones.
Their process:
Week 1 (purpose and tool): The team lead writes the purpose statement, defines the five entry points, and chooses Notion. She doesn't create any pages yet.
Weeks 2-3 (seeding): Three team members spend 3-4 hours each writing the minimum viable content: 6 how-to guides (most common CSM tasks), 2 reference pages (team roster, tool directory), 2 standard pages (communication norms, escalation process). Total: 10 pages.
Week 3 (contribution habits): They establish the "answer once, add to wiki" norm in the team meeting. They add wiki update to the CSM check-in template. They name owners for each page.
Launch (end of week 3): A Slack announcement linking the wiki. Three existing pages are used within 24 hours of announcement. One team member adds a page for a recurring question within the first week.
Month 1: 18 pages. Two new CSMs join and use the wiki as their primary onboarding reference. Their first question to a senior CSM comes on day 3 rather than day 1.
Month 3: 29 pages. Zero-result search rate at 18% (started at 35%). Senior CSMs report ~3 fewer Slack questions per day each.
A team wiki that works is not built — it's grown. The tool is a container; the structure is a navigation system; the content is what makes it valuable; and the contribution habits are what keep it alive. Teams that invest in structure without content launch empty wikis. Teams that create content without contribution norms create wikis that are useful for six months and then stale for the next six. The sequence — purpose, content, structure, tool, habits, maintenance — produces a wiki that becomes the team's first resource rather than an afterthought, and that improves incrementally with every Slack question that gets documented and every new team member whose onboarding friction gets fixed.
More WebSnips articles that pair well with this topic.
How to run a documentation audit — a practical guide for teams who want to systematically assess what documentation exists, what's accurate, what's missing, and what should be removed, producing a clear action plan for a knowledge base that's trustworthy and complete.
How to break down knowledge silos — a practical guide for teams and organizations where critical knowledge is trapped in specific people, teams, or systems, creating organizational brittleness, slowing decisions, and widening capability gaps between teams.
How to build a company handbook — a practical guide for founders, operations leaders, and HR teams who want a handbook that communicates what the company values, how it works, and what employees can expect, without producing a bureaucratic document no one reads.
How to build a company knowledge base — a practical guide for teams and organizations who want to capture institutional knowledge, reduce repeated answering, and make organizational context accessible to every employee regardless of when they joined.
How to build a decision log — a practical guide for teams and organizations who want a permanent, searchable record of significant decisions that makes the reasoning behind current practices visible and prevents repeated debating of already-resolved questions.
How to capture knowledge from departing employees — a practical guide for managers and HR teams who want to systematically extract institutional knowledge before it leaves with an employee, rather than discovering the gaps after they're gone.