Knowledge is intangible and fragile. You are at risk of losing knowledge as people move on.
Organisational knowledge, and how to best retain it, has been one of the main work-related things on my mind lately. As I transition out of a specialist (eLearning /digital learning) role into a more generalist one (OD Business Partner), I’m asking myself daily (multiple times a day):
What’s the best way for me to share and distribute this knowledge and experience to equip others to answer the questions and solve these problems ?
It’s not so much the projects but the ‘BAU’ that is the challenge: the daily questions and problem solving, knowledge, advice and support – which is the way most experienced people add value to the business and other teams. This is the work that experts in the team internalise and don’t often even realise they’re doing, but which often holds the fabric of a team or function together, makes things work more smoothly for those around them and enables them to achieve outcomes efficiently and effectively. It’s the work that relies on tacit knowledge, and historical data to get done – things that people know simply from having been in the environment for a long time, that’s either not or can’t easily be documented. And, that, even if you did take the time to document it, you wonder would people even look at it? For me, it might be the story behind existing or legacy online content, or software licences we might need to maintain, why, and the impact of not doing so, who to contact for getting stuff done (and how to get them to do it), workarounds for getting stuff to work, how to maintain things so stuff doesn’t break (an issue particularly when you work with tech): the know who and the know how. This is knowledge that’s built up over years of experience, that I’m only realising others don’t have, when I stop doing the work, and the questions I’m asked reveals the gap.
Nicely summed up by Jeff Stemke here:
How I’m solving the knowledge problem
I’m documenting the important stuff (guidelines, tools, templates, legacy project info) and saving it in locations that make the most sense for the workflow of each task. And inspired by a Jane Bozarth ‘show your work’ webinar I have also been more openly and regularly sharing with the team the problems I’m encountering, and solutions I’m working on, and encouraging them to ask questions in the context of the projects they’re doing.
But: I’m also coming to a realisation that some things simply need to be experienced to be learnt – documentation will only ever go so far – there is no substitute for experience. So I am also increasingly focusing on handing over, delegating, guiding, coaching and mentoring others in the team to undertake the work whilst I am still around to answer questions. Sometimes (often?) the best way to pass on knowledge is by helping others to gain the experience.
So I was intrigued when Michelle shared her notes on Jeff Stemke presentation on measuring value and retaining organisational knowledge:
I found it fascinating. And moreover useful: especially the key steps and methods of Jeff’s ‘Knowledge Transfer game plan’ to mitigate the risk of this knowledge loss as a framework I can employ:
…and actively practice knowledge sharing behaviours in my daily workflow. Often this means consciously making a decision NOT to do a task myself, and instead, finding someone else I can teach it to, making introductions to help build relationships (as work only gets done effectively and efficiently through ‘who you know’, especially in large complex organisations).
The challenge can also be not having someone to ‘handover’ to: in that interim period between when one person leaves and their replacement arrives, and the rest of the team is already over-capacity, finding opportunities for knowledge sharing can be difficult (as yes – it does take longer to brief and coach someone through a task rather than doing it yourself).
and ways to overcome them
But as the deadline for moving out completely looms, you’ve got to just focus on the critical things – what they need to know so they don’t break stuff inadvertently, and creating performance support tools (guides, tools, checklists) that will provide people with at minimum, a starting point. The rest then, is up to direct experience – the learning by doing that only they can do for themselves.
What you come to accept and realise as well is that organisations are organisms, they’ll keep moving and morphing and adapt to the change. Things may not work quite as smoothly, but this is merely a temporary blip on the radar.