My BSc thesis was about knowledge management and this subject has always got my attention when it comes up. I work for an infrastructure consultancy company whi

My BSc thesis was about knowledge management and this subject has always got my attention when it comes up. I work for an infrastructure consultancy company which employs 300+ engineers/consultants/architects over a wide range of customers. The main issue is what I call the "content versus context" problem. For example: A new engineer comes in and has a basic skill of a certain technology. Let's say he/she is well educated in Cisco routing and switching technologies. So the "content" of a certain technology space should be no problem. The challenge is the context: How does "skillset x/y/z apply to customer x/y/z" in which the specific customer operates in a certain context with its own constraints etc. In the aforementioned example: How does customer x/y/z uses Cisco technologies in what kind of architecture serving which specific services? The context is key and exploiting (in the positive sense) this knowledge is what you typically strive for to get employees up to speed with a new customer. The issue is (what you describe) how to make this contextual knowledge tangible and searchable in the least frictionless way. Within my shop there were different trains of thought: 1. Using fileshares grouped by customer (but this needed updating and not all employees uses those shares to file their work. Let alone the fact that sometimes it is not permitted to store confidential stuff on our own fileshares. We also do defense contracting work so that is a big no-no) 2. wiki's (already mentioned here), but this needed constant updating and for some the actual "coding" and using the markup language of a wiki was too much of a boundary 3. Using Yammer/Slack etc. This works OK as it is pretty low level, but it needs a certain critical mass to use and when you have 300+ employees with all kinds of customers who might also use their own Slack/Yammer what-have-you it's hard to get the employees conditioned to also check the internal channels each day/week. We finale settled at the following mechanism which is a nice starting point to solve the "content/context" problem namely using the resumes each employee has to keep updated (and fiercely enforced by HR) and using a smart search algorithm to find the best knowledge-match of each employee. It doesn't work flawlessly and it had to be customized for us, but it works better than other methods. It's still a two step approach: 1. Search the CV for the best content-context match 2. Call/mail/IM the colleague and try to figure out if his/her knowledge helps you in tackling the issue you have. Another method I saw someone use (and apply within a large online retailer) is to "tag" each person with his own knowledge set and visualize the links between them. So, again using my field of work as an example: Bob has a lot of knowledge (explicit in the form of certs etc.) of Palo Alto firewalls and is considered the internal "guru" in this specific field. The more Bob gets consulted for his knowledge the larger his "circle" of knowledge is (you can actually visualize this). What you eventually build is a knowledge graph were each point in the graph represents an employee with a certain knowledge set and every time he/she gets consulted for that specific knowledge by another employee a line is formed. This is a very powerful system but requires maintenance to update the knowledge sets. Setting this up requires interviewing each employee with questions like: - What is your skillset and how do you score on a scale of 1-5 (or whatever scale one sees fit) in this specific set? - Who consults you the most for this knowledge set? - Who do you consult the most for which knowledge? The end result is the aforementioned "chart" with "dots" representing ones knowledge. The larger the dot/circle the more knowledge one has.