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

Dashboard
Notifications
Mark all as read
Q&A

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).

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

0 comments

3 answers

+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.

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

1 comment

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. Sigma‭ 3 months ago

+2
−0

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.

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

2 comments

I've suggested we use Jira for task tracking (currently we use Excel - hooray Finance!), but perhaps I will bring this up again. Everything else just lives in our fileshare - we don't have ceremonies that produce the usual templated notes a dev team might want. Adding general team info though is a great idea! Sigma‭ 3 months ago

File shares become write-only kitchen junk drawers, in my experience -- it's easy to add stuff but harder to find and organize it, and actually maintaining it is even harder. Jira would be an improvement for you because of the integration with Confluence, which you're already using. For example, we embed Jira queries in some of our Confluence pages, feature specs link to their tracking Jira tickets, and so on. Monica Cellio‭ 3 months ago

+0
−0
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.

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

0 comments

Sign up to answer this question »

This community is part of the Codidact network. We have other communities too — take a look!

You can also join us in chat!

Want to advertise this community? Use our templates!