Institutional memory is a collective set of facts, concepts, experiences and know-how held by a group of people. As it transcends the individual, it requires the ongoing transmission of these memories between members of this group.
This is especially important in companies. When someone leaves, you don’t want them to take all of their knowledge with them. You want to have that knowledge written down and shared.
The lack of institutional knowledge is a real problem for any company. Recently, I walked into a situation where I would be part of a two-person team supporting a product.
Three days later, my co-worker was fired. I panicked, but felt OK because they had processes and procedures written down. Surely, I would be able to find the information I needed because it was available to me.
It was not.
There was nothing written down. Nothing had been documented. I had a huge pile of Word and Excel documents loosely groups into folders. I had multiple copies of many files, some of them incomplete, all of them differing versions of the same document.
If you're processes aren't written down, you don't have processes.
— Carl T. Holscher (@peroty) December 17, 2013
If you don’t write it down, you have good intentions. Every last bit of institutional knowledge about the product walked out the door when my co-worker was dismissed. I was starting from scratch.
Those good intentions don’t go very far when I’m left to support a product in a specific environment and I know nothing about the environment. I can support the product. I know how it works. I know how to use it and can explain it to the user community.
What I need is the process put in place in this company to perform that task. That’s the part that went out the door with the firing of the last knowledgeable person.
For instance, I can create a user account. I don’t know the process for requesting that user account be created. Who needs to request it? Who needs to be notified of its creation? Who is paying the bill for this account? These are the things I’ve had to slowly learn and document along the way.
I am a firm believe in writing things down. Not only for the next person when I leave, but when I need to do something 6 months from now, I may not remember how I did it last time. Who did I get that information from? How do I create this report and where do I send it? I need to write it down for me.
Once I write it down, it can be transferred. And if I write it down clearly, then it can be shared. Now I am on the way to having transferable institutional knowledge.
Ron Ashkenas writes about a similar problem.
I was recently perplexed when I received a request to speak to a group of senior managers about reducing complexity — mostly because I had worked with their company fifteen years earlier on the same subject; and they had since developed a reputation for being good at simplification. Why did they want to revisit what was already a core competence?
How did this group of people, supposedly excellent at reducing complexity need a refresher?
Once I met with the senior management team, the answer became very clear: Whatever institutional knowledge about simplification that had once resided in the company was now lost.
This is an extreme example as he points out. But it’s a problem I face now and one I’ve seen in every place I’ve ever worked. Information is gained, it’s retained by the person who gained it, and it’s never written down so it leaves. Institutional knowledge is an extremely valuable resource that’s not given nearly enough attention.
Organizations spend a lot of time and resources developing knowledge and capability. While some of it gets translated into procedures and policies, most of it resides in the heads, hands, and hearts of individual managers and functional experts.
It’s fine for the knowledge to start in the heads and hearts of those who use it and need it daily. However, there comes a time when that knowledge needs to be passed down. Like stories from our fathers and their fathers, we need to pass down our stories.
These stories are not exciting. They don’t involve adventure or the time grandpa set the barn on fire. But just as those stories shape us, the stories of your company shapes it. It’s not sexy to talk about the configurations of your network or what IP ranges each building is assigned. But it’s vital information to pass along.
It’s not exciting to document how to start a WebEx training session and what pitfalls there might be in planning one, but it’s vital the day of the event when you’ve got 1,000 open phone lines and terrible feedback and noise.
Institutional knowledge are the stories of the company. They are the story not only of why things are but often how they came to be. There is a reason behind a process or a way something is done. As a new person, this way of doing things may seem backwards or needlessly complex. However, once you learn the history behind it, it makes sense. Working in government of healthcare, there are a huge number of laws and regulations that must be followed. So procedures are put in place to keep the company compliant with these regulations.
With a huge workforce of contractors who may leave at any time, or full-time employees looking for a change, how do you keep this institutional knowledge?
First, there needs to be a culture of documentation and information sharing. Nothing else matters if no one is going to contribute to it. Lead by example. Ask yourself the question, what does everyone come to me for? What are you the go-to person for?
If you don’t know, ask a co-worker. Many times I’ve been a resource for something I didn’t consider myself very good at, but others saw me as the guy to see. Start there. Write up what you know.
Second, write it down. Pick a system. I recommend an internal wiki because it keeps track of changes and accountability, via user accounts. It’s a living, public document that’s easy to update.
Make it as easy to use and update as possible. A wiki is typing words into a web page. Anyone can do that. You don’t need any special knowledge.
That’s all you need to do. Encourage everyone to write things down. Then actually do it.
I’m not saying it’s going to be easy. But there are some places to start. Such as your help desk and support staff. Surely they already have some system for keeping documentation.
I briefly supported a call center and their documentation system was a huge green folder.
](https://i0.wp.com/peroty.com/blog/wp-content/uploads/2013/12/folderofpapers.jpg?resize=500%2C375)
This was filled with screenshots, printed out and highlighted. Someone had taken the time to type the how tos and procedures. Then destroyed the searchability by printing it all out.
When I worked at the National Institutes of Health, they used Atlassian’s Confluence wiki which was wonderful because we each had accounts and could create and edit pages as needed.
It was perfect for collaborating in a large team environment. Since it was part of our review process to create and update the documentation, it was actively maintained by everyone.
The participation was also high because it helped us to better do our jobs. There’s one thing if you’re doing something because you have to. It’s an entirely different things to see the benefits of it.
That’s the biggest advantage to writing things down. It’s a resource for your team that’s specific to the company. I’ve spent hours searching the web for a solution to a particular problem. Why would I throw that time and effort away by not adding it to our wiki?
If I have to answer a question once, odds are I will need to answer it again later so why waste the time looking for the solution again? Write it down. Document it. Helping your team is helping yourself.
