Category: Knowledge work

The Art of Procrastination: A Guide to Effective Dawdling, Lollygagging and Postponing,
Perry, John

I began my formal relationship with the notion of procrastination at the age of 12. I was in my room working on a model plane instead of my homework. My dad came in and asked me to look up the word “procrastination”; without lifting my head or skipping a beat, I answered “sure, I’ll do it later.” The model parts were pushed aside and the dictionary landed on my desk. I was invited to read the definition aloud.

I read this slim volume in 2013, which confirms that I am part of its target audience. Written by Stanford philosopher John Perry, The Art of Procrastination is largely tongue-in-cheek but contains some of the most useful advice for living with procrastination that I’ve encountered since my abrupt introduction in my youth. Perry recommends a basic coping strategy that accepts the reality of putting things off and leverages a small bit of self-deception to actually manage to get things done. He labels his strategy “structured procrastination” and argues that procrastinators “can be motivated to do difficult, timely, and important tasks… as long as these tasks are a way of not doing something more important.

This will seem counter-intuitive to those who don’t routinely procrastinate. For those of us who do, however, this finally makes sense out of how we’ve ever managed to get anything done.

Perry offers other useful insights as well. For example, he differentiates between horizontal and vertical organizers; those whose work needs to be spread out to see versus those who can effectively file things away in cabinets when they aren’t pertinent to the task at hand. He also offers an intriguing take on perfectionism and procrastination. The impact of perfectionist thinking isn’t in soaking up time in endless cycles of tweaks and revisions. The impact comes from fantasies of producing the perfect deliverable preventing the procrastinator from starting the prosaic work of turning out a serviceable product. That was an insight that hit a little too close to home.

If Perry’s notions of structure procrastination ring true for you, add this slim volume to your pile and read it as a way to avoid working on some other pressing task.

Invisibility is an accidental and troublesome characteristic of knowledge work in a digital world. What makes it invisible? Why does it matter? What can you do about it?

How did knowledge work become invisible?

As a knowledge worker, I get paid for what happens inside my head but not until I get the work outside where it can be seen. Before the advent of a more or less ubiquitous digital environment, that head work generated multiple markers and visible manifestations. There were handwritten notes from interviews, a presentation might start with rough mockups of slides scribbled on a pad of paper. Flip charts would document the outcomes of a group brainstorming session. A consulting report would start as an outline on a legal pad that would be rearranged by literally cutting and pasting the paper into a new order and organization. Computer code started as forms to be filled out and forwarded to a separate department to transcribe the forms onto punch cards.

No one would want to return to that world of knowledge work.

Digital tools—text editors, word processors, spreadsheets, presentation software, email—have eliminated multiple manual, error-prone, steps. They’ve made many low-value roles obsolete—sometimes by unintentionally giving them back to high-cost knowledge workers.

These same tools also reduce the physical variety of knowledge work to a deceptively uniform collection of keystrokes stored as bits in digital files hiding behind obscure file names and equally  uninformative icons. A laptop screen offers few clues about the knowledge work process compared to an office full of papers and books. A file directory listing appears pretty thin in terms of useful knowledge content compared to rows of books on shelves.

Why does the visibility of knowledge work matter?

If you can’t see it, you can’t manage or improve it. This is true as an individual knowledge worker and as a team or organization.

Noticing that digital work is invisible reminds us of benefits of analog work that weren’t obvious. Among those non-obvious benefits;

• Different physical representations (handwritten notes, typed drafts, 35mm slides) establish how baked a particular idea is
• Multiple stacks of work in progress make it easier to gauge progress and see connections between disparate elements of work
• Physically shared work spaces support incidental social interactions that enrich deliverables and contribute to the learning and development of multiple individuals connected to the effort

Consider how developing a presentation has changed over time. Before the advent of PowerPoint, presentations began with a pad of paper and a pencil. The team might rough out a set of potential slides huddled around a table in a conference room. Simply by looking at the roughed-out set of slides you knew that it was a draft; erasures, cross outs, and arrows made that more obvious.

A junior level staffer was then dispatched with the draft to the graphics department, where they were chastised for how little lead time they were provided. A commercial artist tackled the incomprehensible draft spending several days hand-lettering text and building the graphs and charts.

The completed draft was returned from the graphics department starting an iterative process, correcting and amending the presentation. The team might discover a hidden and more compelling story line by rearranging slides on a table or conference room wall or floor. Copies were circulated and marked up by the team and various higher ups. Eventually, the client got to see it and you hoped you’d gotten things right.

The work was visible throughout this old-style process. That visibility was a simple side effect of the work’s physicality. Contributors could assess their inputs in context. Junior staff could observe the process and witness the product’s evolution. Knowledge sharing was simultaneously a free and valuable side effect of processes that were naturally visible.

Putting knowledge work on the radar screen

The serendipitous benefits of doing knowledge work physically now must be explicitly considered and designed for when knowledge work becomes digital. The obvious productivity benefits of digital tools can obscure a variety of process losses. As individuals, teams, and organizations we now must think about how we obtain these benefits without incurring offsetting losses in the switch from physical to digital.

Improving knowledge work visibility has to start at the individual level. This might start with something as mundane as how you name and organize your digital files. You might also develop more systematic rules of thumb for managing versions of your work products as they evolve. Later, you might give thought to how you map software tools to particular stages in your thinking or your work on particular kinds of projects. For example, I use mind-mapping software when I am in the early stages of thinking about a new problem. For writing projects, I use Scrivener as a tool to collect and organize all of the moving pieces of notes, outlines, research links, drafts, etc. The specific answers aren’t important; giving thought to the visibility of your own digital work is.

Teams should take a look at the world of software development. Software development teams have given more thought than most to  how to see and track what is going on with the complex knowledge work products they develop and maintain. Software developers have carefully thought out tools and practices for version management, for example. Good ones also have practices and tools for monitoring and tracking everything from the tasks they are doing to the software bugs and issues they are working to eliminate. These are all ideas worth adapting to the broader range of knowledge work.

Organizations might best adopt an initial strategy of benign neglect. I’m not sure we understand knowledge work in today’s world well enough to support it effectively at the organizational level. Knowledge management efforts might seem relevant, but my initial hypothesis is that knowledge management is hampered, if not trapped, by clinging to industrial age thinking. We’re likely to see more progress by individual knowledge workers and local teams if we can persuade organizations to simply let the experiments occur.

I have over 49,000 files in the documents directory and its subdirectories on my computer. They span nearly thirty years of output writing, teaching, speaking, and consulting. These represent the knowledge assets that support my livelihood. I am willing to claim that this is likely to be typical of today’s knowledge workers. That means there is a knowledge management problem to solve at the personal level that precedes any organizational knowledge management requirement. The answer depends on being smart about naming things; in particular, about naming files.

This is a problem that snuck up on me; I muddled along for years before recognizing it and gradually crafting strategies to deal with it. At first, I thought of it as a problem of where to put things; a place for everything and everything in its place. The desktop metaphors of file folders and hierarchical directory trees fooled me into thinking that the answer was to replicate the practices of generations of file clerks and librarians. Wrong. The affordances of filing cabinets and bookshelves lead you in directions that create unnecessary problems and obscure the opportunities inherent in the digital realm.

The work of pioneering thinkers like Vannevar Bush, Doug Engelbart, Ted Nelson, and Tim Berners-Lee seemed to offer a way out. They painted a compelling picture of how knowledge work might flourish once everything was digital, reachable via clickable links, and cleverly indexed by the engineers and algorithms at Google. Progress, but these visions glossed over the question of how to create and manage all the digital goodies to be found at the other end of all those links. That’s the world that you and I spend our days in; a world of email, Slack, Dropbox, shared drives, and files. Lots of files; 49,000+ and counting in my case.

The choices you make the first time you save a file can either complicate or simplify your life tomorrow, next year, and five years from now. Here’s a file name I just pulled off my laptop from an old project;

Final Presentation v.3.31.ppt

I’m willing to bet that you have a similar file somewhere on your computer. In fact, I’m willing to bet that you have several files with that or a similar name. Now, you would be correct to surmise that this file was originally found in some project directory at the end of a path something like /Documents/CLIENT/CustomerServiceReview/. That doesn’t help you very much, however, without access to my computer. Things are slightly better if we are both working off of a shared drive or Dropbox folder. On the other hand, what if I need to email the file to a client whose IT department blocks access to Dropbox?

These are problems that occur when you share a file with an incomplete or ambiguous name. Weak file names also cause problems for the individual knowledge worker. While you will only name a file once, you will have frequent opportunities to decide whether to look inside a file based on its name. You will often be making that choice while scanning through a list of potentially relevant files—either a directory listing or the results of a search.

Over the last several years, I’ve evolved a set of rules or guidelines for choosing a file name. As a sort of meta-rule, I start from the perspective that I will write the name only once, while I will read the name and decide what to do based on that name dozens or hundreds of times over the course of a project or a career. Here are the names of two files from my computer:

Brin-Page-AnatomyofaLarge-ScaleHypertextualWebSearchEngine.PDF

NSC-TLA-PKM-StrategyWhyAndHow-2011-04-21-1104.pptx

The first is a journal article I want to have ready access to; the second contains the slides for a talk I gave to a networking group I participate in. Let’s dissect the names to see what they tell me. The first file name is straightforward; it identifies the names of the authors and the title of the journal article. It contains all I need to decide whether I want to open the file to read it or whether this is the particular file I’d like to share with a colleague.

The second takes a little bit more effort to decode, although I can decipher the code on the fly, which is my principal concern. If I share the file with you, the code might slow you down a little bit but you can still extract the necessary information with no knowledge of my system. Let’s breakdown the name into its components and see why its constructed the way that it is:

• PKM-StrategyWhyAndHow- This is simply a descriptive name for the contents of the presentation. “PKM” is my shorthand for Personal Knowledge Management.
• 2011-04-21-1104 This is a timestamp for when I created the file. When I created this file, I was using timestamps that included the time as well as the date. In my current practice, I only record the date. I use a keyboard macro program (TextExpander on my Mac, ActiveWords when I am working in Windows) to enter the time or datestamp.
• NSC- This is a shorthand code for the organization I was part of at the time I wrote this talk. I’ve been affiliated with a number of different firms and institutions over the years and I find that who I was working for is a consistent memory trigger.
• TLA- This is a shorthand code for the particular client I prepared this talk for. Another meaningful memory trigger.

There is a design logic underlying these names and a series of principles and considerations that have and continue to evolve:

• Descriptive File Names: All modern file systems permit long file names. Use them. I choose names based on what they suggest about the contents and what will jog my memory later
• Ordering of Name Elements: My basic ordering of name elements is Organization, Client/Project, Descriptive Name, and Datestamp. It’s basically a hierarchy to collect items in sorted lists
• Shorthand Codes: I try to keep these codes at three letters each. I’ll deviate from that if something longer makes more sense. The codes are derived from the organization, client, project. etc. in a way that serves as a mnemonic for me. Three characters yields over 17,000 possible combinations so I’m not worried about running out. I don’t maintain an actual list; the code is a trigger for me to recall the actual organization. Here are some of the codes I currently use to offer a flavor of what I mean:
  • LOY – Loyola University Chicago
  • HCG – Huron Consulting Group
  • CMN – Collaborating Minds
  • NSC – New Shoreham Consulting
  • TLA – Technology Leaders Association
  • PKM – Personal Knowledge Management
• Embedded Datestamps: Computer operating systems keep track of various file dates, so why bother to add a date to the file name? Because the operating system timestamps serve the operating system’s purpose and can change for any number of reasons. The embedded timestamp reflects a date that has significance to me. For example, it might be the day I delivered a particular talk.
• Technical Considerations: Although most operating systems allow spaces in file names, I don’t use them. Instead I either capitalize each word (Title Case or CamelCase if you’re a wiki user) or use a dash to separate sections of the file name. I also try to avoid other punctuation characters to avoid potential problems in some operating system settings. Probably a holdover from my programming days.

This is a system that has evolved over time; much of it was not designed. I am not fanatical about any of it; utility today and tomorrow is the deciding factor. I do try to avoid the temptation to think any file is “only a temporary file.” I don’t try to be religious about any of this and keep the following passage from Jorge Luis Borges in mind:

These ambiguities, redundancies and deficiencies remind us of those which doctor Franz Kuhn attributes to a certain Chinese encyclopaedia entitled ‘Celestial Empire of benevolent Knowledge’. In its remote pages it is written that the animals are divided into:

(a) belonging to the emperor,

(b) embalmed,

(c ) tame,

(d) suckling pigs,

(e) sirens,

(f) fabulous,

(g) stray dogs,

(h) included in the present classification,

(i) frenzied,

(j) innumerable,

(k) drawn with a very fine camelhair brush,

(l) et cetera,

(m) having just broken the water pitcher,

(n) that from a long way off look like flies.

There is no curriculum on how to be an effective knowledge worker although we live in a world dominated by knowledge work. We identify ourselves as knowledge workers. But what comes after that?

Peter Drucker observed that the defining characteristic of knowledge work and knowledge workers is that the first question is “what is the task?” (see Knowledge-Worker Productivity). In manual work, the task is a given. It is defined in advance of hiring the worker and its various inputs, outputs, and structures define who the appropriate worker is for each task.

All knowledge work begins with the question of what is it that I am expected to do. Nothing in conventional education or conventional organizational thinking prepares us to deal with this question. This goes well beyond questions of self-management or self organizing systems. It implies that we each have responsibility as both designers and executors of our work. It is not sufficient to understand the ins and outs of Microsoft Excel or Microsoft Word. If we have some responsibility for defining what the task is, then we have some responsibility to understand why the task is relevant and how it fits into the broader picture.

This complicates our lives as both individual knowledge workers and as members of larger organizations. This obsoletes conventional job descriptions. Every job now has components of project management, of strategic thinking, of analytic thinking, and design creativity. What does this imply for how we educate and develop ourselves to be effective as knowledge workers? Note that I’ve focused this question on our individual responsibilities. That leaves another set of questions for the educational institutions and training organizations that lay claim to preparing us for the environment in which we work.