
4 Ways to Avoid Institutional Memory Loss When Key Employees Leave - pgeorgep
https://www.schoolkeep.com/blog/4-ways-to-avoid-institutional-memory-loss-when-key-employees-leave
======
im_nullable
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.

~~~
cydonian_monk
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.

~~~
ThatGeoGuy
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.

------
inopinatus
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.

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

------
dugditches
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.

------
skummetmaelk
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.

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

~~~
ryandrake
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.

~~~
cakebrewery
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.

------
tabeth
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.

~~~
Avernar
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.

~~~
tabeth
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.

~~~
Avernar
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.

------
cydonian_monk
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.

------
Drrobbob
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.

