Review – Only Humans Need Apply

Only Humans Need ApplyOnly Humans Need Apply: Winners and Losers in the Age of Smart Machines
Thomas H. Davenport, Julia Kirby

In his most recent book, Tom Davenport, along with co-author Julia Kirby, provides an excellent entry point and framework for understanding the evolving relationship between smart people and smart machines. There’s a great deal of hand-wringing over technology encroaching on jobs of all sorts. This is hand-wringing that arises with every new technology innovation stretching back long before the days of Ned Ludd. Davenport and Kirby avoid the hand-wringing and take a close look at how today’s technologies—artificial intelligence, machine learning, etc.—are changing the way jobs are designed and structured.

They articulate their goal as

“to persuade you, our knowledge worker reader, that you remain in charge of your destiny. You should be feeling a sense of agency and making decisions for yourself as to how you will deal with advancing automation.”

In large part, they succeed. They do so by digging into a series of case histories of how specific jobs are re-partitioned, task by task, between human and machine. It’s this dive into the task-level detail that allows them to tell a more interesting and more nuanced story than the simplistic “robots are coming for our jobs” version that populates too many articles and blog posts.
Central to this analysis is to distinguish between automation and augmentation, which they explain as

“Augmentation means starting with what minds and machines do individually today and figuring out how that work could be deepened rather than diminished by a collaboration between the two. The intent is never to have less work for those expensive, high-maintenance humans. It is always to allow them to do more valuable work.”

They give appropriate acknowledgement to Doug Engelbart’s work, although the nerd in me would have preferred a deeper dive. They know their audience, however, and offer a more approachable and actionable framework. They frame their analysis and recommendations in terms of the alternate approaches that we as knowledge workers can adopt to negotiate effective partnerships between ourselves and the machines around us. The catalog of approaches consists of:

  • Stepping Up—for a big picture perspective and role
  • Stepping Aside—to non-decision-oriented, people centric work
  • Stepping In—to partnership with machines to monitor and improve the decision making
  • Stepping Narrowly—into specialty work where automation isn’t economic
  • Stepping Forward—to join the systems design and building work itself

Perhaps a little cute for my tastes, but it does nicely articulate the range of possibilities.

There’s a lot of rich material, rich analysis, and rich insight in this book. Well worth the time and worth revisiting.

Lowering the costs of context switching

Context switching is expensive yet inevitable in our multi-tasking world. If you are a knowledge worker, lowering the costs of context switching may be one of the highest payoff investments you can make. How should we go about thinking about the problem of context switching to reduce those costs?

Switching contexts vs. switching tasks

A context switch is bigger than a task switch. Moving from answering one email to answering another is a task switch within a single context. Switching between answering email and drafting a client presentation or facilitating a planning meeting constitutes a context switch. Basic productivity advice encourages you to group like tasks precisely to avoid unnecessary context switches.

How can we organize our mental models, intellectual scaffolding, and the supporting environment to shorten the time it takes to shift gears from one context to the next? How do we reduce the time and effort it takes to get back in the zone and focus effectively on the task at hand?

It’s helpful to break the context switch process into three stages. For any one context there is a setup stage of getting all the elements for performing one class of tasks up and running. Second, when switching from one context to another, there is a teardown stage of clearing out all the elements of the first context to make room for the next. Finally, it helps to think of the space between two contexts as a third stage where we can do things to simplify and streamline the switch from Context A to Context B.

The first step is to make a particular context as standard, distinctive and evocative as possible. We want to setup a context to trigger the mental state we want to achieve. This is why writers often have a separate space dedicated to writing tasks. Research materials on the left, reference books on the shelf to the right, coffee mug in its familiar place and word processor open to where you left off the last time. Identify all the cues that evoke the mental state you seek and arrange them in their proper place. Other examples of physical contexts that prepare you mentally for the work at hand include a cook’s kitchen or a craft-person’s workshop.

Setting up a digital context

Increasingly, our contexts are largely or exclusively digital. Taking some cues from physical contexts we can call to mind, we might think of setting up our computer for a writing or a programming session in terms of opening a collection of applications and documents arrayed across our monitor(s) in exactly the same way every time we write or code. Few of us put that much thought into this setup process, but cognitive science suggests that we have something to gain if we do.

If you are a programmer, this is part of the logic behind encouraging the use of Integrated Development Environments (IDE); all of the tools and data you need for a coding session are available at once and each is in the same location on your physical screen. Over time, this means that the pattern of screens, data, and tools in front of your eyes maps directly to a comparable array in your mind’s eye. Using the physical patterns to evoke and trigger the mental patterns speeds your transition into programming mode.

By way of contrast, consider how else you might begin to work on a programming task. First, you open your favorite text editor, close whatever document might be left over from the last programming session, open today’s code module and begin to read. Launch a test machine and run the code until the code encounters an error. Then, load a debugger to examine the errant code. Then, open a document containing the program spec. Possibly, fire up a browser—or switch to a browser that is already open and pointing to a random site; search for a discussion thread relevant to the error code you are looking at.

Which scenario feels likely to be more productive and effective? Which is more common in your experience?

Breaking down a context

Whether analog or digital, switching from one context to another starts, ideally, by wiping the slate clean. In the analog world, leaving a context behind can be as simple as leaving a room and closing the door.

The digital world is a bit trickier. Leaving random elements of the preceding context cluttering the landscape means your mental landscape starts out comparably cluttered. Better to break down a digital context by closing all open documents and shutting down open applications.

The space between contexts

Switching contexts in the analog world might entail a short walk from an office to a conference room. Although brief, that physical transition serves an important function of easing the necessary shift of mental gears.

Shifting digital contexts can occur more or less instantly with a handful of keystrokes; that may not be a good idea. You want to give your mind time to complete its shift as well. This is one of the benefits of the Pomodoro technique, which deliberately builds in breaks between mental sprints. The breaks are the ideal spot to locate context shifts in your work.

There are some other things you can do to ease shifting from one digital context to another. For example, to the extent you can control it, order context switches such that adjacent contexts are as distinct as possible. For example, switch from working on a spreadsheet analysis to writing a report rather than switch between two reports. Better yet switch between writing a report and debugging computer code if your collection of tasks is sufficiently broad.

Make different contexts as visually distinct as possible to engage more of the senses in making the switch. If you are using the Pomodoro technique, contemplate clearing your monitors to some standard, neutral display as a resting step between adjacent contexts

Context switching and team work

We’ve been focused on context switching as an individual cognitive task. Most of us do large portions of our work in team settings. How does context switching apply to team environments? On the one hand, moving between teams and team venues probably provides more than sufficient triggers to switch smoothly. On the other hand, the proliferation of virtual teams and the all too common experience of days of one conference call after another may be making the context switching problem worse. Can we extend our thinking about context switching to the team and virtual team level or is that simply a bridge too far?

Technology in the Classroom

There’s a nice piece over at Studypool talking to a dozen “experts” about effective use of technology in the classroom. I put experts in quotes mostly because I was deemed one of those experts. Kidding aside, the end result is a nice overview of productive ways to think about incorporating technology into teaching and learning environments. Better yet, it offers pointers to a diverse group of folks thinking about this problem.

This advice is more broadly relevant when you consider that, as knowledge workers, we are all tasked with learning on an ongoing basis. From that perspective, we need to have more effective strategies to incorporate technology into our learning whether the classroom is in an ivy-covered hall, an office conference room, or somewhere in cyberspace. None of us have the luxury of working in stable environments. We all must operate on the assumption that we need to assimilate new ideas and techniques into our work practices and do so on technology platforms that are also evolving.