16 Knowledge Management Myths Debunked: Misconceptions of KM

 

Often, the reason for doing something is the belief that we need our own. I'll be asked, "Can I have a community for SAP?" I'll reply, "We already have one. Why don't you just use that community?" "I need my own." They don't articulate it well as to why, but it's generally some variation of we need our own. The idea could be for what they think is a valid reason. It could be "We need one just for this country that we're in. I need a knowledge management community just for Portugal." I'll say, "Is knowledge management that different in Portugal from how it is in some other country?"

 

If they wanted to have conversations in Portuguese, that might be a valid reason, but if they simply want an English-language system that's just for people in Portugal, then there are two problems with that: A, there aren't going to be that many people in it; and B, they're going to miss out on all the other knowledge management people in the other knowledge management community. What you're trying to do there is to encourage them to say, "You don't really need your own," and try to refocus the energy that they have to start their own new community into helping to lead the existing one. In that case, the best advice is to say, "I'm glad that you're excited to lead this new community. Let's have you be a co-leader of the existing one. We can really use your energy and bringing in your colleagues from the organization you're in." The alternative is to try to get a new one off the ground, which isn't likely to go well.

 

We also that issue with internal versus external--the notion that we'll have an internal community or an internal forum or an internal repository when in fact, most of the wisdom about the subject may be outside of the company. You'll see that sort of thing in a community that's formed where people ask some question that could easily be answered if you were part of an external community, but can't be answered that easily inside.

 

I had an example of that this week at Deloitte where someone wanted to know what the job descriptions were for knowledge managers at our competitors. That's a hard question to answer inside of Deloitte because we are not our own competitor. If they asked that question in an external community like the SIKM Leaders Community, they're likely to get some answers. The idea that we can only do this inside, and we don't want to do it outside often isn't going to be effective.

 

Then there's the notion of the narrow niche. This is the one where I need a community. I need an enterprise social network group for this module of SAP. They'll localize even further. It's going to be for Europe and it's Module 12 of SAP. We say, "I don't think that's going to achieve critical mass. You arenít going to find that many people. I know you're excited about it, but you may be the only one. You're going to form your community." 

 

We've seen people form their group and then write an initial post where they say, "Hey, everyone. We're going to talk about Module 12!" And they're the only member of the group. No one is actually seeing their excited post. We need to help them understand and educate them and guide them, but we also need to help them to see that when you don't get critical mass in a community, you generally don't have an active community.

 

My colleague Lee Romero did some work where he studied inside of our network what number of people you needed to have for a community likely to be active. That number turned out to be 200. If you had 200 or more, you had more likelihood of an active community. If you had less than that, you had less. It doesn't mean that there aren't counter-examples. It just means that on average, if you don't get to that magic number, it's not as likely. When you see that kind of thing happening, you want to go in that direction.

 

 

A typical lament you hear in KM circles is, "I don't have time for that," meaning a variety of things. "I don't have the time to do the thing you're asking me to do. I don't have time to participate in communities. I don't have time to be on calls. I don't have time to go to conferences."

 

What that implies is they don't think that learning is as important as mundane tasks. If you said, "Why didn't you attend the community call this week?" they'd say, "I had other stuff to do." What exactly is that other stuff to do? Often it's attending some meeting or it's doing some kind of mundane work.

 

If you back away from that and you say, ìWe're in the field of knowledge management, one of the things we're really trying to strive is to learn and get better at things. Won't we do that ourselves? Won't we make one hour a month to learn more about our field?î 

 

Instead, we get confused by this. No one's making you learn. No one's making you attend the conference. When you do, you generally are going to get better at it. The notion that you don't have time generally means that you don't think it's important and you should probably step back and reevaluate that.

 

Youíll also encounter people whoíll want to plan and prepare endlessly rather than try things out. They'll say, "Yeah, we should probably do that, but let's develop a plan," and there'll be an endless planning cycle and we'll start up a task force." We're so busy with our mundane dreary work that we don't realize that we could be doing something else. We could step back and figure out a better way that would actually end up saving us time.

 

 

Another thing I hear frequently is that we should work ourselves out of a job. This variation is that knowledge management is everyone's job. Therefore, we don't really need knowledge management as a department. We don't really need to be full-time knowledge managers. Our goal should be to not even need knowledge managers anymore. When I hear that, I always say, "What about finance, HR, and operations? Is it their goal to work themselves out of a job? Are we going to get rid of the finance department because finance is all of our jobs?"

 

I think this is a fundamental mistake. It's all of our jobs to actually share and learn and do the things that knowledge management includes. For anything to actually get led in an effective way, there needs to be somebody leading it. To say that there will be no one leading knowledge management and everyone will just do it is naive. It's not that you need a gigantic knowledge team, but you always need at least one person who's worrying about this. You may need a few more. When you say it's everyone's job, itís everyone's job to do it, but it's not everyone's job to be the advocate for it, to be the champion for it, to be shepherding all the people, processes, tools, and components that go into knowledge management work. I don't think we're trying to work ourselves out of a job. We're trying to do is ingrain knowledge-sharing into the work of everyone else, but not necessarily to eliminate the people trying to lead the effort.

 

If you have to have an organization and you have a few people and somebody's leading people and somebody's leading process and someone's leading technology and you have some extended virtual team members, that may be all that you need. You don't necessarily have to have some monolithic giant structure, but I think you need something in order to shepherd knowledge management.

 

 

Some KM practitioners say, "The bigger team we have, the better. The more power I'll have. The greater importance I'll have in the organization. I'll be measured by that." So they'll build up large teams. They'll develop large offshore presences, and they'll think this somehow signifies that they're important or doing good work. But large doesn't necessarily mean more effective. In fact, if you think about it, many times the larger you get, the less effective you get because you're spending all of your time coordinating and communicating within these many, many people and if you get down to a smaller number, you have to spend less time doing that.

 

Large isn't necessarily better in terms of teams, and large isn't necessarily better in terms of anything else. The more websites you have isn't necessarily the better. We've heard some instances where people said they had organizations with millions of web pages. I doubt that that's a good thing--having dizzying websites with lots of crazy stuff on them, animation, widgets, and things.

 

Actually, as Google showed when it came on to the scene, simpler was better. The initial Google interface was just a box in the middle of the page. Meanwhile, the previous champion, AltaVista, had evolved to include all kinds of things. It had every kind of information known to mankind on the page, but that wasn't what people wanted. They wanted something simpler. More is not necessarily better. Sometimes, we'll tout the fact that we have more ESN groups. As I said before, that's not necessarily good. That could be bad. More isn't necessarily good.

 

Then you have the problem of citing numbers that don't necessarily reflect reality--i.e., join-only members. People join a community and then they don't pay any further attention. We can tout that we have thousand members of our community, but how many of them are actually even paying attention to what's going on?

 

Now the exception to this is the more members who are paying attention, the better. I've never found any reason why the size of a community needed to be limited. Sometimes people ask me, "Isn't there an optimum size, or shouldn't you try to keep it small?" My own experience and the research that Lee did suggests that if you have 1,000 members in a community and the member 1,001 joins, that's not going to cause any harm. Member 1,001 may begin learning and benefiting from the other 1,000 members. They may be able to answer questions and share useful information. There isn't any harm in it. In the case of community membership, more is better.