Folksonomy in the Enterprise: Will it pay off?

Although semantics in content management are being discussed and marketed for a long time already and always make up for a cool topic at conferences, they are rarely being used in real life. It is already hard enough for CMS users to get the content right and it is even harder to put it in the right context of a metadata set (especially if it is a large controlled vocabulary). This is where corporate “librarians” come into place, who control the use of controlled metadata – but they cost money…

Theresa Regli, principal with CMS Watch, published the article Human Touch, discussing today’s problems and solutions to motivate users of content management systems to annotate/tag/classify/etc. information with metadata. The currently preferred solution for the taxonomy dilemma is group-dynamic annotation (folksonomy), as the article states:

â??The best motivation for tagging is almost instantaneous feedback,â? adds Busch. â??Things like Flickr,, and Technoratiâ??the key to those is the instantaneous feedbackâ??the alerts, the feeds, the group tagging. Thatâ??s why people get into it and get excited about it.â?

It will be interesting to see, how large businesses and SMEs will adopt that strategy. They are not likely to communicate with the outside world to establish a swarm-intelligent taxonomy. Large enterprises might set up their own tagging infrastructure, while SMEs fall back to existing vocabularies, but don’t share the tagged information externally.

Additionally, there are different levels of confidentiality concerning corporate information: Some of it is for all employees, other only for the top management, certain teams, etc. This fragments the group-dynamics due to confidentiality gaps especially in large enterprises, who could actually profit from a broad collective intelligence when it comes to a high quality folksonomy.

The big hope concerning Social Tagging For The Enterprise is of course to optimize knowledge flows and to save money. Yet, it needs to be testified whether collaborative annotation can really live up to its expectations in firms. The larger and more complex the corporate environment, the more likely you will need dedicated and professional metadata reviewers. It would be an illusion for large enterprises that folksonomy translates into knowledge-management-for-free. SMEs on the other side could suffer from limited resources to ever have a useful folksonomy at hand. They might be blinded by a massive tag cloud.

On the other side, as with all data that becomes part of the public domain: in the end, all sorts of enterprises and organizations could profit from social annotation, simply because experiences are already being made by many people. Related Open Source software and publicly showcased approaches are being constantly refined, existing tag collections are readily available to be directly included or used for inspiration. That will in sum lift up all enterprises when it comes to how effectively they make use of their organizational knowledge with the help of a tagging staff.

The question is not, how much enterprises will profit from folksonomies, the question is how effectively they will make use of it by combining social software with a corporate culture where most of the employees are happy to share what they know by providing hints what their knowledge means to colleagues.

My New Role: Chief Knowledge Officer

I have been appointed Chief Knowledge Officer (CKO) at eZ systems. Some of you might go “Uh, CwtfO???”, so here is what Wikipedia has to say about the CKO role:

A Chief Knowledge Officer is an organizational leader, responsible for ensuring that the organization maximizes the value it achieves through “knowledge”. […] CKO responsibilities include such things as (1) developing an overall framework that guides knowledge management, (2) actively promoting the knowledge agenda within and beyond the company, (3) overseeing the development of the knowledge infrastructure, and (4) facilitating connections, coordination and communications.

That’s quite a nice description. One special thing about eZ systems is, that it is an Open Source company, thus the borders between internal and external communication often do not exist. In fact, an Open Source company is just as much about an open communication as it is about open software.

This is actually the part I am most excited about: to explore the potentials of open knowledge management, which includes the eZ systems team just as much as the developers community, the partners, etc. In an Open Source ecosystem, knowledge management is very much a joint effort of all actors involved and can only follow a bottom-up approach.

With the CKO role, eZ systems is the only Open Source company I know of with a dedicated role for managing its knowledge and that of the whole ecosystem. It shows that eZ systems is serious about its slogan “Share your Information”.

If this all sounds too abstract to you, stay tuned, as I plan to write about concrete KM projects and their results in my Weblog.

Knowledge Commodities

To understand the difference between commodity products from the industrial and those from the knowledge sector means to understand the main difference between the industrial and the knowledge society – and why Open Source is cutting-edge.

Serving the Mass Market

First of all, when talking about a commodity, I think of a product for the mass market. Many software applications have indeed become commodity products, e.g. a well-known operating system. In respect to Open Source software, being a
commodity has been identified as one of three key factors for success.

Quantity or Quality

Software is a knowledge product, when you compare it to industrial commodities, e.g. doormats, is there any difference? The answer is that industrial commodities are physical goods and each new product will take resources to manufacture it. Hence, you always encounter the trade-off between quality and quantity with industrial commodities.

Quite different with software, as this is a virtual product. Software can be copied for almost zero cost, but developing it is a complex and time-consuming task. There’s actually no trade-off between quality and quantity when talking of software commodities and physical goods. The only trade-off concerning knowledge commodities like software is between quality and time.

Copy/Time vs. Optimization/Time

Concerning industrial commodities, there’s a copy-per-time ratio, because the amount of products you can create, is limited by the time it takes to manufacture each product. On the other hand, knowledge commodities have an optimization-per-time ratio. There, you don’t have to invest time to create copies of the product, instead, you can invest your time into making the product better.

Optimizing the Optimization

Due to the optimization-per-time ratio of knowledge commodities, the key to success for a software company is that it optimizes its optimization processes. Knowledge companies have the fear to become mentally lame and not agile enough to compete. In other words: they should take care of their potential to optimize the optimization-per-time ratio.

One measurable example would be more bug fixes in shorter time, but still, this would not say anything about the quality of the patches. High quality expectations need to be a natural part of every knowledge company and its organizational form and company culture needs to support every single employee to live up to these expectations.

Ecosystem of Optimization

Open Source companies and projects provide an open ecosystem to gain maximum optimization of their software commodity products, e.g. by bug fixes and new features contributed by third parties. In proprietary companies, the ecosystem is rather closed and they need to rely on internal resources mostly.

Now, the next question would be, whether the open or the closed ecosystem of optimization is more efficient and competitive? Let’s deal with it in another blog – this one is already long enough.

Mailinglists and Project Management

Mailinglists are quite useful as a part of daily project management. The way I use them at work is that I post rough ideas to the relevant internal mailinglist. Then my colleagues contribute with their ideas, comments and critique.

If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.

Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.

In a nutshell, the approach is:

  1. Post an idea to the mailinglist.
  2. Keep the discussion going until a decision for or against actions has been reached.
  3. Extract tasks from the discussion.
  4. Discuss single tasks in the mailinglist if necessary (go to 1.)

Communication Skills

This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.

Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.

As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.

Exchange of Information

Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.

The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.

As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.

If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.

Other Channels

Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.

Open Company Culture

Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.

In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills 🙂

Codified Personality

In Knowledge Management, there are the concepts of codified and personalized knowledge. Wikipedia describes it as

codification vs. personalization – the trade-off between capture and storage of explicit information and making connections to people who know.

This definition was missing the fact that personalization also refers to making external knowledge part of your knowledge, thus I added “as well as to acquire external knowledge yourself” to the Wikipedia page.

Anyway, what I wanted to say is, that it struck me again some days ago, how nicely the personality of one person or a whole group can show up in software. The way how a routine or API is designed can tell a lot about the personality of a programmer and his team:

  • How accurate is the code? (You can tell from that whether they do a wholehearted job and are commited to what they do)
  • How much abstraction is in the code? (Reflects the experience of the developers)
  • How much is the overall design of the software thought through? (A criteria for how well the team can organise itself)
  • How complex is the software? (A sign for a team that can master software by organisational maturity)

This is what you can call “codified personality” – it is what you can also find in arts, in books, paintings, music, etc. Thus, the “vs.” in Wikipedia’s definition of “codification vs. personalization” is not totally correct, because the two concepts are not only opposed to each other, but can also go together nicely.

Of course, it is only a small step from here to ask: If personality is immanent in code, can code change the personality? Strictly speaking, code cannot change a personality, but as code is always the result of humans, it is the social system that those humans live in, which influences their personality. It is not the code that changes the personality of a person or group, but rather the way how the code is treated within the social system you belong to. As software code is codified personality, this is indirectly about how your social environment treats you.

Think of open source and proprietary as social (sub-) systems, and you’re encountering another interesting question: How do software licenses, as part of the regulatory system of your company, influence your personality?

Opinion and Authority

In a company based on hierarchical authority, it is much easier to have a strong opinion when you’re on a high level of the food chain. If you’re on a lower level, the problem is that you might be wrong or that your honest opinion might be something your boss does not want to hear. Thus, you act in an opportunist way and only say what’s mainstream in your company.

Knowledge companies cannot afford to have this kind of behaviour, they need everyone to have a clear opinion. Or put it like this: knowledge companies need to provide the freedom to their employees to have or form their own opinion and communicate it within the company.

An egalitarian organizational structure and predictable working conditions are thus a prerequisite for a successful knowledge company. They cannot afford to have the management rule by verdicts and fear. Instead, it needs to be trust and mutual respect, what drives the management to motivate the staff.
The more quality the opinions have, the better the decision-making within the company, and the more it can act realistically in the market.

Linux goes Management

The way how the Linux community is organised gets growing awareness in management, not only in that of software companies. Harvard Business Review published an article entitled Collaboration Rules, were the Linux community is being compared with the organisational structure of Toyota. The article is in general worth to read. I have read the
German version which is published in the current issue of Harvard Business Manager.

The authors’ basic statement is: “Corporate leaders seeking to boost growth, learning, and innovation may find the answer in a surprising place: the Linux open-source software community.” And they continue: “Specifically, Toyota and Linux operate by rules that blend the self-organizing advantages of markets with the low transaction costs of hierarchies.”

Management will indeed be able to learn a lot from Linux or the FOSS movement in general, as it can be regarded as the prototype organisational form of knowledge work. Today, most products are knowledge-based, even if it is simply the design of your coffee cup. Thus, the culture of open sources can be applied to various companies of any kind.

The article analyzes what I’d call a company culture of open sources, where information is freely shared between various stakeholders of a production process, be it software (Linux) or industrial goods (Toyota). Such a company culture is very much one that gives community members or employees the freedom to develop their skills and personality.

Unfortunately, the article deals with the aspects of knowledge companies for individuals only marginally. It could nicely be approached from the notion of humans as open sources as elaborated in the latest book of Gunter Dueck: Topothesie (German only). Then it becomes obvious, that doing it the Linux way also means a change of management styles and human interaction at work in general.