Category: Knowledge work

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.

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.

Knowledge management matters more to you than to your organization

I gave a talk on Saturday for ChicagoLand PMI about why knowledge workers needed to develop strategies and the supporting habits and practices to manage and develop their know how across organizations and across time. If you’re interested you can find a copy of my slides on Slideshare.

Knowledge management as buzzword and practice originated in solving organizational problems. That’s where the big, obvious, problems are as well as the budgets. But the roots of the problem lie in the changing nature of work and careers at the individual level.

My father worked for three organizations in his career; I’ve worked for twenty so far and the number is likely to climb. Some might argue that this reflects either a severe case of ADD or a general inability to hold a job. Regardless, the trend is real; knowledge workers will work for more organizations and have shorter tenures at each. Organizations worry about the knowledge retention problems this creates; I’m more interested in the knowledge management problems it creates for individuals. I am aware of a handful of people who are also thinking about this; Harold Jarche, Luis Suarez. If you know of others, I would love to hear about it. 

The nub of my concern is this. You cannot rely on your memory and the experience it encodes. You also can no longer rely on having access to the institutional memory and artifacts of any one organization to supplement your limited human capabilities. You ought to be thinking about and planning for how you will accumulate knowledge and expertise over time. What personal infrastructure should you be building that can travel with you? How should you adapt your work habits and practices to simultaneously deliver value to your organization and enhance the value of your personal knowledge base? What new practices and skills do you need to add to your repertoire?

Roots of Project Management

USS George Washington SSBN

I just wrapped up teaching an MBA level course in project management at Loyola University. I started doing project management in the 1970s and it has been an essential, albeit secondary, element of my skill set. During the course, I found it useful to look back to some of the origins of the field. Project management can be a second class citizen in many business schools; it feels too pedestrian next to courses on disruptive innovation or venture finance. I went looking for some interesting history to put these skills in broader context.

In that search I came across several papers that offer important perspectives on today’s practices and conventional wisdom. You can track them down from these links:

The first two papers take a look at the U.S. Defense Department programs from the Cold War that created the Polaris submarine and also promoted a story of advanced management techniques that was a more complex mix of technique and internal marketing than we usually acknowledge.

The third paper by Winston Royce is often credited as being the origin of the waterfall software development model that held sway for many years and is now ridiculed as often as it is praised. It’s revealing to take a look at what Royce actually said compared to what followed.

I find it valuable to balance knowledge of particular tools and techniques with a more general sense of the history and organizational realities that shape our use and understanding of those tools.

Entropy and knowledge management

What does the second law of thermodynamics tell us about knowledge management? There’s some pretty complex mathematics around the laws of thermodynamics, but the poet’s version will do for our purposes:

  1. You can’t win
  2. You’re going to lose
  3. You can’t get out of the game

Life is a constant battle against entropy or disorder. Cars break down; they don’t repair themselves. Left to themselves, files, books, and ideas become disorganized. Organizations and the knowledge workers inside them are engaged in a constant, but doomed, fight against entropy; the order they bring is always temporary.

Knowledge management is one of many disciplines engaged in that fight. If entropy is destined to win, what does that tell us about how to carry on the fight?

It reminds us that perfection is the wrong goal. You can’t define a perfect taxonomy; 100% compliance with the documentation standards is wasted effort; there will always be something more pressing than the paperwork. This matters because the personalities attracted to the apparent orderliness of knowledge management tend to be seekers of this impossible perfection. You want to temper that predisposition, not feed it.

Surrendering to disorder isn’t a good strategy either. Let the reality of entropy shape our strategies and practices. There are things we should worry less about and things we might better do differently.

We should worry a lot less about perfection and completeness and strive instead for a standard of “good enough”. That requires more judgment and sensitivity to unique circumstance than most organizations—and many individuals—are comfortable with. Black and white makes for easier, albeit impossible, compliance standards and management.

If you are in a position to shift an organization in the direction of more gray, encourage that. If you are enmeshed in unrealistic organizational expectations, strive for only as much compliance as will keep the auditors and censors at bay. I’m not advocating open rebellion, or even mild “civil disobedience”; simply be comfortable that you have the laws of physics on your side while you quietly ignore stupider requirements.

If entropy is the law, how might you operate differently?

Learn where small efforts now postpone or eliminate major remediation efforts. Whatever you opt to do now, you are going to live with that choice later. Make your choices with that appreciation of a disorderly later. You are never going to go back later to add the appropriate tag, improve the name of the file, or reorganize the project team’s directories. Recognize the places and moments where a tiny injection of order now will pay lasting dividends. Don’t pretend that you can get organized after the press of the immediate has passed.

Entropy is inevitable. As a knowledge worker, your task is to create pockets of order out of the noise. As you create those pockets, don’t increase the noise everywhere else.

EntropyAndKidsHMP Comics

Carve out time and space for deep thinking

 

Deep Work: Rules for Focused Success in a Distracted World, Cal Newport

If your value to an organization depends on the quality and insight of your thinking, Cal Newport’s latest book, Deep Work, offers important insights about how to think about your thinking. The forces at work in our environment and in our organizations favor quick, shallow, and social over other forms of thought. That is generally adequate for much of the activity that fills our days.

Exceptional value, however, finds its roots in sustained, focused, individual thinking and reflection. Deep Work builds the case for this mode of thinking and offers paths to carve out the necessary time and develop the necessary mental muscles to engage in deep work more intentionally and predictably.

Newport defines deep work as

Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.

The ability to think deeply is a skill, so it can be developed. Much of the book offers counsel on techniques and practices that can help you develop your skills at deep work.

Newport is an academic computer scientist. In his world the contrasts between deep and shallow work can be stark. His binary distinction doesn’t transfer neatly to organizational settings where it is more useful to think in terms of a spectrum of work with shallow and deep anchoring the extremes. With the pressure toward superficial and shallow, there is great opportunity for individual knowledge workers to become more proficient at going deep.

Newport does offer practical advice for how to make deep thinking more possible. That advice needs tuning and refinement to work well in most complex organizations. Newport sums up why that effort matters thusly;

A commitment to deep work is not a moral stance and it’s not a philosophical statement—it is instead a pragmatic recognition that the ability to concentrate is a skill that gets valuable things done. Deep work is important, in other words, not because distraction is evil, but because it enabled Bill Gates to start a billion-dollar industry in less than a semester.