Since we all use the term “knowledge worker” these days. I thought I would take some time to define just what I believe a knowledge worker is. Before reading on, take a stab at defining a knowledge worker for yourself. I’d be interested in any thoughts that you may have...
Let’s start by defining knowledge itself, which sits on top of a pyramid:
Data (or the seldom-used plural, datum) is a factual entity that sits at the lowest level, and is obtained through techniques such as measurement or observation. Information and knowledge are derived from data. For example, collecting data about automobile drivers such as their ages, sex, number of accidents provides the inputs that can be examined and turned into useful information.
Information is about examining the data (facts) and attaching meaning to the data. Examining multiple data points may reveal some type of pattern that gives form to the data; in effect, information becomes a representation and communication mechanism of the underlying data.
Continuing with the automobile driver example, analysis of the data reveals that young male drivers have a higher risk of getting into an accident than anyone else. The statistical observation attaches meaning to data obtained about drivers and their accident rates and becomes information – and input – used by insurance companies in determining how much to charge someone for automobile insurance.
Knowledge is the accumulation of information, experience, and reasoning about a particular subject or field. Knowledge coupled with skills and abilities becomes expertise. (Wisdom is a variant of knowledge, where the deepest level of insight is attained, in my opinion.)
There will be differences in expertise between individuals, as some people obtain a greater understanding of their field than others in the same field. Even where expertise is equivalent, there can be differences in opinion because each person has different experiences, preferences, and values. Back to the automobile drivers one more time, knowledge is used to actually determine how much to charge different drivers, as represented by their risk. As you may have noticed, no two insurance companies charge exactly the same rate for automobile insurance.
Now that knowledge is explained, it is an easy step to define a knowledge worker: Someone who engages in the active application of knowledge to achieve a specific purpose, or someone who initiates a new data-information cycle to generate new knowledge – advancing their field. A knowledge worker applies existing knowledge or develops new knowledge.
Knowledge work is not routine. Knowledge work can involve analysis, strategizing, planning, prioritizing, brainstorming, critical thinking, or creating. Knowledge work is about dealing with difficult situations that cannot be directly addressed through pre-defined solutions.
Software development falls into this category. Writing software is not about building the same application over and over again. There is uniqueness involved every time.
Routine work can be handed off (ideally) to a computer. Referring back to the automobile insurance scenario, many times it is a routine decision for an insurance company to insure someone. Standard questions can be placed on a web site, and based on the answers to those questions a decision can be made (paraphrasing William Shakespeare’s Hamlet) “to insure or not to insure…” – along with determining how much it will cost to insure someone – by pre-programmed logic. Exception conditions outside the norm can be forwarded to an underwriter for analysis and a decision.
Challenges with Knowledge Work
Knowledge has value and this value will decrease over time. The world is continually changing, and information is being generated and circulated at a phenomenal rate. Knowledge that is pertinent and relevant today may be of little value five years from now.
In general, keeping relevant (knowledgeable and valuable) over time requires continual learning, reflection, adaption, and application of new knowledge. This places a demand and challenge on knowledge workers to manage their time to provide for learning and growing. “Maintaining” in the knowledge arena is effectively taking steps backward. The world will move past you.
All knowledge is not easily captured. Some things can be captured and written down in a form that is understandable to others. An insurance company deciding what questions to ask and what calculations will be performed to determine a premium is an example. This is “routine knowledge” (once it is created) that can be captured and used repeatedly by less knowledgeable people.
Some knowledge – tacit knowledge – is more of a challenge. You can capture instructions about how to ride a bike, but reading about riding a bike will not enable you to immediately ride a bike the first time that you try. Book-learning can be like that as well. You might understand the concepts, but the author has different experiences and values than you do. The truth is that you might need to get some personal experience under your belt to truly understand and value some of the concepts that an author conveyed.
This is also why “knowledge transfers” in organizations can be challenging. If you expect that a one or two-day “knowledge transfer” will fully prepare someone to fill another’s shoes in exactly the same way, you will be dissapointed. In fact (and since this is a blog about managing software development), software development is effectively a knowledge transfer exercise.
The goal is to translate business knowledge into software. This requires a collaborative effort to represent the business in a very precise, step-by-step processing of instructions to conduct business transactions on a computer. This collaborative effort alone is a challenge, as those on the business side do not understand computers as deeply as those who write the software, and those who write the software do not understand the business as deeply as those involved with the business.
And there is another problem that lurks with software: The knowledge – expertise, values, and experience – of the few business representatives involved with software projects often speaks for the many. The big question is: What are the odds that the judgment of those few will be correct?
This is why building software in small increments is valuable. It allows the software to be viewed by many early and often. Soliciting of feedback allows course-corrections; better to set a course and make small adjustments along the way than to sail directly into rocky waters – where you will sink – because you wanted to maintain your original course come hell or high water.
If you're looking for another (humorous) perspective, blogger Steve Schwartz has a great post about The 3 Types of Knowledge.