Having looked at signs of a bad and a good culture for knowledge-sharing, respectively, it’s time to get to work. How can we make sure we’re setting our knowledge program up for success?
I didn’t always think this stuff was important, by the way. I started my work in knowledge management on the technology side, building innovative KM environments for intelligence analysts, librarians, support engineers, and self-service customers. When people started talking about “culture” and “alignment,” I would roll my eyes and get back to work on the search algorithm.
But in the last decade or so, I’ve decided that culture is the most important thing—almost the only important thing. Of people, process, and technology, the people are the ones who make the decision, consciously or not, to use the process or technology, every day. And culture is simply the sum of environmental forces that make one decision, or the other, more likely. Get the culture right, and the default behavior for most people will be to do the right thing. Get it wrong, default behavior will be wrong, and you end up in an “enforcement” or “compliance” battle, which is never a winning strategy with knowledge workers.
With that, here are some tactics that encourage a good knowledge-sharing culture:
- Convince leadership that knowledge sharing is a core part of the mission. Francoise Tourniaire likes to say, “culture is a downstream phenomenon.” The first and most essential step in creating a knowledge sharing culture is making sure that leadership believes it’s important. Unfortunately, especially in support organizations, I’m afraid many leaders don’t understand their organization’s job, which is customer success. They think their mission is to close cases. Now, closing cases is an important part of delivering customer success, but it’s only one part of it—CSI members report that only 2% – 3% of customer issues are resolved through a service request for B2B companies, and far fewer in B2C environments. The rest are handled through self-service, customer communities, and other social channels. So, yes, even if we were only closing cases, knowledge is really helpful for doing a great job of the 2%. But knowledge is the ONLY hope for the other 98%, not to mention fixing the customer experience so the problems don’t surface again. The execs really need to focus on the whole iceberg, not just the part they can see and are used to managing.
- Make it part of the job. In today’s world, it’s not enough for staff to have their technical chops and their soft skills—they also need to be able to communicate in writing. (Note that this is not the same as needing to be a technical writer.) The ability to collaborate and share knowledge should be written into every knowledge worker’s job description, and their success doing this should be part of every review and feedback session. We need to hire for knowledge sharing, and train, coach, and develop it on the job.
- Make it a byproduct of collaboration. Your team members are collaborating now—it’s what humans do. They may be collaborating with specialists on the team, or they may be collaborating with a customer to figure out the root cause of a problem. The question is, after there done collaborating and problem solving, is there a permanent record that can be shared? Is there an artifact? In other words, is collaboration also knowledge creation? Michael Idinopulos makes a wonderful distinction between “in-the-flow” collaboration tools and “above-the-flow” collaboration tools. Above-the-flow tools are ones where you have to step out of your daily work to document your knowledge (like most traditional knowledgebases, or like Wikipedia.) In-the-flow tools, or as KCS would say “capture in the workflow” tools, are those that are integrated into the tasks that you’re already doing. When people say “it’s hard to get people to contribute to the knowledgebase,” it’s an almost sure bet that above-the-flow work is involved.
- Take the net out from under the high wire. This is counter-intuitive, but true: the less review there is before publishing information, the higher the quality of the submissions. You might think that having checkers and editors and reviewers and SMEs poring over each article would make people extra careful not to make a mistake. And it’s true, if you reject a few articles (I wince as I type that word “reject”), people will learn to stop contributing. But for most professionals, especially the kind you want on your team, the “reviewers” they care most about are the actual content users: their peers and their customers. If they feel insulated from their mistakes or sloppy work by people who will clean up after them, it’s only human nature to relax and let the checkers take care of it. On the other hand, if they know that their name is going on something that’s going to be published as is, then their pride and self-respect will ensure they take more care with it.
- Everyone needs to understand “why.” Not long ago, I watched a support analyst do a great job of helping a customer with a complex, but familiar, issue. I say “familiar” because he was able to give detailed directions to the customer without consulting a reference of any kind. At the end of the call, he sighed, pulled up the knowledge base, searched for the article that described that problem, and linked it to the case. I asked, “Why did you do that?” He said, “Because I have to.” I asked, “Why do they make you do it?” He shrugged, shook his head, and answered the next call. As we discuss in our workshops, there are at least seven benefits for him to have made that link…parenthetically, many of which he missed out on by doing it after the call. But he had no idea. How can we expect to do the right thing by default if they don’t know why they’re doing it? We need to remember to practice unreasonable overcommunication.
