Oana Elena Florea, Customer Support ManagerFollowing the growing popularity of Wikipedia, “the free encyclopedia that anyone can edit”, the concept of building knowledge in a collaborative way became a golden rule. Many companies have been inspired by this open way of organizing information and have included wikis and collaborative software in their tool stack. At XWiki, we have embraced this philosophy at many levels throughout the company: building an Open Source product, fostering a collaborative and open culture and giving away most of our knowledge for free to the XWiki community.
It takes a village to build knowledge (every contribution counts)
No matter the business niche, offering open product documentation for users and clients is expected. However, creating a wiki-like xwiki.org and opening the product documentation to anyone who is willing to contribute is not an easy task mostly due to fear of bots, bullies, trolls or just mean people. All these reasons are superficial when considering the advantages of having more contributions:
- You build a “remote community” which easily multiplies the number of employees you can afford.
- You get feedback fast including product questions and bugs you never thought of.
- You get valuable contributions for free, including from people you might not expect, etc.
Knowledge can pile up, you need to plan for gardening
At XWiki, we manage several external knowledge bases for the product: XWiki documentation, community extensions, Pro extensions, FAQs and a community forum. It can all pile up with duplicate content, very long wiki pages and images that don’t reflect the latest product release. Gardening needs to be an ongoing process both as a pro-active activity, but also as a way to incorporate feedback from users and clients.
It takes courage to contribute and expose yourself to constructive feedback for content contributions or pull requests
As individuals fear is one of the main hurdles on our road to personal progress and innovation. It takes courage to face the fear of peer review or rejection (e.g. content contributions, pull requests).
Build a strong knowledge base both internally and externally
So often we focus all our effort on building the external knowledge bases for users (e.g. how to use the software) and we underestimate the need of our teams for managing the internal knowledge and avoid corporate amnesia.
An internal knowledge base for procedures is also an important tool to foster collaboration between less technical teams like HR who rely traditionally on email.
Some examples for an internal knowledge base:
- Private HR data and procedures (e.g. share interview results with a larger audience, share How-Tos to speedup employee onboarding, etc).
- Support procedures protecting private data from clients.
To sum up, the more you give to your community the more you will receive: build a knowledge base, a forum or any channel that you are comfortable with and give away free knowledge to your community. Users will give back bug reports (including blockers!), documentation and very good product questions you never thought of.
