Tailorable blog

Top 5 misconceptions about wikis at work

Although many organizations are currently experimenting with wikis, some presumptions about wikis in the workspace appear to be sticky. Our interviews with managers as well as employees (before working with a wiki) revealed some opinions that may hinder the introduction process, if left undiscussed. What misconceptions have you encountered around wikis at work? John Rotenstein from Atlassian already mentioned a couple a while ago. Hereby my top 5:

1. “Making the technology available is enough for people to use it.”
   Carefully planning and supporting the introduction of the wiki is essential. People must trust the new technology, know when to use it (and when not), how to use it, have management support to use it, and find ways to embed it in their normal working routines. Putting the technology in place is just a small piece of the puzzle.
2. “Only information that will stand the test of time belongs in the wiki.”
   Comparing the company wiki with Wikipedia is not helpful: people have to learn that sharing raw ideas and initial thoughts can be great conversation starters and lead to a “pressure cooker” effect, where insights from different angles are combined into valuable results.
3. “You cannot trust the contents of a wiki page.” As with any piece of information, you have to judge wiki content carefully. However, the mechanism that all employees can mark and correct wiki pages helps in discovering and correcting errors. You’re not alone.
4. “If everybody can change everything, things will become a mess.”
   Ton Zijlstra told me to just make a slide with this text and then animate it, so “everybody” changes into “my colleagues”… If they still see that as a problem, then they need more then just a wiki.
5. “Putting information in the wiki is something you just do on the side.”
   These are actually two misconceptions: it takes time and effort to write a good wiki page, but more importantly, writing down results in a wiki could be the primary outcome of the work process, not a secondary documentation step. For instance, a design, meeting minutes, or a status report could just be delivered as a set of wiki pages. Management has an important role to reassure people that delivering project results as wiki pages is perfectly acceptable.

What are your experiences with presumptions around wikis at work?