Chapter 6. Prevent (or Minimize) Obstacles
Wikipatterns – Table of Contents
What can hinder wiki adoption?
Whereas wiki patterns are the approaches and strategies you want to apply, anti-patterns are the things you don’t want to happen, or at least want to catch and fix as early as possible. To do this effectively, you have to be able to recognize them, and that’s the goal of the anti-patterns on Wikipatterns.com. Let’s look at some of the most common ones, the reasons they happen, and how to quickly fix them.
The key thing to remember about anti-patterns as they relate to wiki use in an organization is that they’re mostly the result of ignorance about how to use the wiki, and not malicious intent. Often people who are engaging in anti-pattern behavior just need some help understanding how to contribute to the wiki in more productive ways.
Sometimes a person can get too enthusiastic about the wiki, and try to do everything. Remember that kid in school who always raised his or her hand to answer every question? It’s somewhat the same situation with a person who acts as a Do-it-all on the wiki.
A Do-it-all is someone who:
- is always the first to volunteer to do something on the wiki to the point that they don’t even give others the opportunity to volunteer
- regularly offers to do things on the wiki for others, instead of helping them do it themselves
Bear in mind that a Do-it-all isn’t a _bad_ person, but the danger in having a Do-it-all is that one person dominating the wiki blocks others from having the opportunity to directly use it themselves. If someone is reluctant to use the wiki, and a Do-it-all just offers to do it for them, that person will never get over their reluctance to use the wiki, and will rely on the Do-it-all instead of taking the time to properly learn how to use the wiki. This can ultimately doom the wiki because it doesn’t have enough people using it to make collaboration effective. Also, the people who are reluctant to use the wiki are often skeptical about whether it should even be used at all, and if they don’t see its value by directly interacting with it, they’re likely to not support it in the long run.
One way to channel a person’s enthusiasm away from Do-it-all behavior is to have that person help others get comfortable with the wiki. Instead of making changes by themselves, ask that person to meet with others who are less familiar with the wiki, and work with them to both get comfortable with the mechanics of editing and collaboration, and introduce changes that will stimulate further contributions.
OverOrganizer and Do-it-all have some similarities, and sometimes the same type of person can exhibit both behaviors. The main difference between the two is that unlike a Do-it-all who does everything, an OverOrganizer tends to take what others have contributed to the wiki and rearrange it to try to structure content in a way that makes sense to them. Often this involves moving pages, renaming them, and rearranging content – sometimes within the same page, and sometimes to different pages.
As with Do-it-all, an OverOrganizer isn’t doing this out of any negative intent, and is actually trying to improve the wiki. But the problem with this is it leaves others confused, unable to find content they added, and it deters them from participating because they lose a sense of ownership over their contributions. As much as a wiki is supposed to be collaborative and a invite editing of all content, people need to at least find the content they’ve contributed and feel confident that there’s some logic to how content is changed on the wiki. If one person unilaterally changes the structure too much, and moves or rearranges pages others have just created, people will lose interest in the wiki because they feel they don’t have much to contribute or can’t do it in a way that satisfies them.
A wiki should start out with the least amount of structure necessary and structure should be added over time, when needed, and in a manner that involves and informs everyone who uses it. If you encounter an OverOrganizer, keep in mind that they might not even realize that what they’re doing can be harmful. Encourage them to leave a comment on a page proposing a significant content change before actually making that change. This offers an opportunity for discussion and refining the direction of major changes, but it can also simply inform people so they know where to find content after the change. Also, it’s a good idea during a group’s wiki BarnRaising to emphasize that people should distinguish between smaller, routine edits and larger, more significant changes, and in the event of a larger change, discuss it with the community first.
WikiTroll is another anti-pattern that often arises out of ignorance about how to interact on the wiki. It’s different from constructive criticism because when a person exhibits WikiTroll behavior, they make philosophically negative comments about a topic that can provoke equally negative responses, in some cases. The latter doesn’t always happen, but at the very least the comments distract people from productive collaboration.
An example of a comment from troll might be, “This whole company stinks and makes a crappy product. You should go check out my company instead.” On the other hand, a constructive critic might say, “The export to PDF feature in this software crashes if the file is more than 10 pages long” or “The glue supplied with the build-it-yourself table is weak and doesn’t bond.”
So how should you handle trolling? First, bear in mind that trolling is less frequent inside organizations, where the wiki community parallels an established one and people are working toward shared goals. So keep an eye out for trolling in wiki that are open to the public, such as a support or community website for a project or product. One way to deter casual trolling on a publicly-accessible wiki is to require registration. This is effective because registering requires some effort that people often aren’t going to expend if they just want to post a negative comment but don’t want to otherwise engage in the community. Also, registration attaches some level of identity to the comments that people are not likely to want to establish if they’re just casually trashing a product, project, or community.
If trolling happens inside your organization, it may simply be because the person posting negative comments doesn’t realize that what’s posted online can come across more strongly negative than in person. In that case, a simple chat with the person and explaining to them that it’s better to tone down comments and build criticism around facts and specific issues will make comments less flaming and more useful.
Wikiphobia arises out of some level of fear or dislike of the wiki. Mostly this is the result of misunderstanding or lack of experience with the wiki, but it’s different from the preceding anti-patterns because it often results in a lower frequency of participation on the wiki. In some cases people with Wikiphobia can even try to sabotage the wiki by suggesting that existing tools should continue to be used instead. This is a problem because the wiki thrives on active participation and if too many people have a phobia about things like editing content written by another person, then it won’t achieve critical mass of activity and will wither.
One way to handle Wikiphobia is to just circumvent it. Create a wiki and don’t tell the Wikiphobic people about it until it reaches critical mass with others and the momentum can’t be stopped. This also gives you a tangible example to show how wiki collaboration works in your organization, and how it’s beneficial. This can go a long way to inform a Wikiphobic person and demonstrate the kind of value that convinces them to embrace it.
There is some risk here because if the Wikiphobic people are still resistive, and happen to be in positions of power they might still try to stop the wiki altogether, and then you run the risk of losing all the collaborative fabric that’s been built on the wiki. But the reality is that once the wiki has gained traction and the people using it see it as essential to their work, they’ll advocate for it to stay and a Wikiphobic person – even someone in a powerful position – won’t be able to get rid of it easily. Even if that did happen, the grassroots nature of wiki means that a new one would likely spring up in its place. The risk here is that the new wiki could be outside the firewall, potentially putting information at risk. The bottom line is, once a wiki is in place and has gained both a critical mass of activity and momentum, Wikiphobic people will have to use it or risk being left behind, and most will, with some coaching and good examples, come around.
Creating a Sandbox, or test space where people can create pages and practice editing seems like a good idea, but it’s not always as useful as it seems. For people new to the wiki, having to start in a Sandbox can create the false impression or reinforce misconceptions that the wiki is difficult to use and requires training away from the “real” content. If a person is uncomfortable with the idea of editing content written by someone else, a Sandbox won’t fix this because people don’t create content together and collaboratively edit it as they would in a space dedicated to a project or team.
Also, creating a Sandbox is not a remedy for Wikiphobia because it doesn’t show the wiki in true form. The Sandbox is much like the warm-ups before a figure skating competition, where all the athletes are on the ice at once, but each is practicing his or her own routine independently.
It’s better to have new users start by creating a personal space, because it gives them a chance to practice creating and editing content with a purpose. When people edit in the Sandbox, there isn’t a larger purpose for the editing so they aren’t experiencing real wiki editing or collaboration. With a personal space, they may not experience as much collaboration, but building something with common elements and purpose enables them to get comfortable with the mechanics of editing, and produce something they’re proud of. Others can comment in personal spaces to welcome each user, and that provides an introduction to editing in a shared space.
In some organizations, there’s a push to charge departments or teams for technology services like disk storage space, or use of enterprise tools like the wiki. The thinking behind this is that it’s easier for a central IT operation to support new services if the users that want them are willing to share in the cost. This idea has emerged as a response to the high price of most enterprise knowledge management tools, which IT departments have trouble affording on their own.
It can be a good idea, but there’s a place where it goes very wrong, and works against the needs of users: when the IT operation decides to measure use of the tool and charge users based on their level of use. This essentially penalizes the groups that use it most, and encourages people to limit their use of it to save costs. That, in turn, limits the network effect in which the wiki’s value is based on a cycle of increasing membership and activity.
How can this be avoided? Don’t charge based on level of usage. In fact, with the low cost of wikis compared to other enterprise software, this shouldn’t even be an option. However, watch closely to make sure that if people suggest this based on their prior experience with more expensive tools, you can explain why it’s not financially necessary because of the low cost of the wiki.
No one wants to be first to do something right? If people see an empty page, they won’t know where to start and will likely not edit it because they don’t want to post the wrong information. When people see an empty page, they often wait for the person who created it to post information first, since they assume the page creator knows best what she or he wants to do with the page. It can be good for the creator to establish the purpose of the page and seed it with content, but the problem occurs when the page sits idle for too long and others just don’t know what to do with it. When a wiki has too many empty pages, it can affect the overall level of collaboration because people visiting the wiki will see those pages and might assume that it’s just not the place to be and stop visiting it regularly.
So what can you do?
When you create a new page, post a basic structure, a more detailed scaffold, or just a few lines of info on the page’s purpose and what content should be added to it. Even if that content is to be generated over time and not immediately available, having some information on the page helps guide people so that when they do have some content that belongs on the page, they know where to post it.
If you see an empty page, mention it to the person who created it to see if she or he realizes it’s empty. You could also post a comment on the page asking for people’s thoughts on what content should be added, or you could edit the page itself and post a scaffold, or rough outline of content. Then email the URL to others on your team and invite them to edit the structure and contribute content.
It’s exciting to start a wiki, especially if you’re the WikiChampion and are personally invested in making it a success. But you don’t want to be so enthusiastic that people get turned off to using it. This is a fine line – no question – because the job of a WikiChampion is to get people excited and suggest using the wiki so that it gets a critical mass of activity, becomes a magnet for finding and building information, and anchors itself firmly in at the core of peoples’ work.
If you’re too pushy about it, and try to make people drop other tools in favor of the wiki too quickly, they may feel pressured, uncomfortable, and unwilling to make the move. It’s human nature to resist change to some extent, and, let’s face it, people who aren’t early adopters get tired of trying all kinds of new tools – especially if they’ve been burned in the past.
So, take a measured approach. Be enthusiastic, but resist the temptation to push everything onto the wiki as fast as possible. If people want to move some projects on the wiki, but feel that others should wait until they’re comfortable with getting the first round of projects on the wiki and working out the kinks, be supportive of this. The key to avoiding the All-wiki-all-the-time syndrome is to manage the change effectively. Pace things so that there’s a balance between growing wiki use at a healthy rate, and making sure people are comfortable with the process.
Manager Lockdown is a scenario that takes place when a manager decides to take active ownership of content on the wiki and assume an increasingly direct role in editing that content. It happens most frequently after the wiki has become established inside an organization, when people are beginning to use it for projects involving external content development.
Sometimes it’s the result of a fiefdom mentality at play. Ironically, the people who are most likely to come along and try to take ownership as a result of that perceived need to guard their territory are the same people who were doubtful of the wiki’s value early on, and likely to have tried to discourage its use altogether.
In either case, when this happens it blurs the role of the wiki because certain content is now subject to the hierarchical, top-down control usually associated with more traditional content management tools. Even though other content is left to the peer-management of the wiki, people become reluctant to contribute because they don’t want to edit the wrong page and upset someone above them.
Also, when people just take over content on the wiki but don’t understand how to effectively use it, they spend most of their energy on the home page, instead of on the sub-pages where collaboration really takes place. This is a direct result of the fact that more emphasis is placed on the home page in traditional web sites and hierarchically organized sets of knowledge, and the downside here is that the manager may miss good content altogether.
The bottom line: this is a surefire way to risk slowing the momentum of a wiki.
So what should you do?
This is a complex pattern because it encompasses two scenarios: one where the intentions are good, and another where the motivation isn’t, but both can be counterproductive to collaboration. In the former scenario, the best course of action is to make sure pages are available to freely draft content in the early stages, and establish a practice of moving content from a drafting page to a managed page once it’s ready to be reviewed and approved for public distribution. Also, it’s important to educate a well-intentioned manager about the need to be transparent when managing pages, and to encourage contribution and collaboration so people don’t feel reluctant to edit. Most well-intentioned managers will appreciate this help, because they don’t want to disrupt something successful.
In the latter case, educating the manager is necessary to help them better understand the conditions necessary for the wiki to function successfully. Breaking the wiki down into regions of control will ultimately doom it because this runs counter to the social simplicity that makes using it so inviting. The wiki has to be the domain of the users for them to use it, and hierarchical control just gets in the way. Most managers don’t want to undermine something that works, but they need to be informed so they understand how to recognize that it’s working well.
Too much structure
This anti-pattern is the result of a long legacy of highly structured tools that force you to learn their structure before you can start using them. The inclination is to try to anticipate the structure for a new wiki and build it before content is added and collaboration takes off. If the structure is built too early, it won’t necessarily match how people really organize information, and it may make people think the wiki is too rigid to meet their needs.
It can also leave the wiki in a messy, disorganized state, with lots of empty pages that are part of the anticipated structure, and lots of added pages that would otherwise appear organized but don’t because they don’t match the structure and are mixed in with empty pages. This can make information hard to find and deter participation on the wiki if people see it as a disorganized mess.
The solution: Have a BarnRaising so that the everyone who’s going to use a particular wiki can post content and build the basic structure together. Every wiki has a certain amount of structure, but it needs to evolve over time to meet the specific needs of the people using the wiki, and stay compact and simple.
When you first start adding content to a wiki space, keep it simple. Use the home page as a simple table of contents, with a list of all pages in the space. This way, any information on the wiki is one click from the home page. As the content grows, some areas will grow faster than others. When a topic grows large enough that pages relating to it take up a lot of space on the home page, propose creating a second level table of contents page specifically for that content. This way, content grows in one place until it’s necessary to increase structure, but every increase is compact and directly tied to content growth.
If you encounter a wiki with too much anticipated structure, and lots of empty pages as a result, propose deleting those pages. This both lets others know what’s happening, and engages them in improving the organization of the space.
Including the word _wiki_ in the name of every space on your wiki is a dangerous habit because it confuses the technology with the purpose for using it. This is problematic because people should use the wiki with a purpose, not just because it’s a wiki. The wiki is just like any other technology tool in that it needs to be used with a definite purpose to really be successful.
Furthermore, putting _wiki_ in every name is the wrong type of branding. Organization, product, and project names should figure prominently in the name of a wiki space, along with a term that describes the function of each space. For example, when you name the wiki containing frequently asked questions about a product, call it ProductFAQ instead of wikiFAQ.
Once of the other problems with overusing the term _wiki_ in the names of wikis is that if a particular wiki isn’t successful, people may mistakenly associate the failure with the wiki, even if the failure has nothing do to with the fact that wiki technology was used. That mistaken association can make people less likely to use a wiki in the future.
Lastly, naming the spaces with product or project names instead of using the term _wiki_ is better because it encourages the people who are passionate about that product or project to get involved with the wiki not because it’s a wiki, but because of their passion for the product or project. That’s much more likely to ensure lasting success.
The Common Theme…
The common theme throughout all these patterns is not negative intent – it’s ignorance or misunderstanding. That’s much easier to deal with than purely negative intent, and demonstrates the importance of making sure people understand the wiki as a tool and grasp how it’s intended to work. Equipped with that knowledge, they’re much more likely to avoid anti-patterns themselves, and help others get back on track.