7 deadly sins of knowledge management - part 2
Summary
This week we round off our discussion of the seven deadly sins of knowledge management. We discussed three of them last week. Here are the next four.
Don’t take a top-down approach to designing your system. Keep users at the centre of your design approach and make your systems as open as possible.
Avoid building walled gardens unless absolutely necessary. Get everyone to contribute to one system without restriction. This’ll help high-level patterns emerge through lower-level interactions.
Don’t forget about personalisation. This is how we consume information on the internet today and people expect enterprise systems to behave similarly.
“Build it, and they’ll come” is a myth. Recognise this and recognise company influencers, community managers and curators to popularise your system and to keep it fresh.
Last week I started a two-part series, discussing the seven deadly sins of modern-day knowledge management. This goes hand in hand with my previous recommendations for knowledge management in the enterprise. In that last post, I discussed the first three sins.
Recap those pitfalls if you need to jog your memory, or if you’re here for the first time. In today’s post, I want to share four more KM sins to round off our discussion.
4. A top-down approach
Most knowledge management initiatives I’ve seen usually have a senior executive sponsor and often some sort of grizzled steering committee. They also have a team that’s implementing the knowledge management platform. This leads to a twin, top-down dysfunction.
First, there’s the temptation to model the executives’ view of the world. Especially if they’re the only people the KM team gets direction from, this temptation is understandable. But here’s the truth. Most CxO-level representations don’t model a regular knowledge worker’s view of the world. The design of your system can catalyse a myriad of learning and collaboration possibilities for your colleagues. Just the same way as we design applications with users at the centre, it's crucial that we design social platforms for the average employee, not the CxO.
Second, there’s often a fear of letting go. Often, on KM teams we lose sleep over all the things that could go wrong.
What if someone vandalises a piece of content?
How do we stop people from uploading misleading information?
What if someone deletes important assets?
I don’t want to trivialise these concerns. I must point out, however, that most modern systems provide safeguards for many such concerns, through watchlists, version control and other, age-old features. The risks of poor behaviour on an enterprise platform are infinitely lower than those on social media. No one wants to lose their job for being a boor. Our design decisions must be commensurate with the probability of the risks we perceive. My bias is to open up systems as much as your platform allows. Focus on adoption, more than risks. When more eyeballs are looking, all risks are shallow. Here’s some food for thought.
If you’re concerned about an event that has a probability of 2%, does it make sense to block out entire feature sets for it?
If you’re concerned about misinformation, abuse, or just well-intentioned mistakes, can the crowd; i.e. everyone in the community; flag these? Instead of implementing a restrictive system, can you trust the wisdom of the crowd?
And lastly, what lightweight mechanisms does your system provide to filter, flag and watch content? Does it help make the curator’s job easy, by using AI in the background? In 2023, this is a basic requirement.
5. Building walled gardens
Back in the day, we organised our company knowledge on Google Sites. Yeah, don’t ask. I’ll be honest. I dig Google Sites. It’s easy to organise information on them and you can get an entire team to collaborate on creating these internal microsites. Think of them like modern, lightweight wikis. That’s where the romance ends though. When all teams or departments or communities create their little sites, you run into the phenomenon of walled gardens. Let me explain why this is problematic.
When you create content on the internet, for example, this blog post, everyone can see it. With the internet, you also get a layer of sense-making. Search engines can crawl this page. The more people link to it and the more they click on search results, the more likely it is that other people will see it too. This phenomenon repeats itself even on social platforms like LinkedIn. It’s what Andrew McAfee called “emergence” - i.e. the idea that high-level patterns and structure emerge because of lower-level interactions.
The other problem is that entry to a walled garden is often based on arbitrary notions of membership. For example, if a group of business analysts create a community site with content about agile analysis techniques, does it mean that only these individuals should update, maintain and comment on the content? What if a product manager wanted to improve the content? What if a developer took issue with some materials? Sure, they can ask for editing access or request updates, but at scale, this adds too much friction and overhead.
So unless a team wants to collaborate in private, and there are many good reasons to do so; I advise having one, company-wide system to share knowledge. Everyone should be able to contribute to it, comment on existing content and even edit existing content either directly or using merge requests. That’s how things get better with each iteration.
6. Ignoring personalisation
We consume information on the internet in a personalised manner
Pause a moment and think about how you consume information on the internet. You don’t navigate from website to website, do you? Usually, you configure systems based on your interests and the systems serve you the information you want. Everything is personalised, be it the people you follow on social media, the links you click on search engines or the preferences you dial into your newsreader. Some of it is admittedly creepy, but this is how we use the internet. People expect enterprise systems to behave similarly.
In my company and with clients I’ve worked with, I’ve often heard the complaint of information overload. This is where the knowledge and community platform becomes a victim of its success. If you onboard everyone and many of them contribute content, people may feel like they’re drinking from a firehose. It’s information overload of course, but it’s also filter failure. And that failure results from ignoring personalisation capabilities in your systems.
Think hard about how you’ll design your system for scale. How can people tell the system what information they want to see more of or less of? Can they prioritise content that comes from certain people or groups? Does the system learn about an individual’s preferences and provide content recommendations? Without some of these capabilities, your knowledge management solution will be incomplete.
7. The “build it and they’ll come” myth
I reserve the most common sin for the end. We all suffer from this illusion that building a great product is the be-all and end-all. Nothing’s further from the truth. In the modern day, there are thousands of great products that are competing for attention from the same people you target. And no, it makes little difference if you have what seems like a captive, enterprise audience. Adoption is rarely automatic. Let me tell you why.
People’s time is a zero-sum game. If you add something in, they’ll chuck out something else. So when you ask people to adopt your KM system, you’re in effect asking them to “un-adopt” something else. Whether that’s time at the foosball table or the several minutes on Slack, is beside the point. The point is, that you’re asking them to reconfigure their time. And as creators of the system, it’s unlikely that you’ll be the only people to influence them.
This is where you must lean on other influencers. James Clear says that we seek influence from the close (friends, coworkers), the many (our community or tribe) and the powerful (people with status and prestige). Think about how you’ll enlist support from these groups to attract people to the platform. This must be a continuous exercise; not a one-and-done.
People involved in your knowledge ecosystem
In addition, recruit a layer of sense-makers for your platform. While every employee should be able to contribute to your knowledge base, you need community managers and curators to organise these contributions. These are individuals who have enough subject matter expertise to make content useful and usable. When you nurture a system and keep it fresh, you give people an incentive to use it.
And that my friends, was my take on the seven deadly sins of knowledge management. I’ve either seen all these traps from close quarters or made these mistakes myself, so I hope you can learn from my misadventures. If you liked this post, you’ll probably enjoy my other pieces on knowledge sharing in the enterprise. Hint; it’s not about bumping into others at the water cooler. I encourage you to read them and if you’d like, get in touch with me to share your thoughts.