Three Types of Knowledge Workers

I have come to believe that there are essentially three types of knowledge workers. They are:

• Knowledge Generators -- these are your primary sources of new knowledge: the people who know, the experts, practitioners, talkers, explorers... They answer questions, proffer theories, discuss ideas, and find solutions for others.
• Knowledge Consumers -- these are the people who use the system to find information but have little to offer themselves. They ask questions, they search the repositories, and listen intently.
• Knowledge Brokers -- these are the people who do not generate significant knowledge themselves, but are well-versed in finding information. The classic example of a knowledge broker is the secretary; a good secretary is a storehouse of knowledge about how to get things done. Brokers are the ones who know where to look.

Of course, there are many more distinctions you can make if you delve deeper. There are the classic nicknames for users of bulletin boards and distribution lists: lurkers, newbies, trolls, sock puppets, etc. You can also distinguish users by their profession or job. But in general, there are only three types that matter.

The reason the type of user is significant is because in knowledge management programs, we tend to treat all users alike. They are treated as if their knowledge management needs are the same.

Part of this is just the basic constraints of running a corporate program; the old 80/20 rule -- where you provide 20% of the functionality to meet the needs of 80% of the audience. But part of it is an assumption about the continuity of people's knowledge needs and tactics. However, experience teaches us the exact opposite (as in the case of the bulletin board members mentioned above). Based on personality, expectations, needs, and experience, people participate (or not) in unique ways, but we tend to provide a single set of tools for them to use. In most cases this works because the technology is just a shell and the majority of the users find a way to manipulate the tools to their needs.

But recently I've run into several cases where the basic goals of the KM infrastructure have been called into question, based on differing views of the primary users' goals. This conflict has never become explicit, but runs as an underlying discontinuity impacting discussions of KM future directions with management.

Why is the happening? It happens because management and those running the KM program have differing views of the role of the users. It is not the role of the individual that matters (since we all tend to play differing roles at different times), but the overall mixture that can influence a company's KM strategy.

If you assume your employees are generating knowledge (and so have a mix of all three types), then KM will focus on making sure that knowledge is shared. Forums, communities, mentoring, making the tacit explicit, are all key activities within the KM environment.

If, on the other hand, you assume your employees are purely consumers with very little innovative or creative production, there is little need for peer-to-peer sharing and KM strategies will focus on documenting and distributing best practices, standard procedures, policies, etc.

Product development is an example of the former, where there is often a clear focus on sharing knowledge among peers and fostering innovation. The outsourcing of support is an example of the latter, where the assumption is that the knowledge pre-exists and anyone -- even someone for whom English is a second language -- can be taught to give the right answers. Here documenting the "right" answers is the primary focus.

Which brings me to my point. Similar to the outsourcing craze of the late 90's, managers today are focusing more an more on "operational efficiency" and quarter by quarter metrics. Since you can only squeeze so much efficiency out of an existing process, there is a lot of interest in "commoditizing" what have traditionally been seen as skilled or experience-based processes. In the consulting field, this manifests itself in the effort to focus on a limited set of core services that can be defined, documented, sold, and delivered by consultants both experienced and new. The idea is that you dramatically speed up the evolution from custom solutions to standardized offerings before the market commoditizes the price.

You can't blame management. And there may well be opportunities for commoditization here. However, problems occur when the managerial will outstrips the organizational capacity. In their enthusiasm to achieve their goals, they expect KM to follow suit and switch from supporting an organization of creative professionals to pumping "approved" content to delivery engineers. They also insist KM focus solely on those strategic services, to the exclusion of all other knowledge.

But strategy does not equal reality. What happens in the field often does not match the suppositions of headquarters. And unfortunately -- or fortunately, depending on your point of view -- knowledge management has to deal both with goals and realities if it is to succeed.

The outcome is a schism between what managers believe and what KM needs to do to support the organization as a whole. If it is a large corporation, you will also see it in conflicting requirements placed on KM from different portions of management. (Where management closest to the field demands support for what is and those at a global level demand support for what is desired.)

It sounds presumptuous, but I believe it is just a point of fact that knowledge develops much slower and perseveres much longer than almost any corporate strategy. The fact that a particular service is dropped from the catalog doesn't mean the knowledge garnered from it is not applicable to other services or that there are not customers still being supported who require it. (Or employees who can gain from discussing it.)

Also, even when supporting a "commodity" model, there is a significant gap between what can be documented and what happens "on the street". The classic example of a community of practice, described by Wenger and more recently by John Seely Brown in The Social Life of Information, is the case of Xerox technicians who were bombarded with printed information (i.e. "answers") but struggled to solve customers' problems until they were connected through a community so they could exchange tricks of the trade learned through experience. Almost an exact replica of today's managers pushing "best practices" to the exclusion of other KM activities.

This difference between the ideal and day-to-day reality gets expressed in thousands of assumptions about what is important in KM. Insistence that "best practices" get prominence over peer-submitted materials in the interface; requests that contributions be reviewed and "qualified" before being shared; demands that communities and forums be aligned to the organizational structure and other communities be dropped.

In the worst cases, as in the last example above, the difference of opinion results in demands that KM "support the business" and focus solely on efforts to support the strategy of the day to the exclusion of the needs of the employees. (This suppression of "non-strategic" knowledge also will have a critically negative impact on people's desire to contribute, damaging any knowledge sharing culture you are trying to establish.)

What can be done about this? Initially (a number of years ago), I was adamant that the interests of KM be given autonomy and that the knowledge architecture should support the actual topics that employees require or affiliate around. Communities should be aligned around "hot spots" within the corporation or where there was a clear strategic need to bring people together. It is also important that the communities be persistent, so they should be named using industry standard terminology -- not the corporate organizational name du jour.

Later, I despaired of any resolution. It was hard to see how conflicts could be avoided and the synergy between business operations and KM was almost totally dependent on the character of the manager -- the more open and visionary they were, the more synergy was possible; the more strictly operational their focus, the more conflicts would occur.

Now, I believe the tension between KM and corporate operations cannot be resolved -- it is a natural consequence of differing goals and points of view. However, I have learned (thanks largely to the opportunity of watching a few very smart and dedicated individuals working these issues) that it is possible to use this tension to your advantage.

KM must stick to KM -- actually managing knowledge -- not falling for the lure of "strategic alignment". By laying the proper foundation of technical support for collaboration, goals and incentives for individuals, and KM policies and procedures that align with business processes rather than specific, short-term business targets, you establish a demonstrable, long-term KM infrastructure. Then, when managers tell you to align with the business plans, rather than changing the infrastructure, you can challenge them to have their organizations use the infrastructure properly.

For example, rather than creating a new community around a specific version of a product, challenge them to set and meet a goal for participation in the existing community appropriate to that technology area. Or set and meet goals for contributing to existing communities and repositories. When they say push "approved" materials, challenge them to increase usage (downloads?) of that material in their organization or of awareness (training?). By pushing goals and metrics rather than brute force control of the source materials, you can not only get the managers to help push the goals of KM but also give them a view of reality -- see what is really being used and how much or little participation their organization is contributing.

There is no panacea. The broader goals of KM will always be hard to measure against short-term operational targets. However, by providing a stable set of core KM strategies and support, you can help management measure its own success within that environment, without distorting the overall flow of knowledge within the corporation.