Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

71%
+3 −0
Q&A What are some ways to encourage team members to contribute and maintain a centralized wiki?

I wish I knew. But I can at least outline where, based on long and bitter experience, I think the challenges lie. Finding a way to surmount them I must leave to others. The first problem is one of...

posted 4y ago by Mark Baker‭  ·  edited 4y ago by Mark Baker‭

Answer
#2: Post edited by user avatar Mark Baker‭ · 2021-02-09T15:28:12Z (almost 4 years ago)
  • I wish I knew. But I can at least outline where, based on long and bitter experience, I think the challenges lie. Finding a way to surmount them I must leave to others.
  • The first problem is one of visibility. Documenting things publicly benefits other people. You benefit from the documents they create. They benefit from the documents you create. So documenting something is rarely a direct benefit to you in the present moment.
  • That alone is a problem. But the bigger problem is that you usually have no idea if the document that you have produced actually helps anyone else. It is possible that you might get an email if they have a question or that they might come to your desk and give you a bunch of flowers in gratitude for your post, but for the most part you will have no idea that your document was ever read or acted on.
  • So the activity of documenting not only had no immediate benefit, you can't tell whether or not it has any long term benefit. It is hard to induce people do document things under those conditions. People don't mind doing work that benefits other -- but only if they actually see the benefit. So your first challenge is to make the benefits of documenting things visible. This does NOT mean writing memos generically pointing out the benefits of documentation. It means having people see the benefit that is created when the docs the write are read and acted on. This is why sites like this have voting buttons. But good luck with that in a corporate setting.
  • Second, the culture of Wikis is antithetical to Western ideas of intellectual property. Editing other people's work without their knowledge or consent is a deep-seated taboo. Yes, the work actually belongs to the company, not the person who wrote it. But in practice, that does not matter to most people. They don't want to edit other people's work.
  • There are four kinds of wiki contributors:
  • * The arrogant jerk who will happily throw out other people's work and replace it with their own -- and then zealously guard their version against any alteration.
  • * The overly respectful who might start brand new pages but never edits anything existing because they feel they belong to the original author.
  • * The feckless twit who will blithely change things written by people with far greater knowledge without doing research or asking why the current document is the way it is.
  • * The true wiki spirit who is not afraid to edit but is scrupulous in doing their research and making sure that they are truly improving something before they change it.
  • I'm leaving out the saboteur and the ideologue, who plague public wikis, but are not often a problem in corporate ones.
  • But the problem is, most people in your organization are not true wiki spirits. They don't have the motivation or the time. To make it work you are going to have to build and maintain a true wiki culture across the organization. And that is very hard to do.
  • Which is why most organizations eventually realize that if they want this done, they do, after all, need to hire professional documentation people and dedicate them to the task.
  • I wish I knew. But I can at least outline where, based on long and bitter experience, I think the challenges lie. Finding a way to surmount them I must leave to others.
  • The first problem is one of visibility. Documenting things publicly benefits other people. You benefit from the documents they create. They benefit from the documents you create. So documenting something is rarely a direct benefit to you in the present moment.
  • That alone is a problem. But the bigger problem is that you usually have no idea if the document that you have produced actually helps anyone else. It is possible that you might get an email if they have a question or that they might come to your desk and give you a bunch of flowers in gratitude for your post, but for the most part you will have no idea that your document was ever read or acted on.
  • So the activity of documenting not only had no immediate benefit, you can't tell whether or not it has any long term benefit. It is hard to induce people to document things under those conditions. People don't mind doing work that benefits other -- but only if they actually see the benefit. So your first challenge is to make the benefits of documenting things visible. This does NOT mean writing memos generically pointing out the benefits of documentation. It means having people see the benefit that is created when the docs they write are read and acted on. This is why sites like this have voting buttons. But good luck with that in a corporate setting.
  • Second, the culture of Wikis is antithetical to Western ideas of intellectual property. Editing other people's work without their knowledge or consent is a deep-seated taboo. Yes, the work actually belongs to the company, not the person who wrote it. But in practice, that does not matter to most people. They don't want to edit other people's work.
  • There are four kinds of wiki contributors:
  • * The arrogant jerk who will happily throw out other people's work and replace it with their own -- and then zealously guard their version against any alteration.
  • * The overly respectful who might start brand new pages but never edits anything existing because they feel they belong to the original author.
  • * The feckless twit who will blithely change things written by people with far greater knowledge without doing research or asking why the current document is the way it is.
  • * The true wiki spirit who is not afraid to edit but is scrupulous in doing their research and making sure that they are truly improving something before they change it.
  • I'm leaving out the saboteur and the ideologue, who plague public wikis, but are not often a problem in corporate ones.
  • But the problem is, most people in your organization are not true wiki spirits. They don't have the motivation or the time. To make it work, you are going to have to build and maintain a true wiki culture across the organization. And that is very hard to do.
  • Which is why most organizations eventually realize that if they want this done, they do, after all, need to hire professional documentation people and dedicate them to the task.
#1: Initial revision by user avatar Mark Baker‭ · 2021-02-08T14:38:44Z (almost 4 years ago)
I wish I knew. But I can at least outline where, based on long and bitter experience, I think the challenges lie. Finding a way to surmount them I must leave to others. 

The first problem is one of visibility. Documenting things publicly benefits other people. You benefit from the documents they create. They benefit from the documents you create. So documenting something is rarely a direct benefit to you in the present moment. 

That alone is a problem. But the bigger problem is that you usually have no idea if the document that you have produced actually helps anyone else. It is possible that you might get an email if they have a question or that they might come to your desk and give you a bunch of flowers in gratitude for your post, but for the most part you will have no idea that your document was ever read or acted on. 

So the activity of documenting not only had no immediate benefit, you can't tell whether or not it has any long term benefit. It is hard to induce people do document things under those conditions. People don't mind doing work that benefits other -- but only if they actually see the benefit. So your first challenge is to make the benefits of documenting things visible. This does NOT mean writing memos generically pointing out the benefits of documentation. It means having people see the benefit that is created when the docs the write are read and acted on. This is why sites like this have voting buttons. But good luck with that in a corporate setting.  

Second, the culture of Wikis is antithetical to Western ideas of intellectual property. Editing other people's work without their knowledge or consent is a deep-seated taboo. Yes, the work actually belongs to the company, not the person who wrote it. But in practice, that does not matter to most people. They don't want to edit other people's work.

There are four kinds of wiki contributors:

* The arrogant jerk who will happily throw out other people's work and replace it with their own -- and then zealously guard their version against any alteration.

* The overly respectful who might start brand new pages but never edits anything existing because they feel they belong to the original author. 

* The feckless twit who will blithely change things written by people with far greater knowledge without doing research or asking why the current document is the way it is.

* The true wiki spirit who is not afraid to edit but is scrupulous in doing their research and making sure that they are truly improving something before they change it.

I'm leaving out the saboteur and the ideologue, who plague public wikis, but are not often a problem in corporate ones. 

But the problem is, most people in your organization are not true wiki spirits. They don't have the motivation or the time. To make it work you are going to have to build and maintain a true wiki culture across the organization. And that is very hard to do. 

Which is why most organizations eventually realize that if they want this done, they do, after all, need to hire professional documentation people and dedicate them to the task.