If in the opening phase of a wiki adoption it should be difficult to activate employees to participate, this is often because employees haven’t been properly brought up to speed and misunderstand the whole idea of a wiki. One symptom of this is the fear of sharing knowledge.
This blog post is also available as a guest article at Atlassian’s Confluence Blog.
Why do employees have qualms about sharing their knowledge?
At the most basic level, each employee’s knowledge is his or her most valuable possession: They have been employed by the company due to their knowledge, and their own know-how symbolizes their right to be in the company. Now, however, the employer is hoping that this employee will make his or her knowledge available to everyone at a central location.
Our project experience has taught us that many employees fear this change as leading to a loss of power or even a drop in their value to the company. The following thought process probably goes through the heads of many employees as the wiki is being introduced:
Why should I give everyone access to my knowledge? That will just make me less important to the company, make it less likely that I’ll climb the ladder, and might even make me expendable. I would actually be working toward the lessening of my own “market value”!
It is likely that nearly all employees will find themselves in such an emotional state when their employer requests that they depict their knowledge in the enterprise wiki, and is a challenge that must be met as you work toward a successful and productively useful enterprise wiki.
The misunderstanding: Information vs. application of knowledge
The basic misunderstanding consists of the following: What should employees actually share in a wiki? Extremely simplified, we divide knowledge into data, information, and application of knowledge, which means 1) pure data, numbers and facts, 2) the data placed in a certain context (information) and 3) the application of information in a particular situation.
This ability to use knowledge correctly within a context is the reason why the company has hired an employee and continues to keep him or her on staff; this is why he or she is valuable to the company. And this cannot be captured in a wiki document. Employees shouldn’t put any knowledge at all into the wiki, but rather data and information.
One example: I can summarize the data from a study on the topic of enterprise wikis into a wiki document. I can also interpret these data in the wiki and place them into the context of the challenge of employee activation. But I cannot depict in the wiki how I will use the data and information in a particular project situation, for instance, when somebody asks a question in a Wiki-Workshop. I also cannot depict how I would develop an individual activation strategy using the available information, a strategy taking into account the specific requirements of a customer. And I cannot put in the wiki how I would create a coherent, understandable blog article about the fear of sharing information. That which defines the “market value” of an employee in a company cannot be depicted in a wiki.
The wiki-dashboard gives something back to employees
Still, one could point out that employees would lose their exclusive control over certain information. This is certainly correct. But an expert who is not perceived as an expert within the company is ultimately more assailable than a colleague who has put information in the wiki and whose expertise is known throughout the company.
This brings us to the important role played by dashboards, which are a part of every professional wiki system: When an employee, for instance, loads the start page of Confluence, he immediately sees who has executed which changes and when. All employees can see: This colleague obviously has the know-how, he can contribute something to the wiki, he is an expert in a certain area, and you can go talk to him regarding problems in that area. The result is a broad and growing acknowledgment of expert knowledge throughout the company. In fact, the employee’s growing reputation makes him or her even more attractive as an employee.
Fewer internal content questions lead to higher productivity
And that’s not all: If an employee enters exclusive information into the wiki for central access, this will automatically reduce content questions by e-mail (or even visits in person) which means a reduction in time spent working on the wearisome processing of technical problems using e-mail. The effect is clear: The employee has more time for productive work and to be engaged in projects. Due to his activities in the enterprise wiki, he is more productive and, at the end of the day, more valuable than before.
In other words, the result is the opposite of many employees’ initial fears: Through the centralized depicting of portions of their expertise, many users will actually become more important and can make themselves better known as experts. The fear of sharing knowledge is based on a misunderstanding: It is unfounded as the gains in increased reputation and time for productive tasks clearly trump the employees’ loss of exclusivity over some know-how.
This argumentation should be a component of every introductory strategy. //SEIBERT/MEDIA would be happy to support you in the developing of such a strategy.
Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis.
Read this article in German.
Architecture of a Wiki-Project: Elements, Process, Approach, Rules
Architecture of a Wiki-Project: Customers’ Frequently Asked Questions
Factors for the Success of Wikis 1: Technology is important, but not King
Factors for the Success of Wikis 2: Organization is the Key
Factors for the Success of Wikis 3: Overcoming Resistance from the Company Culture