What are some ways to encourage team members to contribute and maintain a centralized wiki?
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).
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
There's no quick or complete fix, but the following things have worked for me.
Plant the seeds early
First, involve those new hires. When everything is new to them, you are in a better position to plant "culture" seeds. Maybe your old-timers have gotten used to not documenting anything, but they are no longer the only people on the team.
As part of onboarding, we point newcomers to our existing documentation (wiki), and we tell them there are probably some omissions and things that aren't as clear as they could be and maybe even some things that are no longer true. (We went through three corporate acquisitions in five years; our IT-infrastructure pages were kind of a mess.) We ask them to update things that need it as part of their onboarding process. We also show them where to get help if they're not sure what it should say (this is wrong/missing but don't know what's right). Editing is easier than creating new documentation, so start there.
Use the wiki for more things
You're using a wiki for process documentation, it sounds like. That's good. Are you also using it for functional specs, roadmaps (what are we doing over the next few releases?), meeting agendas and notes, team-specific information? Do people have personal pages?
In my experience, people will use the tools that people are using in the ways they see people using them. Our chat integration is probably not the best way to manage automated tests, but it's where people are so we send reports there. The wiki might not be the best place for meeting agendas, but since it is a good place for notes from those meetings, it's natural to keep them together. And by all means, include the fun stuff too; in the pre-pandemic times we had occasional team outings and we posted pictures there.
A goal of all this is to make the wiki a natural stopping place, something that people will tend to keep open in a tab or several. Once people are there, people are more likely to fix stuff.
Ask for specific help, not general appeals
Don't ask people to write unspecified stuff. For some people, even asking them to document a specific process might be too much at the start, without managerial support and more of a team expectation. I try to draw people in by asking them to review or update stuff -- hey $busy-senior-colleague, I think this description is mostly accurate but I'm not sure about a couple points; could you make a pass over it? Even if you can only get them to review and not update, and you have to make the changes yourself, you've at least gotten someone else involved in the information content. It's a start.
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.
How do I encourage a community mindset ... not just viewed as "Sigma's project"
You don't. This is your manager's job. Talk to them. Make some suggestions. But in the end, this is their call, and not your job unless they explicitly make it your job.
You say management "fully supports and encourages" people writing documentation, but that's a long way from it being part of everyone's job. When someone finishes a task and tells management, does management say "Great, show me the documentation"? If there isn't any, is the answer "Then you're not really done yet. Come back when everything is finished, including the documentation"? If there is documentation, does somebody actually review it?
Until the answers to each of these questions is "Yes", management doesn't consider it important, and therefore neither will your co-workers. Why should they? It's not their job. They have other tasks assigned to them that management does care about seeing done.
Also keep in mind that doing something and describing it are two different skills. You may not like the mess of a result if the doers who are not good at writing are forced to write anyways. Even worse, they may not like this change in their job description. It's not what they signed up for, and possibly not what they want to spend their time doing.
So in summary, either management gets behind this for real and sees that it's done right, or it will never be what you want. If the group is large enough, then it will require a dedicated writer to work with the team to document their processes.
0 comment threads
0 comment threads