I've worked for large companies and I've worked for small companies. In every place I've worked, few places have knowledge management down solid.
It's such a simple thing, though. Humans have done it for many, many years. How do you onboard someone quickly and get them up to speed?
At a former employer, we would do these meetings called KT (Kay-Tee) or Knowledge Transfer. Essentially, the knowledgeable would present to the ignorant and that was it.
What made matters worse, I would get roped into KT meetings that had nothing to do with my role just for the sake of it. There was little value in them. I made it a point to future presenters to write me good documentation instead and just use that time to go over the documentation.
I've been on the other end leading KT meetings as well. I would write exhaustive documentation. Share the documentation ahead of time. Present the documentation to my team and give a demo. I would still get questions over stuff later.
So, what's your thinking Dev.to? Does tribal knowledge work? Or externalizing tacit knowledge and codifying it? What use is documentation if no one bothers to read it?
Top comments (4)
tl;dr: in my mind, knowledge transfer is broader than documentation and valuable because some things don't transfer as easily in writing
I am a professional writer. I write API docs, so I come to coding from that perspective.
Many people have been trained not to read by writing that wastes time: too many words, too little clarity.
Good writing is clear, easy, and explains to users what they need when they need it.
You can generally tell if your writing is working. The test is whether people read it instead of "calling customer support," whatever "customer support" may be in the context. But yeah, if you write a ton of dense crap that requires a PhD in linguistics to parse, burying key facts like Easter eggs, don't be surprised if your "reader" just phones a friend instead.
Some things should not be put into writing. For example, I would not write to a new coworker, let alone put in Confluence, "Don't talk to X because he's a useless waste of life." Even if it were true and however much I'd need to warn the new coworker, such things should not be written.
Other things are more complicated and the writing works best as a reference or an accompaniment to an interactive conversation. This case is especially common when there is little time and a lot to explain.
IMNSHO, tribal knowledge is frustrating and fragile because people get hit by buses, win the lottery, or just forget. Writing is the solution. In my experience, the number one thing missing from most engineers' writing is just a bit of engineering. Good docs have a logical architecture, know their goal, deploy tools, and solve a problem.
KT is best when the host is also explaining things about the project, and not essentially speaking documentation. The person receiving it should learn the context of why things are the way they are and the team's stance on the project's components. Could this be conveyed in documentation? Sure, but it's easier to convey the emotional side of things in person than it is in text.
If you think about it as an opportunity to interact with the presenter and get their gloss on why, it can be a bit more interesting and valuable.
For my part, "KT" usually meant waking up early and listening to someone drone on about something I knew I would never ever interact with and them resisting attempts at being personable. As much as it is theoretically valuable, I would prefer never to hear the phrase again.
I find that everyone consumes information at different rates, and possibly none of these rates is the same as the rate you are delivering it.
TL;DR
So, you must not only present the info in a concise and interesting way but provide an effective means of allowing everyone to consume at their own pace. These can include:
Offline resources (e.g. handouts or downloadable files)
Online resources (e.g. online presentations, forum or wiki).
The best would be a place (forum or wiki, e.g. Slack channel) where your audience can interact with each other and with you to ask and answer questions, give tips and small demos, feedback, etc.
KT is deathbed talk, documentation is memoir after you're gone.