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

Comments on What are some ways to encourage team members to contribute and maintain a centralized wiki?

Parent

What are some ways to encourage team members to contribute and maintain a centralized wiki?

+2
−0

I joined my current company and department a few years ago. We had some documentation for processes but most people had been around for a long time and never needed it, so it was very sparse.

Since we had access to Confluence (an internal documentation / wiki platform), whenever I learned a new process I took notes and added documentation. This has been a huge resource in training new hires, as they no longer have to create this reference information themselves. My management fully supports and encourages it; it has reduced errors and been helpful in audits as well.

However, I am the only one who makes any significant effort to keep the information up-to-date and expand it. Some of the processes I'm no longer responsible for, but the team members currently doing them don't update the wiki to reflect changes. Others will happily use the documents I've created, but don't want to post documentation of the processes they currently own - they don't think it's good enough.

How do I encourage a community mindset in my team where the wiki is not just viewed as "Sigma's project" but as something everyone contributes to and benefits from? I have a good rapport with my team and the support of management (though I'm looking for a more indirect approach).

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+3
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (1 comment)
General comments
Sigma‭ wrote about 3 years ago

At the moment my department is only ten people, and we really value problem solving and supporting each other. I think our main issue might be that most fall into your "overly respectful" category - well intentioned but unsure what needs to be done. I'm trying to encourage more engagement, but it's difficult to bring people out of their shells.