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?


You can point out to the knowledge holders that they are likely spending a lot of time getting pestered by questions anyway. Writing a wiki entry is a short term investment that pays off in the long run. If they aren't getting pestered by questions, it's probably not important enough to document.

Also, the knowledge receivers are a better choice to write a wiki article than you might think, because they understand the point of view of someone who needs to learn the topic. It also helps organize and solidify their thoughts. Having someone with more time write the article and run it by the guru for review could be very beneficial.

| improve this answer | |
  • 6
    +1 for having the receiver write it. Sometimes a holder and receiver will understand the same sentence differently. – Atif Apr 12 '12 at 21:54
  • 1
    Agreed on having the receiver write it, but have the knowledge holders / experts review it on two fronts: Correctness and Completeness. Good documentation explains both the How and the Why. – voretaq7 Apr 12 '12 at 22:23
  • 2
    +1 Assuming knowledge holders are good at documenting as well is a fallacy. Not to mention precious time and some good karma we will save by putting right people for the job. – mixdev Apr 17 '12 at 20:23
  • 2
    @voretaq7, actually, one of the big advantages of a wiki is the editing. Go ahead and post what you learned, mark the parts you're not sure of, and let either the SME or the next person who needs to know this build from there. – Monica Cellio Apr 18 '12 at 21:51
  • @MonicaCellio Agreed - Wikis are great resources. Unfortunately the community-editing can also be a disadvantage when someone edits in misunderstood/incorrect information and forgets to mark it as "uncertain" -- Ultimately a Wiki is only as good as the people who review it for correctness :-) – voretaq7 Apr 18 '12 at 22:29

One of our tech leads has a great policy, the third time she gets the same question, she writes up the answer and emails it to the person asking and to the knowlege wiki we have set up. Since she was probably going to write that email anyway, the only additional work is to add the address for the Wiki.

| improve this answer | |
  • 2
    Good general policy - if you've been asked it three times it's important to document. As a bonus you've probably also thought about it enough to have a good, coherent answer to make into official documentation. (This is also the rule I use for automating tasks: The third time it has to be done, it should be automated) – voretaq7 Apr 12 '12 at 22:35
  • 3
    @voretaq7, I thought the part about hooking up the Wiki to an email to revie wiki topics was inspired myself. So much easier to document knowldge when all you have to do is add another email address to an email you were going to write anyway. – HLGEM Apr 12 '12 at 22:42
  • 2
    Why wait three times, if someone has asked the question then odds are that someone else will, so document it then e-mail them a link to the updated docs. Scott Hanselman talks about the idea of conserving your keystrokes on his blog here: hanselman.com/blog/DoTheyDeserveTheGiftOfYourKeystrokes.aspx – ridecar2 Apr 13 '12 at 14:58
  • 1
    @ridecar2 I'm no expert but I'd say the same reason I wait until the third time to automate a task: Sometimes you doing it yourself is the faster/better solution if it's only going to happen once, and often you don't know it's going to be a repetitive thing the first time. By the third time you're usually approaching a cost-benefit tipping point where it's obvious the task is going to keep popping up and the work to document or automate will definitely pay off in the long run.. – voretaq7 Apr 14 '12 at 5:24
  • 2
    There is no extra cost to doing a blog post to doing an e-mail, so why not do the blog post straight off? I agree on automation of tasks where setting that up is tough, that's not what I was on about though. – ridecar2 Apr 16 '12 at 0:46

I suggest recording screencasts of about 45 mins. Get everyone together and the presenter does a screencast and transfers the knowledge. It's easier and more effective to show how to do something, then just written documentation (which might also include extra time for formatting, etc.)

At one place I used to work, they had a "Lunch n'learn" on a weekly or monthly basis. One guy eats lunch early, and does a presentation for the team while they eat. This might work if people are strapped for time.

| improve this answer | |
  • 2
    +1 great idea! We had a similar idea, and the company would provide lunch to encourage participation. – tehnyit Apr 17 '12 at 16:03
  • Lunch and learn is a horrible practice. If it is important enough to do training on, it should be done when you are on the clock not during a break, Lunchtime should NEVER include work. – HLGEM Apr 18 '17 at 17:01
  • @HLGEM - I am a HUGE believer in Lunch & Learns. However, they were never counted as break time when I was involved. I also believe that the subject-matter-expert on a particular area should NOT be the one putting on the presentation. The best practice I've seen is to put mid and junior employees in charge of preparing the presentations. They come to it with fewer assumptions and make it more approachable. and when they are prepping for it, they learn it. – Wesley Long Apr 18 '17 at 18:29
  • I am not against this sort of training just that it should never be done at lunch which is usually not paid time and does not belong to the company. It is just as bad as asking me to do training after dinner. There is a good reason why lunch breaks are mandated legally in many jurisdictions. – HLGEM Apr 18 '17 at 18:51

The best way to transfer knowledge is for the people who need the knowledge to work with those who have the knowledge.

Whilst the knowledgeable people may not have the time to work on documenting their knowledge themselves, they may already be spending some of their time explaining to others what to do and how to do it.

Even if the knowledgeable people had the time to write up their knowledge, it is not necessarily the case that the documentation they produced would be of use to the less knowledgeable people. It is surprisingly easy to miss out important 'obvious' information when trying to impart knowledge.

By making the knowledge transfer more explicit and co-operative, and having the users of that documentation write it so that they can understand it, you could both ease the burden on the knowledgeable people and get more information transferred.

If the knowledgeable people are really pressed for time, you could ask the people who need that knowledge to write up what they understand now, and then have the knowledgeable people proof-read and correct any misunderstandings. This could substantially speed things up, and could also help identify areas where the knowledge is lacking.

As an example of this, I work on scientific software. Neither I nor the facility scientists I work with could, alone, document much of the software I write. I could explain what my software does and even why it does it that way, but it's the facility scientists who need to write documentation on why and how visiting scientists should use it.

| improve this answer | |
  • Indeed, this is exactly one of the solutions we considered; it is similar to the apprenticeship idea. As an addition, the apprentice (who probably does have more time) can than document what they have learnt. – Reinstate Monica - Goodbye SE Apr 17 '12 at 15:11

My suggestion is to budget documentation time into every project and make it part and parcel of what you do. If you haven't been doing that all along you probably need to schedlue "Documentation Days" to jumpstart things (for example, say every Friday after lunch those with the knowledge are freed from all other projects and just work on writing documentation).

It can be hard to get the documentation culture into a company when it's never been part of the way things were done before, but the rewards are evident when you can hire a new person and have them up to speed and working independently within a week -- For example, the PostgreSQL project has a strong culture of maintaining excellent documentation. Their manual is better than some commercial products.

| improve this answer | |
  • In principle I agree, but I've seen many times that documentation has been skipped because of short term thinking with a project deadline. – Reinstate Monica - Goodbye SE Apr 13 '12 at 4:31
  • @Wikis Bad Corporate Culture IMHO. Documentation is part of the product (in my case, literally: international standards and federal regulations require it for medical device manufacturers, so I don't have to argue too much about it. I'm lucky :-) – voretaq7 Apr 13 '12 at 4:35

There is an unfortunate trend in my experience when it comes to knowledge transfer and that is the lack of interest on the receiving end. You could have the person willing to do the brain dump to someone else but if there is no interest in its receipt why would the expert take the time?

When I was leaving several places where I worked I was asked to do this because I was one of the very few people who understood the systems I was supporting but when someone was assigned to me for this task I could see in their demeanor that this was bothersome to them and they had no interest in it. So my motivation to do the knowledge transfer was basically reduced to nothing.

So the only thing that I could suggest on the subject is make sure the person receiving knowledge is actually interested in the subject. Captive audience that asks questions does wonders for motivation of the speaker.

| improve this answer | |
  • +1 - As one of the "busiest people" I often find it's hard to get time from everyone else to properly train them. – voretaq7 Apr 12 '12 at 22:15
  • 1
    +1 - @voretaq7 - There have been many times when I've suggested to others that I might explain to them why or how I did something and had them say they didn't think it was necessary. So maybe part of the issue is having willing knowledge receivers. – Tech Lover in NYC Apr 14 '12 at 4:09
  • @Giliane Sounds like separate but closely related problems that lead to the same end: In my case the knowledge receivers actually wanted to learn, but either they were genuinely too busy when I had time to teach or their supervisors would refuse to let them have downtime for training because the supervisor didn't see the value. – voretaq7 Apr 14 '12 at 5:22

I always try to set up a wiki in order to document things. Wikis are simple and encourage adding bits and pieces as time goes by. With formal documentation systems, the blank paper seems overwhelming to the users and as a result only gets filled out when you put a gun to their head. I usually walk around with a notebook, and I'd enter things in the wiki so that they can be located easily - this way, annual tasks can be repeated correctly rather than having to rediscover how they were supposed to happen.

One previous boss was only willing to permit "full and complete documents" which were never done. He banned wikis because he believed that they encouraged lax thinking and poor documentation. Since the previous "full and complete documents" were all 5+ years old at the time I left, he did not care to comprehend that his desires were in direct opposition to how his staff worked.

Only in the direst emergency when one critical person left, he made and recorded webcasts of walking through the code that only he understood. This was one of the few times that when an employee gave notice, that he transferred knowledge, instead of working on stuff until the day he left.

| improve this answer | |

This is really a policy problem, not a motivation one. Employees with critical knowledge should be given the opportunity and to document it and it should be mandatory. If they do not provide ample documentation and their supervisors have given them enough "free" time to do it, they should be disciplined.

No matter how much a person knows or can accomplish, if they are the only one with that knowledge, then they are a liability. Documentation shouldn't be optional.

| improve this answer | |
  • 1
    I think that "discipline" is a [likely] bad approach - so long as the employee(s) are staying productive, penalizing them will only encourage them to leave: which will defeat the purpose. Instead of negative reinforcement, use positive reinforcement - some form of incentive/benefit to providing documentation. – warren Apr 20 '12 at 13:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .