40 KM Pitfalls to Avoid: Part 4

When starting a KM initiative, knowledge management practitioners often fall into traps that may limit the effectiveness of the program. This is the fourth of a five-part series on pitfalls to recognize and avoid.

28. Saying we need our own

Often, the reason for doing something is the belief that we need our own. I received requests like, “Can I have a community for SAP?” I replied, “We already have one. Why don’t you just use that community?” They replied, “I need my own.” They don’t articulate it well as to why, but it’s generally some variation of we need our own. It could be for what they think is a valid reason. They said “We need one just for this country that we’re in. I need a knowledge management community just for Portugal.” I replied, “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 community just for people in Portugal, then there are two problems with that. There aren’t going to be that many people in it. And they will miss out on all the other knowledge management people in the other knowledge management community. Tell them, “You don’t really need your own” and try to refocus their energy to start their own new community into helping 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 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 see the issue with internal versus external — the desire to 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 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.

The other case is the narrow niche. For example, a request for an enterprise social network group for European specialists in the FI module of SAP. I have seen people create such a group and then write an initial post like, “Hey, everyone. We’re going to talk about the FI Module!” And they are 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.

29. Saying I don’t have time

A typical lament you hear 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? 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; we’re trying to get people 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 consumed by the mundane. 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 KM. The excuse 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.

30. Saying we should work ourselves out of a job

I sometimes hear that we should work ourselves out of a job. 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?”

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 management team, but you always need at least one person who is 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 ingrain knowledge sharing into the work of everyone else, but not necessarily to eliminate the people trying to lead the effort.

If you have an organization with a few people, with someone leading people projects and someone leading process projects and someone leading technology projects, 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 you need something in order to shepherd knowledge management.

31. Believing that bigger is better for organizations, and that smaller is better for community membership

Some KM practitioners say, “The bigger the team we can have, the better. The more power I’ll have. The greater importance I’ll have in the organization. I’ll be measured by that.” This leads to building up a large team, with a large offshore presence, which somehow signifies importance or doing good work. But large doesn’t necessarily mean more effective. In fact, many times the larger you get, the less effective you get, because you’re spending all of your time coordinating and communicating with many different people. 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. There are some instances of organizations with millions of web pages. That’s not a good thing, nor is having dizzying websites with lots of animation, widgets, and dense content.

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. Some people tout the fact that they have more ESN groups. That could be bad; more isn’t necessarily good.

On the other side of the coin, some knowledge managers believe that small communities are better than large ones, because all members know each other and thus have greater trust than in large communities. At Deloitte, we studied what number of people you need to have for a community to be active. That number turned out to be 200. If you have 200 or more, there is more likelihood of an active community. If you have fewer than 200, it’s less active. 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.

So the exception to the bigger is not better rule is that the more community members who are paying attention, the better. There is no good reason why the size of a community should be limited. Sometimes people ask me, “Isn’t there an optimum size, or shouldn’t you try to keep it small?” If you have 1,000 members in a community and then 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. In the case of community membership, more is better.

32. Trying to make people do things

The expectation that we can make people do things is naive. For example, trying to make people maintain their expertise profiles. It’s not something we tend to like to do, or to contribute all documents. In the early days of KM, we’d say, “Contribute all your documents and then we’ll put them in a repository, and then we can reuse all of them.” No one likes to do that. The idea that we can make somebody do something is not valid. If we make them do it and we enforce it, they will do it to the minimum extent possible.

Forced membership in communities isn’t a good idea. Participation in communities should be voluntary. Or the wish that everyone will start using the intranet from one home page. Some think, “Here’s our intranet home page. We’re going to put a banner ad on there because everyone will go there.” But they won’t. They’re going to bookmark some other page and go there, and you’re not going to be able to determine where they go. Don’t even try. Instead, try to pull them in. If you need to locate expertise, instead of making people fill in their expertise profile, let them join communities and let the expertise emerge in the community.

33. Saying that everything is a community

I have heard community used in some strange ways, as if everything is a community. I hear entire populations referred to as a community. My definition of community is a voluntary group that you join because you want to get better at something, not something that defines the organization you’re in, or defines the ethnicity that you have, or some other attribute. There are all these uses of the word community.

A community is something you choose to join because you want to meet up with other people who are interested in the same subject. A community is not a website. It’s not a wiki. It’s not a blog. It’s not an ESN. It’s not an organization. It’s not a project team. It’s just the people who choose to learn more about a subject by coming together.

See 10 Principles for Successful Communities.

Read the rest of the series below.

40 KM Pitfalls to Avoid: Part 1

40 KM Pitfalls to Avoid: Part 2

40 KM Pitfalls to Avoid: Part 3

40 KM Pitfalls to Avoid: Part 5