What a wiki is for
A team wiki is a set of shared pages that anyone on the team can read and, usually, edit. It exists to answer questions that otherwise get asked repeatedly: how do we do this, who handles that, where does this live, what did we decide last time?
It is different from a pile of documents. Files sit in folders and are often finished products; wiki pages are meant to be living reference. It also differs from chat, where answers vanish into the scroll. The value of a wiki comes from one thing: people trust it enough to check it before asking someone.
That trust is fragile. A wiki with a few accurate, useful pages is worth more than one with hundreds of pages of uncertain age.
Start small and specific
Most failed wikis began with an ambitious plan to document everything. A better start is to collect the questions your team actually repeats. Look at recent chat threads and ask what new team members tend to need in their first weeks. Typical early pages include:
- How the team works: working hours, how to request things, who to ask for what
- Common processes, such as how to submit an expense or book time off
- Where important things are stored
- A glossary of internal terms and abbreviations
- Contact points for outside suppliers or partners
Write five to ten pages like this before deciding anything fancy. You will learn what format suits your team and what people look for.
Keep the structure simple
A wiki needs a home page that links to the main sections, and the sections should reflect how people think about their work, not how the company chart looks. Aim for a shallow hierarchy: a handful of top-level sections, each with a modest number of pages. Deep nesting hides content in the same way deep folders do, a problem addressed in the discussion of folder structure.
Give each page a clear, searchable title that uses the words people would type. “How to request a laptop replacement” is better than “Equipment” because it matches the question. Use consistent page layouts so readers know where to look: a one-line summary at the top, then steps or details, then a last-reviewed note.
For repeatable procedures, a consistent writing style helps a great deal. Standard operating procedures can live in the wiki as step-by-step pages, and document templates for common page types keep them uniform without much effort.
Assign owners, not just authors
The central reason wikis decay is that everyone can edit and nobody is responsible. Give every page, or at least every section, a named owner. The owner is not necessarily the writer; they are the person who is asked “is this still right?”
Ownership can be lightweight:
- Put the owner’s name and a last-reviewed date at the top of each page.
- Pick a review interval that matches how fast the content changes, for example more often for processes that change frequently and rarely for stable background.
- When someone leaves a team or changes role, reassign their pages as part of the handover, in the same way you would handle access offboarding.
If a page has no owner and nobody wants it, that is useful information. Consider deleting or archiving it.
Make contributing easy
If editing feels like a formal process, people will not do it. Lower the barrier:
- Let anyone fix a typo or add a missing step directly.
- Provide a short guide on writing a page, with an example.
- Welcome small, imperfect contributions and polish later.
- Allow comments on pages so readers can flag problems when they do not feel comfortable editing.
For changes that affect policy or important procedures, you may want a review step before publishing. The approach in document approval applies: route the draft to the right person, record who approved, and keep the decision visible.
Build the habit of pointing to the wiki
A wiki only grows if it becomes the default answer. When someone asks a question in chat that has a page, reply with the page. When there is no page, answer the question and then ask whether the answer should be written down; often the person who asked is a good one to write it, since they just learned what was missing. After a meeting, put lasting decisions on a page rather than only in meeting notes.
Over time this builds a feedback loop: questions create pages, pages reduce questions, and the remaining questions reveal gaps.
Handle sensitive information carefully
Not everything belongs in a wiki everyone can read. Passwords, personal data about customers or colleagues, and confidential financial details need stricter handling. Decide upfront what is out of bounds, and use access controls where your tool supports them. Review sharing permissions periodically, because a wiki often starts open and becomes risky as more content is added. Password managers are a better place for credentials than any page.
Keep it findable
As a wiki grows, search becomes the main way people navigate. Use clear titles, consistent terminology and short summaries. If your tool supports tags, apply a small, agreed set rather than letting everyone invent their own. The habits in document search apply here as well.
Know when it is not working
Signs that a wiki is declining include pages with old dates, people saying “I just ask Sam,” duplicate pages on the same topic, and a home page nobody visits. Respond with a small cleanup: remove or archive outdated pages, merge duplicates, and reaffirm owners. It is also worth asking honestly whether the tool suits the team. If it does not, tool retirement and data migration are worth planning carefully rather than abandoning content in place.
A team wiki is never finished. It is a modest, ongoing practice of writing down what the team knows, in a place where the next person can find it.