Where Knowledge Goes to be Forgotten
Poor knowledge strategy is killing engineering productivity
What if you could upload knowledge straight to your brain? With the announcement that filming on the fourth Matrix movie has started, it reminded me of how awesome it was that Neo learned Jiu Jitsu and Trinity learned to fly a B212 helicopter in seconds by uploading a training program straight into the brain.
The reality of how we learn is a lot less exciting. Though scientists could “stimulate” the mind to perform better in tasks, acquiring a new skill still takes longer than a few seconds.
Our minds have immense potential, but the ability to tap into that capability is limited. For example, our short-term memory can only recall seven digits, six letters, or five words on average per “Miller’s Law”, named after cognitive psychologist George Miller. On the other hand, monkey have incredible recall and would crush any human in a memory test.
It’s no wonder then that we often tend to forget and lose things. Sometimes it’s our keys, sometimes our phones, and sometimes the command to exit vim. There is only so much we can hold in our minds without it disappearing down the memory hole.
To compensate, we developed memory hacks. Airline pilots rely on detailed checklists. There are numerous free to-do and task management apps. We keep critical information in documents and spreadsheets and sticky notes. One good friend of mine wrote reminders on her hands and arms. She called them her knowledge tattoos.
When it comes to enterprise IT however, the problem is more complicated. The knowledge needed to get something done is often in someone else’s head on another team, like API keys or environment setup scripts. It is no wonder then that the most common questions I hear on engineering teams are “where is it” and “how do I do that”.
To manage these questions, teams often rely upon wikis. Sometimes though docs work better, and then there are email chains, chat exchanges, forums, and sticky notes. One time I stopped by the desk of a sys admin whose entire dual monitor setup was covered in multi-colored bits of paper. When I asked about the stickies, he said it was his system for remembering various passwords, config parameters, and pending tasks 🤦.
We are awash in places to store information and ways to exchange information. Given the amount of complexity technology teams are handling and the speed of change, this situation can become untenable. At enterprise scale, this problem contributes significantly to the invisible work that hampers delivery speed, code quality, and system resilience.
When I started this series of posts on organizational change towards becoming a learning culture, I shared six key traits needed to support this transition:
- Enabling better collaboration
- Fostering safety to fail
- Aligning talent to work
- Controlling work in progress
- Curating a community of purpose
- Building institutional knowledge
Every organization has challenges in building institutional knowledge. Expertise gained quickly fades away when knowledge is never captured in a systematic way and teams get shuffled around. This is especially true with project teams that are temporary versus product teams that are together long-term. Then you have employee attrition which further exacerbates the issue.
The outcome is a culture of relearning. You can see relearning in action when the same questions get asked repeatedly, when requests for help go unanswered, when people cannot find the right resources, and when onboarding takes months instead of weeks.
Sometimes a few brave souls take it upon themselves to do the engineering “glue work”. They create the onboarding, write the documentation, and track down resources. However this neither scales nor addresses the larger systemic deficiencies that cause disruption of developer flow and hinder the effectiveness and productivity of engineering teams.
The typical response to these challenges is tooling and processes and automation. More often than not this merely serves to cover over the challenges of flow and productivity rather than address the root cause.
A more direct and meaningful approach to building institutional knowledge is to employ a knowledge strategy. There are seven considerations in creating a comprehensive strategy.
- Collaboration — Do you need to ask permission or use a process to collaborate with another team or it is a transparent environment to directly engage others?
- Longevity — Does useful content get passed along in channels where knowledge tends to disappear, or does it persist and easily available even after a long period?
- Relevance — Is contributed content highly opinionated based on hunches or is it canonical content based on facts and evidence?
- Familiarity — Can people easily determine whether knowledge is trustworthy, and can they be certain it originates from a proven source?
- Communication — Are channels to support sharing knowledge a broad push in one direction or open for direct contact in a bi-directional way among peers?
- Learning — Is learning delivered as specific events with a beginning and end or is it a continuous cycle of experimentation, feedback, and iterative improvement?
- Culture — Do people perceive knowledge as something to horde and control or do they see knowledge as abundant and an opportunity for team excellence?
These are foundational questions, meaning without understanding the answers, there is no path to building institutional knowledge. Viewing your current knowledge practices along these seven dimensions will begin to address more structural challenges that cause the implementation of knowledge tools and collaborative processes to fail.
Embarking on a digital strategy or organizational transformation requires moving away from the inefficiency of relearning. Unlike the Matrix, the pace of technology change is outstripping our human capabilities to grasp and manage the complexity. The only way to manage complexity is to move towards a culture of continuous learning and collaboration, and that necessitates treating knowledge as a critical and valuable technology asset.
What has been your experience building knowledge across teams and the organization? Is building institutional knowledge seen as a core business strategy?
Episode #9 — Sau Sheong Chang on Being a
High-Performance Technical Leader
Being a high-performance technical leader.
Guest Sau Sheong Chang talks about being a high-performance technical leader. Episode #9 - Being a high-performance…
We welcomed Sau Sheong Chang of SP Digital to the show to share his thoughts about what it takes to be a high-performance technical leader.
We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.