Sign up ×
Personal Productivity Stack Exchange is a question and answer site for people wanting to improve their personal productivity. It's 100% free, no registration required.

This question was originally posted on Programmers SE. I've placed it here based on advice in the comments.

We have recently polled our company wide wiki users and found out that there are two large groups of users:

  • people with lots of knowledge but (who claim they have) no time to document
  • people with time but (who claim they have) not enough knowledge worth documenting

Each group covered almost 50% of the users!

How do your companies handle this? That is, how do you encourage your busiest / most knowledgeable people to share their knowledge?

share|improve this question

4 Answers 4

I am one of the busy people in group #1. I document a lot because I don't have time to keep answering the same question over and over. A lot of questions are answered by linking to the wiki. Or writing an answer on the wiki and then linking to the wiki.

People in group #2 often need nudging. They think they don't have knowledge worth documenting but often do. I will ask them to document specific things when we come across it. That way it isn't always "the expert" documenting. Or I will ask them to document something they do know as part of showing a new person what to do.

share|improve this answer
I like this answer. Many people are intimidated by the thought of starting with a blank sheet of paper and ending up with any documentation worth having. It seems like only a subset of group #1 people are good at this. However, once these people prime the pump and there is something written down to serve as a template, guide, skeleton, whatever, then some of the folks with time who don't seem like they have the right knowledge will in fact be able to provide value. This will also make it possible for the busy folks to make value added additions in less time (thus making it more likely). – Adam Wuerl Oct 19 '11 at 22:14

The same way you get people to do anything - with carrots and sticks. Explain to them why its important and that they're expected to do so, reward them when they do the right thing, punish when they dont.

The bigger question is do you really need the busy people to train the others? Maybe you should look at the surgeon/surgery team model, where you have a few skilled people doing the work supported by others.

You haven't said so but its dangerous to assume that documentation is the best way to transfer knowledge. Often it gets outdated quickly and ignored or worse, confuses people reading the old docs.

Perhaps the best solution is assign the #1 group to a new project or time off and force the #2 group to do the work on the coalface.

share|improve this answer

I would argue with Richard's stick and carrot approach suggestion. If we assume that the busy people in the organization are busy doing meaningful work, then it's not about motivating them with sticks or carrots - they are obviously already motivate to do their jobs.

We should think how to make documentation as easy and as fast as possible for them.

The solution is simple - hire assistants to prepare the documentation on behalf of the busy knowledgeable people.

share|improve this answer

While it's important to assure the people in group 2 that they do have knowledge worth documenting, there is always a hierarchy, and usually your interns do have more time, and less knowledge than your veteran programmers. Here's a plan to help the situation:

  • Pair up people in group 1 with people in group 2. Let's call them the veteran and the intern.
  • Let them pick a piece of code that the veteran knows about. This is the code we're going to get documented.
  • Give the intern a day to try and figure out the code by himself, with the available documentation. Give the intern some standard tasks, like figuring out the main use cases, what does each method do, what's the starting point etc.
  • Now put the veteran and the intern behind the same desk. Let the veteran explain the code, but based on questions by the intern. It's important that the intern drives the conversation.
  • Let the intern draft a solid documentation. Give him time to really get this right. Make sure you have examples of what good documentation looks like. Give him something to strive towards.
  • Make the veteran review the documentation. The veteran can critique whatever he want, but he's not allowed to make any changes himself. The edits have to go back to the intern.
  • Repeat the above two steps a few times.

The benefit of this method is that not only do you end up with proper documentation, your interns start by learning how to document, before they learn how to code. What's more, everybody who puts himself in group 2 will actually work spend their time learning to increase their knowledge (ie. transitioning to group 1), while solving the documentation problem.

Just make sure that this process is properly codified, and that once a pair has been assigned a piece of code, someone will ensure that they finish the job. Perhaps a company-wide documentation manager: his job will be to figure out which parts of the code base are most in need of documentation, pair up a veteran and an intern, and ensure that they finish the job.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.