In-Depth

The Invisibility of Knowledge Work

In the digital world, bringing visibility to the process of knowledge work is the first step in making it more effective

• By Jim McGee
• 03/29/2005

The contribution of information technology to productivity continues to be a source of controversy, and more than a few consulting and academic careers have been built on arguing each side of the issue. Yet I am not aware of any of these thinkers who would give up their word processors or spreadsheets to go back to doing their work longhand. Knowledge work has become unrelentingly digital.

For all the productivity gains that accrue to the digitization of knowledge work, one unintended consequence has been to make the execution of knowledge work essentially invisible, making it harder to manage and improve such work. Attacking that invisibility opens an important path to making knowledge work manageable and improvable.

Knowledge work is better understood as craft work; its products are valuable because they are creative and original. Delivering identical consulting reports to different clients is grounds for a lawsuit, not an example of good knowledge management practice.

From a craft perspective, examining and understanding what constitutes a quality report is an important part of the apprenticeship that transforms a recent MBA graduate into a seasoned advisor. The visibility or invisibility of knowledge work products can make this an easy or a difficult process.

Before PowerPoint, crafted presentations began with a pad of paper and a pencil. You knew by looking at a roughed-out set of slides that it was a draft; erasures, cross outs, and arrows made that more obvious. You took your draft to the graphics department, where you were yelled at for how little lead time you provided. A commercial artist tackled your incomprehensible draft spending several days hand-lettering text and building your graphs and charts.

From there you started an iterative process, correcting and amending your presentation. Copies were circulated and marked up by your manager and hers. Eventually, the client got to see it and you hoped you'd gotten things right.

Work was visible throughout this old-style process. Moreover, that visibility was a side effect of the work’s physicality. Junior members of the team could see how the process unfolded and the product evolved. You could see how editors and commentators reacted to different parts of the product. Knowledge sharing was a free and valuable feature of visible processes.

In moving to e-mail, word processors, spreadsheets, and presentation tools, maintaining (preserving?) visibility of your knowledge work (at both the individual and workgroup level) requires conscious effort. An office full of papers and books provided clues about the knowledge work process; a laptop offers few such clues. A directory listing is pretty thin in terms of useful knowledge sharing content. In an analog process, it's easy to discern the history and flow of work. When an executive takes a set of paper slides and rearranges them on a conference room floor, a hidden and compelling story line may be revealed. You can see, and learn from, this fresh point of experience. That's lost when the same process occurs at a laptop keyboard at 35,000 feet. The gain in personal productivity occurs at the expense of organizational learning

In the digital process, who creates and what they contribute becomes more an exercise in political posturing and interpretation than simple observation. The abstracts in a document management system reveal little about what work is exemplary, new, or innovative, and hides emerging patterns.

Invisibility is an accidental and little-recognized characteristic of digital knowledge work. Seeing the problem is the first step to a solution. While better technology tools will play an important role, the next steps are changes in attitude and behavior at the individual and work group level. For example, organizing your own digital files into project-related directories can help, but not if you continue to name files "FinalPresentationNN.doc" where NN is some number between 1 and 15 representing a crude effort at version control. Embed more information in the file name where you know it will be visible even as you e-mail it around the organization. Use more informative subject lines on your email. Those file names and subject lines should provide the best clues possible as to what will be found inside.

Systems developers have learned that time invested in naming standards and conventions pays off. Teams crafting knowledge-work products should make the same investments. Better yet, spend time with good development teams and look for ways to adapt their practices to more general-knowledge work.

New disciplines take time to become habits. Fortunately, they also eventually become “the way we do work here.” As the disciplines take root, taking a more aggressive look at technology tools becomes appropriate. Many of the office suite tools offer some form of internal revision tracking or auditing tools. What’s missing is any systematic way to integrate these tools into a disciplined process. The capabilities are there but they are irrelevant if they aren’t used intelligently. A version control system doesn’t do anything until you put a process around it to specify what documents should be controlled and when. Specifying that process when the products must meet knowledge-work standards of quality and uniqueness is a different challenge than reengineering the payroll process.

The right starting point is to simply make the flow of work more visible. The classic advice in reengineering has been "Don’t pave the cow path." Before you pave anything in the realm of knowledge work, you need to see where the path is going.