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?
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).
Post
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.
0 comment threads