I believe the number one problem you will run into is what happens to every wiki in the world. Knowledge goes stale and discovery is hard. Especially when you don't know what to look for.

Making content is never the answer to passing on institutional knowledge. This problem was actually solved very effectively a long time ago by trade unions such as the masons.

Start by having an apprenticeship program. Shore up any missing skills and teach someone how to apply them at your institution. Go into the meaning of why you are teaching them.

Second, set up a simple progression where one builds a base of understanding to move to the next phase of institutional understanding. Apprentice (learning) -> Fellow (perfecting) -> Master (can teach).

Masons don't even write anything down and have managed to pass on institutional knowledge for generations. Martial arts communities are similar.

Isn't there a catch, at least in the US, that companies don't want to invest in training/mentoring because they believe once they reach a certain level the people will just leave and employees that don't feel like they're being trained/growing in their role will also start to look to new pastures, esp. if pay is keeping up with their skills?

I was recently laid off from my job. I was #2 in a two-person IT team (#1 had been there for 20 years). I came wanting to be mentored and to learn but the string of broken promises and lack of any sort concrete plans left me adrift so I continued to self-train. After expressing this sentiment to the boss, thinking an open and honest dialogue about where I hoped to be and that I felt neglected in terms of the company investing in me (whereas the other users received an educational stipend, paid for professional study and exams, etc.), I was told we'd come back to it after our office move earlier this month. Well, we did, and I was let go.

I don't disagree with your main point, and I think the apprenticeship model could work wonders in many tech environments. Harder to implement when you have a very migrant worker population, even at normal rates of turnover.

There is however some merit to writing down details to critical or seldom-used processes in a communally-accessed place such as a wiki. Keeping it up to date and having someone review it regularly has to be part of the process.

Build instructions, and dependency assumptions for starters.

Sometimes the hardest part is just figuring out how to get a project running, or learning what kinds of settings need to be enabled on deployment.

As for craft and actual in-code understanding, I think the masonry example can fit well (see pair-programming as a more fluid example of this). Granted, if you have an API, you probably want to at least document the interface with an example of how to call it. The complex bits of "how is this architect-ed can be better taught by 1:1.

I'm thoroughly sick of advertising masquerading as content. Not that it this anything new, but I still wish ill on those who waste my time so. And it seems to be on the rise in recent years.

This is a puff piece for their LMS and on that basis is not necessarily good advice. Where it is good advice, it is a mixture of motherhood statements, commmon sense, and the bleeding obvious.

Edit/addendum: I'm starting to flag such articles. The poster in this case has never posted any remarks and only ever contributed advertorials and promotional blogs for this one product. That is red flag#1.

Wow, bummed this got flagged. Considering HN shared it on FB & Twitter - I think that may have been uncalled for.

While this isn't a 1:1, the Trades are getting hit hard by this.

With the massive shifts in them(technology)you're losing the generation of TradesPeople that had both the old and new. And were able to draw off the old to work better in the new.

However there isn't the equipment/chance/time to spread that knowledge to the new Apprentices who only get to see the new without building a more solid foundation.

TL;DR: People retire, make sure they document what they know in any medium. Also make sure new hires go through the documentation.

Seems like common sense.

It's sense. It's definitely not common! (common enough, anyway)

I thought it was just something startups struggled with, but my mom, a long time transportation engineer, was just telling me about consultants who were paid a ton of money to do toll road analyses for the state and left sparse documentation, so I'm guessing it's a struggle everywhere, though some are better or worse at it.

Harder than it sounds. Specially in companies where only a few are "tech" employees

I worked in a small place where this was a huge problem: There were only one or two software engineers working on the (multiple) products at any given time through the company's history. So when one person left, that could mean anywhere between 50-100% of the company's tribal knowledge of their own software is lost. Getting up to speed meant diving into the source code (if someone knew where it was) and stumbling upon old text file documentation basically by accident. Since they did not use source control (!!) there wasn't even a commit history to browse through to get even a clue as to in what state the products were in.

That's exactly what I mean. Sometimes management doesn't understand what the documentation is supposed to look like or even the importance of it. They might not be aware of the complexity of their infrastructure that's been worked on by a single developer for a span of many years.

I read somewhere that a great employee is one that makes themselves unnecessary, that is, they document everything they do, automate key processes they (used to) complete and so forth.

I wonder if "institutional memory" is just a symptom of a poor process.

---

For example, say you work at CoolCorp. At CoolCorp you're a sales engineer and you notice that many engineers and sales people alike constantly ask you questions concerning conditional pricing.

You consider yourself to be an amazing employee. So, when again confronted with a edge-case pricing and technical question what do you do?

A. Answer the question and move on to additional tasks.

B. Answer the question and consider documenting this particular question somewhere along with your answer.

C. Answer the question and note the general scheme of this question in order to build an internal tool to give people the answers automatically.

I don't think there's a right answer since there are costs involved with each option, but it's interesting to think about.

Great Employees drive themselves to extinction. They documented everything so well that their jobs were offshored somewhere with a lower standard of living. That's why they're so hard to find. The ones that survived learned their lesson and won't make that mistake again.

This is a great point. Like you imply, I don't think the incentives are there. After a certain level of "greatness" your compensation will almost never be commensurate with your value.

Exactly. For the knowlege they contain I'd bet they get the standard cost of living raise and will probably have to fill out some stupid self evaluation to justify even that.

It's only when the companies are going to loose that employee do they start trying everything to keep that employee. By then it's too late. Always reactive and never proactive seems to be the corporate motto these days.

We approach this with documentation (using text / wiki), mentoring, and by trading product responsibilities semi-regularly. There are a few cases where specialized knowledge hasn't changed hands, edge cases, but the cross-training from moving products around has really helped. Also tends to reduce overly-protective ownership of pieces of our product base.

On the downside it means not many are "experts" in their product, and it also drives some folks a bit batty. You'll get into a new product, look at a specific bug, pull a string here or there, and then wonder how the Earth is still in one piece.

Edit: Yet when employees leave there's generally at least one entire team still with us that built or maintained the product who can fill in and help, if needed.

To preserve institutional knowledge one needs to create business processes and an organizational culture that promotes the "capitals" - transforming employees (those who know) intellectual capital(ideas and experience)into structural capital (captured in digital form) in an environment where it is shared across boundaries (relationship capital). Knowledge and experience becomes an organizational asset vice an individual asset that goes out the door when people leave the organization.