The late great management guru, Peter Drucker, helped to innovate theidea that there is a whole economic class known as the Knowledge Workeronce said: "Nobody has really looked at productivity in white collarwork in a scientific way. But whenever we do look at it, it isgrotesquely unproductive." In other words, trying to define how tomeasure the productivity or performance of Knowledge workers (commonlycalled white collar workers), is an exercise in futility.
Davenport's bookpoints out that it is hard to create a common correlative measurementaround "knowledge workers" as a whole class. In fact, he describes thatthe typical way of dealing with knowledge workers is the HSPALTA approach: Hire smart people and leave them alone. Unfortunately, this doesn't really examine how to improve the system or help people improve themselves.
Maybe we will eventually discover some future magical formula thatmeasures this performance and how to improve it. In the past, inAgricultural societies, we had found ways to improve agriculturaloutput. Farmers from the dawn of time will tell you that "farming is anart", but the truth is that farming is also a science. Art issubjective, hard to measure, quantify and teach. Science is morestructured and actually can be taught (although not necessarily easily).During the Industrial Age, we achieved similar goals for manufacturingoutput. Now that we are in the Information Age, we are stumped, becauserather than a physical unit output, it is more of a mental qualitativeoutput, and that seems to us a very subjective element.
The good news is, as Davenport points out, there is at least one way to measurethe quality of knowledge. It's been done for centuries: the Peer Reviewprocess. It's most common in academia, whereby a group of your peersexamines your output and gives an analysis of what they think of it.It's how Masters and PhDs are still given out for the most part,worldwide.
I think that this is a good thing for us because that Peer Review process is atechnique that can be applied to unstructued knowledge on our site. Inits simplest form it is a Ratings systemwhereby anyone reading a piece of information on the site can vote 1through 5 on what they think of the article. It's entirely subjectivebut if you get a large number of ratings, it tends to average out whatpeople think of the information. This can apply to structured as wellas unstructured knowledge. This is the first level of a Ratings model.
That's a very basic notion. In fact, to be more useful, you may want tocollect all those ratings per a person's knowledge output and store itand those knowledge output items as part of their identity. Thus, youcan see what a person has contributed and produced and what peoplegenerally think of their output (their level of quality). This is amore evolved Rating system, generally referred to as a Reputation model.
Then, in turn, you could use a person's current rating as a weightingfactor to any rating they apply to others; i.e., normalize the value ofthe function of "my current rating" multipled by the rating value theyascribe. Thus when an industry luminary says you have a good idea, itweighs more towards the rating of that information, than when a novicerates it. Thus you have a weighted average of your Reputation based onwho actually rates your articles. This is a second evolution of Ratingsinto a weighted or a Ranked Reputation model.
How do you yourself become such an "industry luminary"? Essentially, alot of high-ranked people giving you good ratings implies that a lot ofknowledgable or influential people think that your output has a highlevel of quality. Thus, you would appear higher on the rankingshopefully amongst those lofty people who are the luminaries.
Community and social computing
com Marcações: unstructured_knowledge X
rawn 100000R0P5 Marcações:  reputation knowledge_workers unstructured_knowledge trust_models 2.586 Visualizações
rawn 100000R0P5 Marcações:  unstructured_knowledge use-cases knowledge_workers blogging 1.449 Visualizações
Davenport in his book Thinking for a Living points out that the are essentially four basic types of activities carried out by Knowledge Workers in a line starting from :
For example, developerWorks is involved primarily in the activities ofPackaging and Distribution. We rely on authors, contributors, bloggers,and other experts to create the knowledge. We then package thatknowledge in various forms: articles, tutorials, blogs, briefings etc.We then offer a distribution mechanism for these pacakged knowledgethrough our web sites, our live events, etc. This is made available toour readership so that they may try to apply it each to their own uses.
The packaging part is the difficult proposition now in the light of unstructured knowledge.The dW web sites has typically been a e-zine in the past with manyZones each reflecting a magazine along some topic that appeals to someaudience. The knowledge comes from many sources, both within andoutside IBM to attempt to get the best coverage on a topic we can.These are structured into the semblance of an article or a tutorial.
Unstructured or less-structured knowledge, however, is where dWCommunity comes in. It's less structured because it does necessarilyfollow some kind of content format that people are familiar with: thereisn't necessarily an order to how the information is formatted, wherethe answers lie, where to look for more resources, or sometimes evenwho wrote the information or what their reputation/skill level in thesubject is. There is also usually little formal or standardized editinginvolved.
On the other hand, unstructured knowledge is where there is a hugeamount of growth, everywhere on the Internet. Take our blogs forexample: every blogger has their unique style on how they post theirknowledge, or even what kind of info they provide; while it isstructured according to the goals of that person, every visitor has totry to figure out each post or each blogger in context of others. Thisis both good and bad; it invokes style and personality to a greaterlevel. However, not everyone is a born-writer or blogger. Lots ofpeople go to school and study journalism just to learn how to do it;others, I will daresay like myself, have a natural apptitude for it.
To become more useful to those Knowledge Appliers, it helps to know howto better package your knowledge. While blog systems provide a tool forpresenting the knowledge, they don't automatically make you a betterwriter or a better blogger. With unstructured knowledge like blogs, fordW for example, we now share the workload of knowledge packaging withour experts, in exchange for greater freedom for them to carry oncreating knowledge about their activities. We also carry out anotherpart of the Packaging aspect through the blog tool itself.
What we (dW) need to provide is guidance. We collect the ideas,information, practices and success stories on what makes for goodhabits, techniques and practices for more successful blogs. We sharethat information with our bloggers as much as we can. In addition, wecontinue to workon ways to better distribute this knowledge across the site and the net.
Take the example of our blogs and multiply it for each other type ofcommunity tool (wikis, forums, podcasts, etc.) and you can see the rolewe provide in this Knowledge activity line in terms of unstructuredknowledge. When you consider that much of this is still fairly new orbleeding edge, we sometimes have to do the bleeding in the process offinding out what works and doesn't to better support our unstructured knowledge creators.
Unless of course someone else wants to handle that function ;)
rawn 100000R0P5 Marcações:  unstructured_knowledge knowledge_workers social_computing 1.309 Visualizações
Ive just started reading Tom Davenport's new book Thinking for a Living, a great book on the issues surrounding knowledge workers.
If you havent heard of this term, you may not realize that you are (in the IT industry) very likely a knowledge worker yourself. This kind of work is a difficult to quantify, and even describe, but essentially involves all those jobs where people spend the majority of their time thinking of solutions for a living (doctors, lawyers, managers, programmers, etc.) rather than building many unit pieces of the same thing (e.g., manufacturing, production or labor-intensive work). This may still be an unfair description.
In fact, even the book indicates that the term has been measured in many different ways. In the US, the Labor statistics report is not categorized this way, so analysis by different academics point to there being anywhere from 30 million to over 100 million knowledge workers in the US alone (thats from 10-30% of the population).
The book makes for a fascinating read. For me, it provides valuable context to understand how developers worldwide do or think of their work. For example, Davenport indicates that there are some common attributes for knowledge workers, no matter their job:
It is these last two points where I find good relevance to my own job. Im probably a typical knowledge worker; in fact, my current job can be categorized as heavy knowledge work, but also some production work.
For the production work-side, I am responsible for getting more people blogging, discussing, debating, and interacting on technical topics on our site through our various community areas. Loosely, that translates to getting more instances of blogs, forums, wikis, and other such tools, started and running. I certainly have help from many others to get this going.
On the knowledge work-side, I work on our community strategy and direction, and lead our large community project currently in development in dW. This means I work with our infrastructure and development teams to describe the technical idea and debate solutions. I work with our research team and do research myself on different Web 2.0 and community activities around the Web. I work with our design, user experience and information architecture teams to consider how to present, organize, and direct this information. I work with our content teams to consider how to use or how to get others to use our community system, generate content, and participate in activities. I work with our management to present, consider and strategize what we should be doing in all these areas. Finally, I work with other teams and people outside dW, in IBM and beyond, to discuss many of these areas in relation to Web 2.0 and community. Believe me, that's a lot of phone calls and knowledge exchange.
To summarize: I suck information in and spew (hopefully useful) knowledge out across many different personas (people and groups).
Continued from my previous post...
As I said, we already have an internal taxonomy data structure that is used for our internal search engine, for categorizing our content, etc. It's crucial to keep this or things start going array when those tools are used. Each item in that taxonomy is used as a tag for marking items.
Now for dW Community, currently only the bloggers have their own "Category" tags, which are separate from the dW taxonomy. Because each blogger can create their own tags personally categorizing any of their posts, this can result in many variations of the same tag (same idea, different names), conflicts in the semantic usage of tags (different ideas, same name), and even ownership of those categories. Thus, you can think of these tags as having their own "individual scope" and exist in a different tag space than the full dW taxonomy.
Thus, there are now two scopes of tags: personal, and dW.
Next comes the issues with the big improvements coming in 2006. The plans for 2006 have been laid out but we haven't completely worked out the full tasks and implementation model. Hence, I haven't really described it yet... BUT it is coming and it will have a BIG impact in change! (we hope for the better in many ways)
So, with the new plan, we will start considering another scope of tags: those that span community-wide as a general folksonomy (see previous post).
In this scope, dW Community members can create a tag that exists in the public scope that anyone else can add, modify or even delete items from. This is where we start trusting our users to do what's best for themselves.
With any folksonomy there is potential for abuse and disaster when:
Thus, a pure folksonomy can become total chaos if the facilities to backtrack, undo, alert, or generally administer those tags are not available.
Yet another way to do this is to introduce a new type of scoping. You still have a folksonomy, but you subdivide topics at a high level, and break them down into groups. Each group can have its own tags created by anyone in that group. It's folksonomy in limited scale and actually breaks the original idea some, but limits widespread chaos.
So thus the potential is that there may be a number of scopes: individual, group, dW, global
How do you refer to each of these scopes?
Globally-unique naming of each scope is usually enough.
With our shift towards the more social interaction of Web 2.0, we're currently trying to figure out what makes sense in terms of defining topics and taxonomies in developerWorks.
We already have an internal taxonomy which is used as a table of data in things like our search boxes (see the choices for "topics").
Now we are tackling the issues of how do we build a new taxonomy-like structure that also allows community members to contribute. This is very much in the folksonomy concept in sites like: del.icio.us, flickr, 43things.com, etc.
First, a quick review of things that contribute to complexity of these issues.
There are a number of faces of the same thing which I'll define to point out the differences:
In addition to these concepts, dW itself has some concepts we use regularly, primarily the zone which covers a major topic that we want to publish information on. Thus a zone is a variant of a topic. We also have had "special topics" (smaller than a zone), an "area" (also smaller than a zone), a "station" (guess what: smaller than a zone).
I've been playing around with TouchGraph's Google Browser to see how our blogs are linked in from other sites, and displays it in a graph network showing other sites searchable on Google that have pointers to your own blog.
I'll try to take a snapshot of the results later and paste that in here.
The U.S. Army has a useful phrase: Ground Truth, the truth of a matter as it actually exists on the "ground". It's also called by a number of other terms such as the "real stuff from the trenches", "where the rubber meets the road", etc.; pick a cliche. I found this out in Don Cohen and Laurence Prusak's excellent book In Good Company: How Social Capital makes Organizations Work.
The ground truth indicates that the actual matter of a deployment may be different or call for actions other than prescribed procedures, pre-planned processes, etc. In reality, this is quite common in software development and deployment too.
More significantly, understanding or learning the ground truth comes from experience and direct participation. This understanding varies depending upon the specific situation but can be something that occurs again and again for others.
This kind of knowledge really lies in the hands of those on the ground themselves. In many cases, the knowledge itself is not easily describable in a simple, generic repeatable manner but requires a lot of qualification.
To paraphrase Fox Mulder: the ground truth is out there.
The only practical way to get to it is to help people to communicate and participate in discussion. And that is just what we want to aim for in developerWorks Community.