I once worked with a company that would say farewell to long-serving employees by publishing an exit interview with them in the company magazine. People would say “Gosh, I never realised Sally knew all about X, I wish I’d asked her about it before she went”. Jokingly, we came to call them “knowledge obituaries”.
You pay good money to hire people with experience, expertise, and the right qualifications. Yet sometimes the diligence that goes into valuing a new hire’s knowledge is missing when it comes to retaining that knowledge, particularly when restructuring decisions are being made. Right now, as employers adapt and re-plan around the pandemic, and employees also reflect on their choices, we’re seeing major shifts in employment patterns.
I’m not going to argue that knowledge can somehow be decanted from people, or that there’s an AI silver bullet that will automatically retain knowledge when people leave (not even Microsoft Viva Topics!). However, there are things we can do to get smarter about some kinds of knowledge retention, so long as recognise that knowledge is many things, not one.
Not another definition of ‘knowledge’
We tend to use the term ‘knowledge’ very loosely, or at least we do until we talk to a Knowledge Management person, after which days can be lost wrangling between definitions of information, knowledge, wisdom, know-how and numerous semi-synonyms. So let’s sidestep that hairball by framing the question as:
How does my organisation ensure continuity of capability?
This seems a more practical perspective – we’re not in the business of just storing knowledge, what we want to know is how can a company keep doing what it does, given the people doing it will inevitably change over time? How can we minimize the risk that goes with it?
The RESPOND model
Once you start thinking about continuity of capability, it makes sense to recognise that what an employee does has multiple components, all of which at times get labelled ‘knowledge’. I find it helpful to use this acronym as a reminder.
Rules of Thumb (heuristics, professional shortcuts)
Experience (hands-on, real-world execution)
Skills (driving, public speaking, negotiating etc.)
People (personal network & organisation knowledge)
Objects (documents, processes, etc.)
Natural Talent (e.g. intelligence, abstract-thinking)
Declarative Knowledge (what-is, facts and figures)
Usefully it spells out ‘Respond’ so it is easy to remember. Less usefully, it doesn’t mean anything that clever – but the approach is my remix of the ASHEN model, which doesn’t mean much either. What it adds to ASHEN are the ‘declarative knowledge’ and ‘people’ dimensions, which are often essential parts of fulfilling a role well.
You can model some’s role by breaking down the components of what they know and do into the elements of the RESPOND model. For example, we might break down a sales role into the following dimensions (with examples).
- Rules of Thumb
- When a prospect is ready to close; how much discount to offer.
- Dealing with objections; how to adapt to customer styles.
- How to pitch; listening.
- Contacts for an introduction; sideways influencing.
- Sales collateral such as brochures and specification sheets.
- Natural Talent
- Personality; quick thinking.
- Declarative Knowledge
- Product data; competitor intelligence.
It doesn’t matter too much about categorizing things perfectly; the goal is to identify how each element plays a part. A newly-trained surgeon may be more up to date with facts and theory, but lack the experience to think clearly when a procedure goes wrong, for example. The engineer that can fix problems nobody else can may not be more of an expert, but may have the charisma and people network that means she can call on a diverse set of people to help diagnose it.
Planning knowledge retention
The final part of retention planning is then to understand the risk and mitigation elements of the RESPOND model profile. Each element will need its own approach. For example, objects and declarative knowledge are amenable to documentation, so the focus may be about when to use these resources. Things like experience are harder to replicate, but there are ways of structuring learning to accelerate it. Natural talent is the tricky one – there’s no way to transfer it, but you can at least identify it and know of significant it is when it comes to deciding to retain or replace a key resource.
For the more explicit knowledge types, see my earlier article: Clear knowledge management roadblocks with this diagnostic tool. Now take a look at the suitable approaches to implementing RESPOND.
- Rules of Thumb
- Knowledge mapping, discussion forums.
- Storytelling, learning histories, after action reviews, discussion forums, communities of practice, mentoring.
- Recruitment, coaching, training.
- Social networks, communities of practice, mentoring.
- Mind-mapping, task-observation, documentation.
- Natural Talent
- Recruitment, coaching, storytelling.
- Declarative Knowledge
- Knowledge mapping, wikis, training, documentation.
One of the most useful approaches I’ve found is to get experts to re-play memorable projects or events and talk them through. The first time they tell it, the story will probably be too ‘neat’ – every decision lead perfectly to the next step. But if you run through it again asking questions like “What other options were there?”, “What would you have done if that hadn’t worked out?”, “Where did you get that information from?”, you can start to unpack the multiple capabilities that were involved in the outcome.
The main thing to note is that some kinds of knowledge are much harder to replicate or are necessarily intrinsic to the individual. These represent the highest risk and need to longest-term planning. It is also why no single tool – such as an enterprise social network, document repository or topic map – will fully capture corporate knowledge.
By the time you know somebody is going it is probably too late to do anything but write the knowledge obituary, but taking a strategic approach at least gives you longer term resilience, a continuity of capability.
A version of this article was originally published by CMSWire.