When we think about knowledge work productivity, it is a very tricky subject. The reason it is tricky is because at one extreme we can routinize knowledge work — as when someone is calling to fill out a survey, or answer a customer service call. In a low value added knowledge work task, there is some variation, and the motivation and attitude of the employee is still a very big and important deal.
(See Dick Walton’s Book Up & Running for an excellent discussion of commitment versus compliance based controls while implementing technology in organizations), but in the main, you can structure the work just the way you analyze and structure work in a factory. Frederick Taylor’s rules of scientific management with a dose of the worker involved, edge-based, data-driven approach of the Toyota Production System, can guide the design and management of the work.
Many organizations have over routinized knowledge work in a way that creates as many problems as it solves. All of us have experienced the frustration of calling a call center to solve a problem to only have the poor employee say something akin to, “Sorry, I know we should be able to fix that but I don’t have the authority and the computer won’t let me do it.” That is an over routinization of work. This is present in many companies. For example, insurance companies have often gone back and forth between treating claims like a production line in which each worker turns their own intellectual screw, to one in which the work is organized by teams of case workers who take each claim from start to finish. Both have their advantages and disadvantages.
In this low end knowledge work there are many simple things to fix — especially around technology. If software would rust, these would be more obvious. In many customer service systems, for example, we have the equivalent of a very messy physical factory. There are multiple customer numbers; systems don’t integrate; the response times are too long, the data are a mess — in short, if it were physical instead of digital it would look like a poorly managed factory of the 1950s. These can all be analyzed for process and economic improvement. They are not easy to do because most organizations have few true program and project managers, but these often valuable changes are easy to figure out for any experienced practitioner of process/technology improvements.
At the high end of knowledge work, I think we should turn to Doug Englebart, whose work has been aimed at helping highly skilled groups of people solve complex, interdependent tasks better and faster. He often referred to “raising the collective IQ of the group”. This is a very different animal than the tailorized call center work. If we stay in insurance, this type of task would be to deal with a complex commercial risk such as insuring an ecological risk of the new fracking technology. This type of complex, idiosyncratic, team-based work cannot be fully serialized, or automated. Instead, one needs to look at the factors Englebart identified in his HLAM-T model. In this approach he suggest that any complex work has a human being, with a language system, and artifact and a method — HLAM. In addition, this person can be trained in the language system, the method and the artifact, which is where the T in HLAM-T comes from: training.
We see great examples of this model at investment banks in trading operations. The trader has both a set of “quants” whose job it is to come up with new methods within the language system. Some of these quants can also code C++, Java, and they know the bank’s systems and data feed from outside sources. These are the bitsmiths I’ve written about before. They create the artifacts which embody the method and use the language system of the knowledge workers (in this case the traders). In fact, because the investment banks have made so much money on these traders (we’ll see how this plays out under Dodd-Frank, but that’s another story), the banks were willing to spend hundreds of thousands of dollars a year to pay these bitsmiths to help the trader earn millions which made the bank tens or hundreds of millions. At the very high end, knowledge work productivity is very skewed, but only a few organizations actually spend money rationally to drive the differential productivity of the very top end of their talent pool.
I have lamented before that we are too focused on automating knowledge work and not enough on Englebart’s ideas. I think that opportunity still confronts every firm.
Original post: http://www.sviokla.com/innovation/knowledge-worker-productivity/
