Can you Manage Knowledge?

I was part of a group listening to a case study presentation on the evolution of a Knowledge Management technology this week. I listened not so much for the lessons learned, but to hear about the particular experience of this individual at a company I was once familiar with.

What struck me about the case study was that the presentor actually came out and said that once management got involved the implementation faultered, now I’m paraphrasing and summarizing, but that’s what it boiled down to. The initiative had started off as primarily a grass-roots Community of Practice technology implementation, i.e. putting in some technology to support the activities of the Comminities of Practice–sharing documents, being able to find experts, generally sharing information. Management liked the results so much they got directly involved in creating rules for the communities to follow–who could share information, how it was to be placed in the technology–taxonomy and meta-data, they made it so difficult to share people stopped, the communities stagnated.

The point the speaker was making was that the program was a victim of its own success, but what it made me think of was the question of whether you can really manage knowledge? And if you can, what does that management look like? I think that you can, and I think that at a high-level it doesn’t matter if we are talking about tacit or explicit knowledge, the guiding prinicples are the same. The management of knowledge is not the same as the management that many of us are used to in organizations, it is not a top-down model or even a matrixed model, nor is it a completely decentralized model, it’s a hybrid, a middle road.

The model for managing knowledge privides some structure, some guiding pricinples so that people know what tools they have at their disposal and how to use them and when to use them. The steering/governance committee has participants from business and IT, and not just management, but front-line users. In part, the committee determines, user guidelines (not rules), and helps ensure that taxonomy and meta-data are enough to be useful but not so much to be cumbersome–a fine line to walk. They help define terminology so that people understand things in the same way. They make sure that any technology that is used meets user requirements and that is has an appropriate security/permission model, this does not mean locking everything down so only a a few select users can access it, it means opening things up and that those (hand-full) of documents that should only be accessed by a few people are only accessed by a few people. Then they let the knowledge workers use the knowledge sharing activities they way they want to use them.

This is not a command a control model, management cannot control what people share or how they share it or when they share it, they can only facilitate the sharing. Managing knowledge means that management has to trust the knowledge workers to do their jobs, to ask for help from others and to provide help to others in whatever means makes sense–whether that’s within a community of practice, a knowledge repository, by collaboration, or some other means.

This finding was mirrored again later in the same day, when I listened to another presentation on using wikis for support, one of the key activities that drove success was that the manager let the support personnel put whatever they wanted in the wiki, and trusted that information that was useful would stay, “rise to the top” and the information that was not useful would be removed, “sink to the bottom” and it did. He provided them with some basic training and a framework of activities and let them figure out the rest, now the support team can’t imagine using anything else.

So yes, you can mange knowledge, but it involves changing your definition of management.