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
with Tags: knowledge_workers X
rawn 100000R0P5 Tags:  reputation knowledge_workers unstructured_knowledge trust_models 2,497 Visits
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 ;)
Continuing my thread on knowledge workers, and how to get them to share their knowledge...
Davenport indicates that knowledge workers value their knowledge skills, but often do not share it easily.
The former part indicates that knowledge workers are proud of the ideas and knowledge they produce, and of the fact that they were able to come up with it. They see value in them. Therefore, one idea to increase productivity of knowledge workers is to give visibility or accolade to their ideas.
Unfortunately, the latter part is oh so true: if a knowledge worker does not feel secure in their environment or community, they are unlikely to share it, especially if it means that by sharing that knowledge, they may even be helping someone else take over their job.
Im an optimist in this area, and with the rise of open source and a more open worldwide environment (especially in our industry), we may be able to trust others enough to break down this barrier.
Take a look at this earlier post on a sort of universal meme about communities. This suggests that to get towards innovative ideas, you need to progress your community of people from the earliest stages of first getting them to interact to create a level of understanding and familiarity between the people in the organization. With a level of understanding you then have a platform that allows people to build trust between the community-members, and with that trust, some can explore and experiment on ideas and thereby develop a greater entrepreneurial spirit. Finally, once you get that level of mentality, you can finally succeed in innovation through your community.
Obviously, with Davenports statement, the sharing of knowledge lies in the very first few stages. If you cant get people to trust each other--even in a contained environment--you wont get knowledge sharing in action.
If you have a strongly-connected employee base, you have developed that level of trust or at least a level of understanding amongst the people in your organization. You still need to encourage others to experiment, as in our Think Fridays in IBM. For a small organization it is easier to distribute new ideas, but to achieve knowledge sharing of those ideas in anything beyond a few hundred people, you really need to consider a common tool to collect, rank, sort and share all those ideas.
That kind of tool is exactly what we have in IBM right now in the form of our ThinkPlace tool and system. The IBM Innovation team offers this tool whereby any of the 300,000+ people in IBM could share their ideas; these ideas are then sorted or ranked by popularity (by software and also by hand). Not only does this do great justice to enabling knowledge workers in our organization but it is also leading a lot of our own innovation, not just for new product ideas, but also for company-internal improvement.
In its simplest form, it is a sort of open discussion group with many threads that anyone can start up around their idea. This is more than a 21st century version of the old "Suggestions Box" found in many companies yesteryear which was a closed box only viewed and analyzed and action taken on by management.
Thinkplace is a more open process whereby your peers can look over the ideas and weigh in on its merits, rather than someone in management dealing out commandments. In fact, it is also a way for employees in other divisions to mine this idea database for things that might relate to their work. The managers from the Innovation team, in this respect do exactly as their titles suggest: they manage the flow of this output in useful channels to find the best ideas.
We have ThinkPlace in operation already, but now consider the next step towards integrating community.
As I mentioned in a previous post, you can use your blog to implement free-thinking time (e.g., Think Fridays in IBM), since many bloggers use this tool to share their ideas and knowledge. This certainly provides a useful business case to retaining and supporting knowledge workers.
Now consider how to export some of those ideas from your own blog into a community tool like ThinkPlace. Each blog post which is specifically is an idea should probably be tagged and then "pushed" (through software preferrably, or via manual copy) to the ideas database.
The reason to do this is because blogs are part of the new Web 2.0 mentality of a model of participation. In other words, people who are bloggers are starting to embrace a more open and willing stance on sharing their knowledge.
An experienced blogger is used to the idea of posting to their blog on a regular basis. All we are talking about here is categorizing particular posts and make it easier to export that into a public space like the ThinkPlace tool. This reduces the tool-usage time to transfer knowledge into a tool where that can be considered by a wider audience. In fact, for bloggers thats also a good thing: more exposure to your ideas on your blog, and possibly even showing some real outcome of your ideas.
Thus, the knowledge workers can create their ideas and contribute for a mass audience to consider and analyze; the organization behind that audience can create an idea pool that is self-defining and self-directed to produce new innovations; and both the members and the organization can benefit from discovering and implementing these innovations.
For the knowledge worker, this suggests not only building a regular practice for participating in communities but also offers a reward mechanism in seeing some of their ideas appreciated and maybe even implemented by the overall organization.
So, unless you think you dont really need innovation out of your organization, this suggests a useful business case for different kinds of community tools, for the growth of the organization as well as the happiness of your knowledge workers. And, oh by the way, in doing this, youve just created a knowledge sharing and capturing process.
On the last two points that Davenport made in his book: to get commitment from a knowledge worker, it is important give freedom to experiment and work on ideas rather than to always dictate or direct them to work on specific things. Also, just as it is difficult to describe the job, it is also often hard to describe the knowledge output; for that matter, knowledge workers may not even seemto be in their best interest to share their knowledge.
The concern is that if you do not provide the correct supportive environment for your knowledge worker, they are quite likely to move to another organization that does (i.e., jump ship to a potential competitor who does offer the right environment).
This has direct relevance to a number of activities in IBM. For one, we now have Think Fridays. Basically, Fridays of every week should be freed up so that you have some peace of mind to consider, experiment, or talk about new ideas. Each person should apply that to their job as they see fit. I hear that 3M has something similar in that engineers should put aside 15% of their time to this kind of free-thinking.
For me, this tends to free up my regular weekday packed with phone calls with different groups, and sit back and think of the issues and changes to our project, or new ideas that have emerged. Others in our division use this time to experiment with new technology. C.J. and Peter on our team have even extended this to Think Friday-Build Saturday-Test Sunday, which I agree is certainly going beyond the call of duty, and very applaudable.
Now, consider Think Fridays on a different level across all IBMers. In particular, think of what people do in blogs and different community areas: discuss, digest, or produce new ideas. In fact, if youre an avid bloggers, you probably have Think-Mondays, Think-Tuesdays, etc., but in less than a full days time. Thus by blogging, as a knowledge worker, you are very likely and effectively using that free-thinking time.
So my advice to bloggers in IBM (and even beyond): Consider using a portion of your Friday to blog, because by blogging you are in effect implementing the spirit of Think Fridays.
Obviously, not all the ideas that you have are something you would want to discuss on a public blog. In that light, for IBMers we have an global intranet system called BlogCentral, which is a safe environment to discuss ideas with other IBMers. This quickly points to the necessity of having a blog system not just for an external audience but also one for a company-internal audience. Therefore, for knowledge workers within an organization, it is important to have an organization-wide blogging platform.
So for those looking for a business case for why you need a blogging system inside an organization, this is one good example. Blogs allow an expression of Think Fridays (or your organizations equivalent) which many companies think is an important aspect of encouraging, supporting and keeping happy their knowledge workers. I would generalize that to any number of other community tools, not just blogs.
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).