nerdleader

Everything about knowledge is hard. It can be hard to translate it from our thoughts into words. It can be difficult to write it down correctly and create the correct diagrams and illustrations. It is hard to keep it up to date in a timely fashion, and it is certainly hard to learn new knowledge! And it can be incredibly difficult to find time to create, update, and share new knowledge. We can all do a better job of leading this process if we learn from sites like Wikipedia and ensure everyone can have a voice and participate – with governance.

I truly mean everyone should participate – I have been around the block a time or two and everyone has unique perspectives and insight that they can offer. Surely not everyone is equal when it comes to quality or quantity of output, but you never know in whose hands a particular gem of knowledge lies. But what does it mean to democratize the knowledge management process? For starters, like in any team activity you, as the leader, must ensure that all voices are being heard and that everyone has a role to play. See that everyone feels comfortable sharing their thoughts, opinions, and knowledge, but also give specific direction and tasks to individuals who do not seem to be invested or interested. The most obvious (and likely easiest) way to do this is to incorporate a wiki into your knowledge ecosystem. If you are using Jira, you should think about using Confluence, but all enterprise platforms seem to have wiki components.

As you proceed, please spend time thinking about the way you are going to structure your documents. We are blessed to have sophisticated searching mechanisms at our fingertips, but the knowledge discovery process is improved by finding related information to the topic(s) at hand. When using a partner’s API, for example, finding the documentation on the API itself and its inputs and outputs is key, but finding out that there are other related APIs, new versions, etc., might only be accomplished by looking at the full API documentation and seeing what is near the functions being used. I find that hierarchical organization is best, with architecture and business documentation arranged under its relevant project, but then linking to those documents from higher up in the hierarchy, whether by product, team, P&L, or what have you. By linking instead of copying, you ensure that there is only one place to go to update documentation, and the updates are instantly available in other parts of your knowledge tree.

Next, ensure that you have a policy to create documentation and knowledge as part of the product creation process. Give your teams the time to document – not just at the beginning and end of a sprint or cycle, but within the sprint ensure that some of the productive time is allocated to documentation. Yes, it may change slightly more frequently if your developers are keeping and sharing notes each day on what they are creating, but I have yet to see a team that has not been able to manage this effectively. It has an additive effect of keeping other teams aligned on progress and approach and easing onboarding and team composition change. If you are using a wiki, creating and updating the documentation each day is supremely easy, but if not, use your modern business tools like Office or Google Docs and create shared documents that the whole team can access.

At this point your teams are creating voluminous documentation and linking it throughout your knowledge tree. Ensure that you are using best practices for guiding this flow of information and enhancing its accuracy and authority. Turn on the available document versioning feature in case of error or loss. All modern shared documentation platforms have this feature, and it is supremely easy to be able to roll back incorrect changes or compare multiple versions of documents. Also, make sure you are making good use of the “draft” and “publish” features where available. This will allow you to only version and communicate authoritative “published” versions of documents while also allowing the team to collaboratively edit each “draft”.

Once you have each member of your team participating in the documentation process, have efficiently organized your information, ensured that it is incrementally updated, and implemented appropriate editorial guidelines, you will have evolved beyond mere “documentation”. You will have created an efficient knowledge management engine without needing separate information managers or architects. Yes, in large companies, information architecture and knowledge management are large investments requiring dedicated experts, but these experts are advisors and outside of the knowledge creation and update process. It is up to you, as a leader, to ensure that your team efficiently owns and drives the knowledge sharing process.