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:
- Knowledge workers prefer being autonomous and having a greater free hand as to how they do their job
- Trying to define their work routine in terms of detailed steps is less valuable and more difficult than other types of work
- The best way to understand what a knowledge worker does is by shadowing or observing them in their work
- Knowledge workers usually have a good reason for what they are doing (although I will add, it isnt always easy to describe the why)
- If you want a knowledge worker to work on something, it is crucial to get their commitment in the work
- Knowledge workers value their knowledge, but dont share it easily/li>
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).