The costs of context switching

Multiple ScreensMulti-tasking doesn’t work but our lives demand it anyway. This leaves us with the problem of how to compensate for the productivity and quality losses generated by work environments that demand parallel processing our brains can’t handle.

Why can’t our brains multi-task and what happens when we try? Left brain/right brain discussions aside, we only have one brain and that brain is single-threaded; it’s built to work on one cognitive problem at a time. Most of us can manage to walk and chew gum at the same time, but we can’t read the paper and discuss changes in the day’s schedule with our spouse simultaneously.

The bottleneck is attention. When we pretend to multi-task, what we are doing is cycling focus among the tasks competing for our attention. Each time we switch focus, we have to re-establish where we were in our work when we left off before we can begin moving forward. We also have to set aside the work we were doing along with whatever supporting materials we were using.

This process of redirecting focus is a context switch. Context switching is expensive because complex tasks—writing a blog post, debugging code, analyzing sales data—depend on equally complex mental scaffolding. When writing a blog post, for example, that scaffolding can include notes on the points to be made, memory of relevant previous posts ideas about upcoming blog posts, links and open browser tabs to supporting research, and so on. That scaffolding might be spread across multiple computer screens and program windows. It might also handwritten notes or paper copies of relevant supporting articles. All of that supporting scaffolding, along with the current draft of the blog post, helps you build up the mental structures that eventually lead to a finished draft of your post.

Suppose now that I need to put aside the blog post in progress to take an incoming phone call from my boss. It’s a call about a proposal we are putting together for a client. It might be just a simple call to confirm a detail in the proposal document, or it might be a more complex discussion about whether to rethink and reorganize the entire proposal. Regardless, I need to set aside the work on the blog post and flush my mind of all the details. I then need to call to mind the salient details of the client and the draft proposal as the call unfolds. In the first moments of this call, I’m not likely to be terribly articulate or smart. As the call progresses, I may need to call up various supporting materials and gradually fill in an entirely new context to contribute to the conversation.

Switching tasks means that you have to also break down one context and stand up a new context before you can actually begin to do any meaningful work. When the call is complete, you need to reverse the process to resume work on your blog post. Will you recall the insight that was just coming into focus when you were interrupted by that call from your boss? Or is it lost forever?

How expensive is this context switch? Research from the world of software development (see Jeff Sutherland’s Scrum: The Art of Doing Twice the Work in Half the Time) suggests that switching between two projects can result in productivity losses of 20%. Add a third project to your list and the costs rise to 40%. This means that each project gets no more than 20% of your attention and focus. Is it any wonder then that professionals work the hours that they do?

Step one in solving any problem is recognizing it. Limiting the number of projects you are working on and carving out big blocks of time to focus exclusively on each project helps. This is the core advice of most time management gurus. Few of us, however, have that much control over our responsibilities. A more attractive target then is to think about ways to lower the costs of context switching. We’ll come back to that in the next post.

Review – The Art of Procrastination: A Guide to Effective Dawdling, Lollygagging and Postponing

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.

Making knowledge work visible

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.