Every month I review the search terms that lead people to our Knoco website, just to see what people are searching for. A common search term that came up again this month, is "How to incentivise knowledge sharing".
I thought it was worth a blog post on it's own.
The simple answer is Don't!
Don't incentivise it; or at least, not directly. Instead, make Knowledge Sharing part of "doing a good job", and incentivise doing a good job.
I think this question often comes from people who have developed a Push system for Knowledge management, sitting in the Explicit Push quadrant of the diagram shown here. This is perhaps the least effective way to start with Knowledge Management, as I have discussed many times. But if you have decided to start here, then probably you have built a "knowledge repository", or perhaps a wiki, and it's probably sitting there mostly empty, and you are probably relying on people to start to populate it. So you think - how can I encourage them to post material? Can I pay them? Can I reward them? Can I nominate "sharer of the month" who gets a nice reward?
All of these ideas are seductive, but dangerous. All incentives like these can be gamed, and the gaming will be counter-productive. By providing incentives which are separate from normal job incentives, you give the message that Knowledge sharing is not part of the job, so needs to be incentivised separately.
So what do you do?
Firstly, make it clear that Knowledge Sharing is part of the job. If you need your sales reps to put knowledge into the CRM system, then write it into the company expectations. Just as timewriting is an expectation, or performance appraisals are an expectation, so knowledge entry should be an expectation, in this case. Or entering lessons into a lessons system - make it part of the project expectations, and the project doesn't get management sign-off until the lessons are done. Or if you require a company expert to own or edit part of a wiki, write it into their job description.
Secondly, reward people for performing against their expectations. Whatever conversations you have about performance, knowledge sharing needs to be part of that conversation.
Imagine a conversation at the end of a project - "Good job; delivered on time, to budget, and a really really great set of lessons for future use, that should save us millions down the line"
Imagine a conversation in a performance appraisal - "you did well with these objectives, but your Knowledge sharing performance was not great. I dont see any contributions from you in the forum, or in the wiki. What happened there?"
in both these conversations, knowledge sharing is part of a broader performance conversation, not something separate.
Thirdly, it does no harm at all, and is positively beneficial, for the community coordinator or the KM coordinator of the knowledge base, to publically thank the good contributors. See for example this post about community recognition. But the point is that this is not management recognition, so doesn't muddy KM recognition and job recognition by introducing a separate recognition system. Any such peer recognition can be referred to in the job appraisal, and the community facilitator or KM coordinator can let the manager know that "X is doing a great job in delivering against KM expectations".
Fourthly, you use the Nudge principle of peer pressure. You publish, to management, league tables of KM activity. You highlight the divisions that are sharing freely, and the ones that aren't sharing at all. You publish these at a high enough level that the managers don't want to look bad in front of their peers. Then you let the managers sort it out in their own divisions, through the normal chain of command. You can imagine the conversation - "Guys, we were shown up again in front of the CEO as being the division that shared least knowledge this past quarter, and by a very long way as well. You know how interested he is in this at the moment. Can you please raise this with your business units? I don't want to be bottom of the list again next quarter." This is not the same as setting targets and quotas, this is making people aware of activity, so they can take action.
I would much rather use these four, or a combination of these four, rather than any discrete incentives for publishing knowledge.
But please don't forget to address knowledge seeking as well, and also the entire tacit domain. Sharing without seeking can be a waste of time. If you focus only on Explicit Push, you miss 75% of Knowledge Management territory, and it is the more powerful 75% that you have missed.