Friday, May 2, 2008

The Four Paradoxes of KM

Knowledge Management is a big topic. There are different models and approaches for managing knowledge -- any of which can be helpful in establishing goals, a strategy, and tactical initiatives for a corporate KM program. Each model narrows the focus to a subset of the larger problem. Some focus on communities, some focus on capturing tacit knowledge, some emphasize best practices, while others target search and/or structuring knowledge that already exists.

However, whichever approach you take, at some point you will come face to face with one or more of the paradoxes of corporate KM. These are problems without a solution. They trigger intense philosophical debates when they arise and can lead to quite heated, sometimes personal, attacks on one position or another. The professional careers of a number of consultants in the field are based on advocating one side or the other of the debate.

Why? Why must it be one or the other? Why can't there be a middle ground? The reality is that any given KM program has only so much time, money, or attention to spend and must tactically select what problems to attack and how, thereby staking a position on each issue. And when you do, there will be advocates within management, among your professional peers, and in your audience base who will argue -- loudly -- for the alternative.

Be prepared. These issues cannot be resolved by pure logic or persuasion. They must simply be faced as a hazard of the profession.

The four paradoxes of KM are the following:

Tacit vs. Explicit

This is perhaps the oldest of the paradoxes and the most intractable: whether to focus on explicit or tacit knowledge. Explicit knowledge is information that is written down: project documents, white papers, lessons learned, best practices, etc. Tacit knowledge is all the information your constituents have garnered from experience but still have locked up in their heads.

A focus on explicit knowledge usually leads to an emphasis on search, taxonomy (categorizing the explicit knowledge), and sometimes selection (e.g. qualifying best practices). A focus on tacit knowledge often requires a concentration on establishing and encouraging communities (where tactic knowledge can be shared), story telling, and the technologies and events that support them (forums, blogs, SIGs, face-to-face meetings, etc.). Search is also important, but often focuses on people rather than documents (finding expertise rather than static information).

Local vs. Global

The second paradox concerns the geographic scope of the knowledge sharing. It is relatively easy to establish a community for knowledge sharing within a local area. Sharing involves trust and trust is easier to establish among people who share physical and cultural proximity. A small localized community also has more opportunities for face-to-face meetings that further increases trust and understanding between members. So you frequently see requests to create a local group, forum, wiki, or repository, although the topic at hand is itself universal (such as a Project Management community for the Boston area, say).

However, once a local community is established, either consciously or subconsciously, it creates barriers to those outside of the group. Just the existence of a local group will create an emotional barrier to people not within that area. They do not advertise their activities outside the region and often think their concerns are unique to themselves. In many cases, they even use security mechanisms to restrict access to their local members only.

But for large companies, sharing knowledge locally is not the problem. Making information and problem solutions visible and available across the corporation is the issue. Consequently, these localized efforts actually create barriers to sharing knowledge between regions and organizations.

Global communities are harder to get started. Individuals don't feel as connected and, for multinational companies, different languages can create an additional barrier. So, if there is a local community, employees will tend to expend their energies participating in the local activities and ignoring the global efforts. (There is actually a chicken-and-egg situation that arises, where people will claim, fairly, that there is no benefit in their participating in the global community because it isn't as active as their local group. But the global community cannot thrive until the individuals get involved...)

So, the individuals would prefer and will -- in the absence of any outside influence -- create small, closed, local groups. But from a larger corporate perspective there is a critical need to establish and foster global sharing. And until the global communities are firmly established and prove their worth, there can be continuing and sometimes heated battles over who gets to establish communities and how.

Open vs. Closed

The third paradox focuses on the tension between security and sharing. This paradox is closely related to the issue of global vs. local, but is not restricted to geographic proximity.

The goal of knowledge management is to maximize the value of the corporation's accumulated experience and wisdom by sharing them and applying them wherever possible: i.e. using knowledge as a business asset. But, in business parlance, assets need to be protected against misuse or -- worse -- industrial espionage. This is usually done by restricting access to the assets to only those who need to know. In other words, putting them under lock and key.

This approach may work well for machinery and a few highly confidential business strategy documents, but it does not work well for knowledge. As soon as you restrict access to knowledge you drastically reduce its ability to be applied and consequently its value.

Knowledge is one of the few "renewable" resources in business. In fact, it is not only renewable, it is regenerative, because the more you use it the more knowledge you create.

Unfortunately, there are many urban legends that scare managers and reinforce the urge to secure any but the most innocuous documents against misuse. Stories of a contractor who also works for a competitor, takes documents, gives them to the competitor who then presents the information as their own work and "steals" customers out from under your company. Even within a company, many groups will protect process documents, examples, best practices -- even sales presentations -- against access from anyone but select members of their own subdivision.

This sort of intellectual property hoarding is hard to argue against because it is not based on rational thought; it is based on fear. If you perceive others within your own company as a threat, it will be very hard to establish a culture of sharing and trust. And as the the average time of employment shrinks and changing companies becomes commonplace, even the most trusted employees within your division become potential future threats.

Quantity vs. Quality

Lastly, the fourth paradox struggles with the choice between a few excellent examples and sharing as much knowledge as possible. The argument goes like this:
  • On the one side, you should save and share everything so as not to lose any of the valuable knowledge captured in your business documents. Besides, you cannot tell in advance what knowledge will be needed. Users can then search through and decide for themselves what is the most appropriate content.
  • On the other side, even if you save only part of the accumulated documents, you don't want your employees wasting their time sifting through piles of unstructured content. The best examples should be reviewed, approved and highlighted to make sure they get the most appropriate content quickly.

Note this argument tends to come up most frequently when dealing with explicit knowledge. But it can also apply to tacit knowledge, when you get into discussions about archiving and how long to store forums, blogs or other user-generated content.

In most cases, whenever I have been caught in the middle of this argument, it has been completely hypothetical. The organization having the argument is neither capturing any measureable amount of unqualified content and has no process, criteria, or personnel in place to locate and rate best practices from any other type of knowledge. However, the debate rages on, hindering any further progress in either direction.

But the paradox does not have to be taken to extremes to prove troublesome. Even when a company attempts to take the middle ground -- accepting peer submissions, then reviewing, selecting, and highlighting best examples -- arguments still arise. To begin with, identifying certain samples as high quality and raising their visibility has the natural effect of discouraging contributions from those who and are not selected. If you encourage people to reuse the "approved" entries, you are implicitly discouraging them from using the rest, so why bother submitting? The other common difficulty that arises is disagreements over who (which group or which role) should have the right or has the expertise to make the selection.

Conclusion

I say these paradoxes are unsolvable, but that is only when they are being argued in abstract. Given any specific business situation, there is always a better and a worse approach that will fall to one side or the other of each issue.

When dealing with call centers and help desks, there is a considerable amount of explicit knowledge required. The call agents are not experts; they rely on databases of "answers" to respond to calls. Any issues that are escalated need to be captured into the database to aid future calls.

At the opposite end of the spectrum, when dealing with consultants, there is a certain amount of explicit knowledge -- contract templates, legal boilerplate, even past examples -- but the critical issue is enabling them to share, combine, and reuse their implicit knowledge with each other as they face new challenges each day.

Unfortunately, people tend to see these paradoxes as abstracts, even when facing specific business challenges. So, although it ought to be possible to argue the merits of a knowledge management program based on the specifics of its strategy and alignment with the business situation, you will more than likely be drawn into a philosophical debate over one or more of the paradoxes at some point in the project.

Being an optimistic, you might view it as a positive sign of interest and enthusiasm for KM. Being a pessimist, it might appear purely as unnecessary interference from the uninformed. Either way, it is best to allot extra time in your plans for it because no matter what you do, you are unlikely to be able to avoid the argument.

Tuesday, April 8, 2008

What is Enterprise 2.0?

In his comment to yesterday's post about Enterprise 2.0, Doug Cornelius posited that:

I do not think it [Enterprise 2.0] is using Web 2.0 inside the enterprise, it is tools like Web 2.0 inside the enterprise.

However, a previous comment, from Xyzo, took what appears to be the exact opposite position:

Enterprise 2.0 is not just web 2.0 in an enterprise. You first need a change in culture, which means adopting new processes.

So which is it? Is it web 2.0 tools and technology inside the enterprise or (if I can be allowed to paraphrase) web 2.0 philosophy inside the enterprise?

Well, not being a fan of the 2.0 craze, I am probably not in any position to insist on a particular definition. So let's go back to the source, Andrew McAfee and see how he defines it:

Enterprise 2.0 is the use of emergent social software platforms within companies, or between companies and their partners or customers.

Hmmm... that doesn't seem to resolve anything. But if you read the rest of his definition, it appears he is siding more with the latter definition. I won't quote the definition in full -- it is a great read so I recommend it to everyone -- but some key points of his definition are the distinction between platform and tool and his use of the term emergent:

Emergent means that the software is freeform, and that it contains mechanisms to let the patterns and structure inherent in people's interactions become visible over time.

So if I interpret this correctly, the definition of Enterprise 2.0 is a little bit of both: it requires both the technology (i.e. the platform) and the philosophy (implied by emergent and freeform).

So are blogs inside the firewall Enterprise 2.0? It depends. It depends on how the technology is used. If it is simply used as another way to push executive news and announcements to the masses, then the answer is no. If it is used as a mechanism for managers to communicate and interact freely with their employees, or for the employees to develop their own interactions, then the answer would be yes.

Which gets us back to web 2.0 and process: intent and the process that embodies it is essential in the classification as any specific tool or technology as Enterprise 2.0. However, too much process is in itself a problem. Remember, McAfee speaks of an emergent platform; too much predefined process will tend to inhibit the emergence of patterns and structure over time. (In other words, there needs to be enough process or intent to act as a catalyst, but enough room to allow the emergence of the true purpose -- McAffee's patterns and structure -- from its usage.)

So, for example, as I read it:

  • Blogs inside the enterprise are OK, but not in and of themselves E2.0
  • Blogs used for project-based communication (as one example) are closer to the definition
  • Blogs used by project leads to post weekly status on each project (particularly if comments aren't allowed or encouraged) push beyond the freeform and the process starts to inhibit the interaction -- becoming purely web 2.0 technology used for traditional top-down project management purposes

It all depends on what is required, what is allowed, and what is supported.

But the interesting question for me -- particularly when talking about the practical application of these emergent platforms -- is looking at what are the characteristics of the platform that tend to lead to success. Which, of course, presumes the thornier question of how one defines success...

Monday, April 7, 2008

Why Enterprise 2.0?

There is a lot of hype about Enterprise 2.0 (or "web 2.0 inside the enterprise"), but what is the buzz all about? There is certainly sufficient cause to be excited -- the exponential growth of social networking "in the wild" and the success of web sites like MySpace, Flickr, and del.icio.us demonstrate a transformative power that any corporate executive would be crazy not to envy. But can that power be harnessed in a corporate environment?

You can have philosophical debates about the revolutionary impact of web 2.0; how the "wisdom of crowds" can change the way business is done, harnessing the combined potential of thousands of employees, etc. But for the time being, these arguments are completely theoretical. Speaking pragmatically -- from a purely practical perspective -- what are the pros and cons that would cause a corporation to deploy social software internally, beyond simple speculation?

The Cart Before the Horse

The fact is, attempts to utilize web 2.0 within the corporate firewalls have -- from all reports -- been sporadic and slow to develop thus far. It is easy to see why.

Cons:
  • Despite all the predictions that younger employees -- Gen X, Gen Y, and millenials -- will expect or insist on social software at work, the fact is they might not. Those employees who have already embraced social networking outside the company will have no great impetus to create a separate social network inside the firewall. The potential audience -- and therefore benefits -- are dramatically smaller and require duplicate effort. For example, if I am using del.icio.us for bookmarks, why would I want a separate, incompatible set of bookmarks just for work-related data? It's just too much effort.
  • Employees not using social software today have no experience with it and so will feel little compunction or interest in using it internally.
  • As mentioned before, the difference between millions (or hundreds of millions) of users on the internet and a few hundred or thousand employees inside the firewall is non-trivial. It is unclear whether there is sufficient critical mass within a company -- even a large company -- to make social software "work". There is simply not enough of a "crowd" to get wisdom from.
  • Finally there are all the usual disincentives for using new applications within a corporation: not part of my job, overlaps with existing apps, can't waste time on pilots or prototypes that might go away...

Given these issues, the question ought to be: is it more beneficial to "roll your own" social network or could companies be more effective by really embracing change and using the existing public services? For example, why not just create a separate FaceBook group for your company and encourage employees to use it?

Pros

The fact is that there are at least three significant reasons for a company creating their own web 2.0 infrastructure internally.

  • Security. First and foremost, the "network" inside the firewall can be far richer -- but at the same time more sensitive -- than the generalized social networks on the public internet. Corporate employees already have a point of connection, their employment, to tie them together. But there is a significant danger of proprietary -- or at least embarrassing -- information being exposed if a company's employees use an external service to develop company-based social networks. For large companies, in particular, this is likely to be a show-stopper requiring an internal infrastructure even if it is purely a replicate of externally-available services.
  • Consistency. The corporate intranet is neither a democracy nor a competitive marketplace. Any good idea on the web has imitators and so individuals have several choices for social networking (MySpace, FaceBook, Orkut...) or bookmarks (del.icio.us, ma.gnolia, reddit...), or video (YouTube, Veoh, Flixya...). Sheer volume can allow each to be successful. But they can also create problems, as people often need to create multiple profiles to connect with friends who are on multiple services. Within the corporation you can insist on a unique service for each, significantly reducing confusion and the dilution of the crowd effect. Whether this uniqueness makes up for the significantly reduced overall audience is unclear, but it may.
  • Integration. Perhaps the greatest advantage companies have implementing web 2.0 inside the firewall is the ability to integrate the services. For companies with single sign-on (i.e. unique digital identifiers for their employees) it is possible to automate the connectivity between multiple web 2.0 technologies as well as traditional corporate data. Rather than separate accounts (one for a social network, one for bookmarks, one for photos...) inside the firewall a person's identity are tied to a single ID, which can be used to merge content. When creating a profile, all of someone's basic information (location, email, role, etc) can be pulled automatically from the corporate directory. Only personal preferences and context needs to be added. In the same way, a person's membership in internal groups, forums, or businesses can be automatically linked to their profile. Photos can be entered once and used throughout the corporation etc. This type of linking has always been possible. The change with web 2.0 is giving the individual control of what that data is that is shared.

Conclusion

For small companies (100 employees or less), it may be possible to embrace the openness of social computing and utilize external services such as FaceBook* for all of their social interactions. But for even moderately sized companies, the need for privacy and security will drive them to institute social computing (if they do at all) inside the firewall.

Despite the drawbacks to internal deployment, the ability to integrate multiple social applications -- along with existing corporate data -- though unique IDs provides corporations with an opportunity to build social networks that are more technically powerful than anything currently possible outside the firewall.** However, even with this potential value, there are some realities that any company must face implementing web 2.0:

  • Adoption will not be anywhere near as "viral" internally as equivalent services on the public web (for all the reasons given above).
  • Implementing only one web 2.0 service as a "pilot" has little if any chance of success (again, for reasons previously mentioned).
  • The previous limitation might be overcome by piggybacking web 2.0 functionality on top of existing corporate services. For example, adding personal biographies or tagging to an existing company white pages provides the new services with a large, pre-established audience. Similarly, adding social functions such as tagging and bookmarking into the corporate intranet banner (where standard banners exist) allows the services to reach the majority of intranet web sites with no additional work for web masters.

* footnote: In fact, for small companies, their entire infrastructure could be built on free services such as Facebook, Yahoo Groups, GoogleDocs, etc. Although I don't know of any companies doing this today, it is clear that an infrastructure-less company is possible, even without paying for commercial SaaS offerings.

**footnote: OpenID offers some of the promise of unique IDs in the public realm. But its potential is still nascent and seriously offset by competing services. For example, I receive requests to "connect" on a regular basis from at least three separate professional networks similar to LinkedIn . The benefit of any one of these networks is significantly diminished by the existence of the others. Thus far I have chosen to simply ignore requests from services I do not already have a profile on because it is too much trouble to maintain multiple profiles for a single purpose.

Monday, March 31, 2008

What I'm Reading: Late for Work

I am suspicious of awards books. You know what I mean: the National Poetry Series, the Agnes Starrett award, the Lamont, the Yale Younger Poets Series, etc. It's not that there aren't good books in these series. It's just that they tend to look better than they are (and I don't mean just visually, although that too).

You leaf through them at the bookstore and hit a poem that strikes you as interesting. Unique. Evocative. So you buy the book and take it home only to discover either that you read the one good poem in the bunch or it is all surface: the poems are all interesting/unique/evocative in the same, formulaic way. Again, I don't want to paint all award winners with the same brush, but as a consumer I have been burnt enough times to be wary.

So when I came across David Tucker's Late for Work at the Concord Bookshop (one of the nicest independent bookstores in the country, by the way), I was intrigued but not necessarily optimistic. The working poet. Poems about working life. I could see the hook and had serious doubts. But it looked interesting enough to overcome my reservations from its being a Bread Loaf/Bakeless Prize winner and picked it up.

And I am glad I did. Tucker is a working poet. Not because he writes self-referential poems about holding down a job (although he does that too), but because his poems are the product of a poet working at his craft just as he works at his primary occupation. The jacket tells us Tucker is a journalist. And plenty of the poems refer to this profession. But the work in Late for Work is the backdrop, the milieu of the poems, not the subject.

Tucker is not a great poet -- you can't expect the revelatory experiences of reading Whitman or Berryman or Neruda. These are not poems using language in a new way or extraordinary visions of the inner self. They are not flashy or arty poems. No, Tucker is a not great but he is definitely a good, steady poet and his poems reflect language used well to examine a life and the society it is lived in.

Which is surprisingly uncommon nowadays and what makes this book worthwhile. Here is a poet taking his time and looking closely:

Through most of January my two brothers and I
drove back and forth to the hospital where our old man was dying.
We did eight-hour shifts, just watching him go
from the final disintegrations of liver cancer, swabbing his lips,
talking into his coma, with sidelong looks at death.
--"Enough of It"

The careful articulation lets you see into the narrator's predicament, experience loss with a clarity that is not possible when the tragedy is your own. And with that clarity comes insight:

I've seen all the x-rays I ever want to see, checked all
the IV bags I ever want to check, heard enough of the morphine counter
and its little metal tongue.

And just as his poetry is slow and studied, his endings do not allow for the easy out either:

      -- and praying
and having faith that you'll get over it and move on and let go,
and the long view you take after losing one loved so much --
I've had enough of that too.

Even in his more flippant moments, Tucker poems are controlled (such as in the poem "Voice Mail", which personifies the one technology that is perhaps the most dehumanizing, beginning "this is what's-his-face's voice mail.") But where Tucker shines is where he examines the everyday, the common events we all share but must experience separately: life, death, work, etc. Poems such as "Enough of It", "The Men Decide", and "Putting Everything Off" make Late for Work a book well worth reading.

If there are flaws in Tucker's books (and one would imagine there must be in a first full-length book) I can see only two. Every once in awhile, Tucker draws out his images so carefully, so long and so far that he goes beyond poetry and stumbles into -- well -- prose. For example, this from the poem "That Day":

The mother sings some song we can't quite hear anymore
as she carries a sack of groceries on one arm
while the boy wades around her, kicking the dry leaves.

As for the second possible flaw, Tucker is a solid poet and his poems are not repetitive. But there is a certain structure that you see repeated in several of his poems. It is the slow beginning, the steady deepening of the images, followed by a turning as the poem progresses, finished off with a final twist in the last two lines. This is not a pattern unique to Tucker. Many poets do it. It comes from a desire for closure, a clean finish. The danger is that you fall for an easy out, a neat but artificial closing image. I recognize it because I recognize it from my own work and the work of others. It is a familiar trap.

Tucker doesn't fall for the easy or the quick close, the surprise ending. But he does favor that final poetic image and uses them frequently. He may want to consider occasionally letting the poem come to a halt, without that closing final exclamation, and let the poem rely on its own merits. A little ambiguity never did any harm.

But this is just nitpicking, quibbling over details. Late for Work is a surprising book because it isn't surprising. Its just good strong poetry in the American vernacular.

Tuesday, March 18, 2008

What is Knowledge Architecture (the Short Version)

In one of the industry mailing lists, a member asked if anyone else had the title of knowledge architect and, if so, what do they define it as. Since that is the title I go by, I thought it might be useful to explain how I define the role and what separates it from others.

(I was somewhat surprised to find that I hadn't answered this before -- in writing. I do it a lot in person. My opening posts define Information Architecture and Knowledge Management, but skipped the synergy between them that is where I live and work today...)

I tend to keep my definitions simple. So to me Knowledge Architecture is the application of information architecture to knowledge management. That is, using the skills for defining and designing information spaces to establish an environment conducive to managing knowledge.

Borrowing a metaphor from physics, you can think of the difference between information architecture and knowledge architecture in terms of energy. Information architecture tends to focus on designing spaces for existing or predefined information. What might be called kinetic information. For example, one branch of information architecture focuses on findability, with little or no concern about how the content itself comes into being.

Knowledge architecture, on the other hand, deals with potential information. So, rather than determining the best way to use existing content, the knowledge architect is designing "spaces" that encourage knowledge to be created, captured, and shared. In this respect, the actual content doesn't matter as much as the life cycle -- how and when it gets created and how best to get it to the right people quickly. For example, collaboration strategies may focus on the structure and set up of team spaces or discussion forums -- how they get created, how they operate, how people find them and vice versa. But the actual tasks and topics discussed in those spaces are up to the teams that use them and may not be determined to long after the strategy is completed and in place.

That is not to say that knowledge architects don't have plenty of traditional information architecture/content management responsibilities as well -- such as taxonomies, web site structures, search interfaces, etc. But what sets them apart from other information architects is their focus on the design of spaces and the processes that support knowledge being exchanged, rather than on the knowledge itself.

Monday, March 10, 2008

Please, Enough with the 2.0 Already

I am tired of 2.0.

It's not Web 2.0 that I object to, that's not the problem. Tim O'Reilly's moniker for the recent developments in web applications really caught the imagination of the populous because it does an excellent job distinguishing today's social computing from the previous iteration of the web as well as from the theory and as-yet unmet expectations of the semantic web.

No, I like Web 2.0. It is all the other two point oh's I object to. First there was Enterprise 2.0, which is an expression I try hard not to use. There is very little benefit calling something Enterprise 2.0 over web 2.0 in the enterprise or social software applied to business. It takes the identification of a truly revolutionary transformation in computing and turns it into a fuzzy catch phrase.

But it got worse. I started hearing about Knowledge 2.0 in the KM community, Training 2.0 among my friends in instructional design, and most recently Work 2.0.

Stop it! For one thing, if we are talking about work, we must be at version 10.2.2 at a minimum. (I'll explain my numbering scheme later, if anyone cares.) Web 2.0 is, at least in part, both responsible for and a manifestation of the latest transition of work in its constant cycle between waves of oppression, cooperation, and exploitation. But don't confuse the two.

So let's make a pact: no more 2.0. If you really think you have identified a revolutionary and transformative trend, come up with your own label that can accurately describe it and
represent that trend. Don't leech off the creativity of others and confuse the issue by attaching a clear name for something happening today to fuzzy, ill-defined initiatives or wishful thinking.

Monday, March 3, 2008

Is Corporate KM Obsolete? (The Threat of Social Software, Part 4)

(continued from Part 3)


Knowledge Management does not occur inside the firewall alone. It happens inside the firewall, outside the firewall, and throughout the expanding universe of the company's employees and their communities -- which regularly ignore corporate boundaries.

Some might say that what happens outside the firewall is more chaos than management, but there is a significant amount of self-regulating process and order applied to the knowledge shared in the public domain. Distribution lists, Yahoo groups, forums, societies, and professional organizations all apply varying degrees of structure to their conversations and content.

Even blogs -- the random diary entries of millions of users -- develop an organic structure through the network of topic tags , blogrolls, cross-references and trackbacks.

So if, as I argued, the knowledge environment outside the firewall is far larger, more active, and in most cases more effective than that inside the firewall, what is the point of having corporate KM? Are we fighting a losing battle trying to keep knowledge inside the intranet?

Well, those are two separate questions with two separate answers. To the first question -- is corporate KM obsolete in the age of web 2.0 -- the answer is not quite. KM (and IT) as currently practiced in many companies around the world, is running against the tide and going to come under increasing criticism as more and more of the MySpace generation enter the workforce.

The answer to the second question -- are we fighting a losing battle to keep knowledge inside the firewall -- is a resounding yes. Corporate KM is not obsolete. But KM as currently practiced in many companies is certainly headed in that direction. The issue is being able to distinguish between what is most effectively (or securely) managed within the castle walls and finding the appropriate synergy with the knowledge flourishing outside.

Breaking Down the Walls

Corporate KM has traditionally been practiced as a self-contained system. Much of this has to do with preserving the privacy and secrecy of corporate activities. Clearly, you do not want employees discussing unannounced products out in the open. Also, many of the processes within a corporation could be considered intellectual property that needs protecting.

Another reason for the insularity is that organizations want a very high level of performance from their internal communities. In the past it has been hard to find a critical mass of similarly trained and like-minded professionals. Professional organizations, such as ACM, and annual conferences on various topics provide some amount of interaction between professionals from different companies. But the connections are limited and take time to establish and maintain.

With the introduction of web 1.0 and web 2.0, anyone can quickly find both information (search) and people (blogs, forums, and social networking) in similar fields and with similar interests and technical ability. Because of the seemingly limitless scope of detailed technical and business information available on the web, you do not even have to know the individual to learn from their experience.

More importantly, there is no "entrance fee". A new virtual community is created each time you perform a search or scan feeds from selected blogs. The low (no) cost of entry, plus the unparalleled volume of content, plus ready access essentially makes any professional a self-contained "consultant" in their own field of expertise. Employees are no longer dependent on their employer or their employment for their technical expertise and their career development.

Resistance to Change

As beneficial as this newfound independence within the workforce is to the company (in terms of self-directed career development and finding answers to problems which might never have been uncovered within the company itself), it is also a threat. Independent employees are threatening to the corporation for two reasons: loss of control and fear of poaching.

Corporations have traditionally taken responsibility for "developing" their employees both in terms of teaching work processes and encouraging specific job skills. They also tend to claim ownership over all the information the employee garners during their employment -- and they are very possessive of that knowledge. Some have new employees sign agreements not to work for competitors for a set period of time after they leave. Others sue when they fear confidential information will be given to a new employer, as in the case of Google and Microsoft fighting over Dr. Kai-Fu Lee.

More recently, there are companies that have gone so far as to attempt to ban employees from blogging or commenting on blogs because they are a "conflict of interest" or endangering the company's reputation or intellectual property.

These all-or-nothing approaches to IP protection are in conflict with reality and -- more importantly -- in conflict with the employees' perception of knowledge ownership. They blur the distinction between what is the intellectual property of the company and what is the professional experience and expertise of the employee.

Intellectual Capital vs. Intellectual Property

As an example, I personally know a fair amount about Microsoft SharePoint. We were a field test site back when it was known as Tahoe. I was involved in the original structural design of the SharePoint infrastructure for my company, and I continue to support SharePoint as a content architect. Having lived through three versions of the product, I have a fairly broad working knowledge of the technology and its uses.

That knowledge was garnered as a direct consequence of my employment as a knowledge architect. Some of that knowledge is intimately linked to my knowledge of the company itself: the specifics of how the sites are structured to support the internal organization, what applications use what data, even the names of the specific servers and services within the corporate firewall. That information could fairly be considered the intellectual property of the corporation since it is specific to the company and revealing it outside could potentially damage its business prospects (by exposing internal plans or structures).

However, knowledge about how SharePoint works and how it can be applied to different business situations is not specific to my current company. It is part of my professional expertise. This can be considered part of the company's intellectual capital -- the resources it has available to it to produce products or offer services.

One way of thinking* of the distinction between intellectual property and intellectual capital is to look at the consequence of an employee's leaving. If I were to quit my company, their SharePoint infrastructure would not change; the structure, server names, applications etc would stay the same. They retain their intellectual property. However, my professional expertise in SharePoint would no longer be available to them to modify or maintain the system or its content. They would lose whatever intellectual capital I personally provide.

In other words, intellectual capital is the knowledge I can take with me and make use of in a new endeavor separate from my previous employer. Intellectual property is the information that stays with my employer and whose context is specific to their business and not dependent on my working there.

Striking a Balance

So what does this mean in terms of knowledge management? It means that corporations can benefit significantly by allowing and encouraging employees to share and expand their professional intellectual capital in the larger external world of forums, communities, wikis, blogs, etc. Their professional development, and their ability to apply it to their job, will increase much faster when they have access to the broader professional community.

At the same time, the corporation can benefit by focusing internal efforts on two key aspects of KM:

  • Managing the intellectual property that drives the corporation -- optimizing internal processes and the sharing of company-specific information.
  • Maximizing the synergy between intellectual property and intellectual capital -- helping employees find appropriate resources outside the firewall and making the connections between internal, company-specific processes, and the generalized, profession-specific knowledge available on the internet.


Finally, the company is still responsible for preserving the security of its intellectual property and trade secrets. The employees are responsible for holding up their end. However, the employees do not always know where to draw the line.

If the company takes the old Draconian view of all or nothing, for the employees to participate in the new web 2.0 information economy, they are left to choose for themselves what to share or not. The company and its employee become adversaries fighting over knowledge that in most cases no one benefits from restricting.

Rather than trying to block all external sharing (or going too far the other direction and sharing everything), companies can help both their employees and themselves by providing guidelines about what knowledge is professional expertise and what is legitimately intellectual property of the company. Names of employees, development projects, internal services, as well as descriptions of proprietary processes fall should all fairly fall under the rubric of trade secrets. Knowledge of a professional nature -- expertise in the use and application of tools, products, or methodologies -- are all part of the employee's professional identify and "toolkit" and do not warrant restrictions.

By helping the employees understand and employ this distinction, the company can help leverage the "wisdom of crowds" for both their own and the employee's benefit.

*I am using a broader concept of intellectual capital and intellectual property than the purely legal definitions. In particular, I believe the crux of the issue lies primarily in the definition of "trade secrets". Explicit Intellectual property, such as copyrights and patents, that can be isolated and articulated poses very little threat of misinterpretation. But the implicit IP of what what comprises a trade secret and suitable for protection will prove much trickier to define.