Knowledge work Archives - Page 24 of 38

More from Dan Pink on the Science of Motivation and Purpose

My long-time friend (old is such an ugly word) Vaughn Merlyn at IT Organization Circa 2017 points to the following fascinating animation to a speech by Dan Pink on his most recent book Drive, which I reviewed here earlier this year. It’s well worth 10 minutes of your time to watch.

We are in the midst of learning some immensely meaningful stuff about how our minds work in recent years. I’m willing to bet that those organizations that factor this knowledge into their designs first are going to make significant strides in the next few years.

Managing the visibility of knowledge work

Debates over whether the Internet is making us smart or stupid are entertaining in the bar and can serve as a pleasant background noise for ruminating during a keynote address in a dimly lit hotel ballroom. When I get back to work on Monday (or more likely on Sunday night) I return to the reality of working in a fundamentally digital environment. My files are digital, my tools are digital, and most of my interactions are digital.

As a knowledge worker, much of what I get paid for happens inside my own head. Before the advent of a more or less ubiquitous digital environment, however, that head work used to generate a variety of markers and visible manifestations. That visibility was important in several ways that weren’t evident until they disappeared:

Seeing work in progress in front of me made it possible to gauge my progress and make connections between disparate elements of my work.
Different physical representations helped to quickly establish how baked a particular idea was.
Physically shared work spaces supported rich social interactions that enriched the final deliverables and contributed to the learning of multiple individuals connected to the effort.

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. The benefits of visibility are now something that we need to seek mindfully instead of getting them for free from the work environment.

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 client report, for example, is an important part of the apprenticeship that transforms a recently minted MBA into a seasoned advisor. The visibility or invisibility of knowledge work products can make this process more or less difficult.

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 then 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 commenters reacted to different parts of the product. Knowledge sharing was a free and valuable side effect of processes that were naturally visible.

With e-mail, word processors, spreadsheets, and presentation tools, maintaining visibility of your knowledge work (at both the individual and workgroup level) requires mindful effort. An office full of papers and books provided clues about the knowledge work process; a laptop offers few such clues. A file 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 risks becoming 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 obscures 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 might 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 practice. The capabilities are there but they are irrelevant if they aren’t used intelligently. A version control system doesn’t do anything until you incorporate it into the routine practice of creating a new document.

The right starting point is to simply make the flow of work more visible. I suspect that this is one of the underlying attractions of social networking and micro-blogging. They promise to restore some visibility to digital team work that we lost in the first generation of tools.

If visibility is, indeed, important to effective knowledge work what else would you recommend as ways to manage and increase the visibility of the intermediate and end products of knowledge work and the people-to-people interactions that take place in creating those products?

Reflections from the 2010 Enterprise 2.0 conference (#e2conf)

I’m just back from the Enterprise 2.0 conference in Boston. Fortunately, there were a number of bloggers more proficient than I at tweeting and reporting on the action as it happened. Bill Ives, Mary Abraham, and Patti Anklam all provided excellent blog posts, while the tweet stream at #e2conf was rich.

What follows are some reflections provoked by being simultaneously immersed in the virtual and physical experience. I expect all will be topics that I will return to here and with clients.

Enterprise social software platforms

The feature sets of the various social software platforms are now effectively identical and are also essentially mash-ups of Facebook, Twitter, WordPress, MediaWiki, and Documentum. The problem i have with this is that feature sets aren’t terribly relevant in whether enterprises will succeed in efforts to derive value from these platforms.

I’m reminded of something that my wife regularly finds extremely annoying. She’s a photographer and an excellent one at that. When people see her work, they always want to know what kind of camera she uses. What she’s taught me, of course, is that the equipment is largely irrelevant. What matters is the photographer’s eye for composition and for the moment.

We’re in a similar situation with enterprise social software and are still working out the relationship between tools and creators. At the moment that appears to mean a bit too much focus on tools and not enough on the creators and their practices. There was certainly a lot of talk about the importance of understanding and influencing behavior in the hallways. We actually know quite a bit about individual and group creativity; it’s time we spent more effort to integrate that knowledge into the user experience. I expect we’ll see some interesting collisions between technophiles and organizational designers.

From workflow and process to light weight coordination

The notions of business process and workflow that we’ve developed over the course of deploying ERP systems and other large-scale operational systems don’t translate well to the realm of knowledge work. Unfortunately, like the proverbial hammer, they are the only notions most have and the results are painful for those of us who don’t happen to be nails. Greg Lloyd of Traction Software has been using the term "light weight coordination" and his colleague Jordan Frank has been talking about Social Process Reengineering and has coined the term Emergineering, which is at least a provocation in the right direction.

The problem with process and workflow is that they lead you into trying to nail down with precision activities that only work with an appropriate degree of looseness. They also emphasize translating judgment calls into hard and fast business rules. The goal in enterprise 2.0 is not to extend process/workflow concepts to the ends of the enterprise. The goal is to offer a degree of transparency and appropriate support to the judgment calls that continue to exist.

I don’t think this issue is widely recognized yet, but I predict we will find our existing concepts about process and workflow are too inflexible and constraining to help with knowledge work arenas.

Making the case for Enterprise 2.0

What’s the ROI is still a perennial question. Not, however, a terribly useful one when framed in this seemingly business-like shorthand. ROI is a tiny piece of mathematical machinery at the tail end of a complex organizational process of allocating scarce resources.

Enterprise 2.0 is in much the same place we were in the in the early 1990s when organizations were debating the merits of email and local area network investments. Back then we talked about "stealth infrastructures" and about how to piggyback investments on top of big efforts that had the necessary organizational backing.

Resource allocation in organizations is a political, economic, and occasionally theatrical process. Better to acknowledge this from the outset than to continue the search for the perfect spreadsheet.

Unpacking organizational culture

Organizational culture was another shorthand term that was in frequent use last week. Organizational culture is an amalgam of which behaviors are celebrated, encouraged, tolerated, risky, and forbidden. It encompasses who has power and influence and who does not. It’s the stable patterns that emerge when you observe all the instances of individual behavior in the organization.

Organizational culture is not a variable that you manipulate. It sets the context within which the behaviors you would like to promote will be evaluated as desirable, undesirable, or neutral. Culture is malleable over time, but the change emerges from the accretion of new behaviors.

Checklists for more systematic knowledge work

The Checklist Manifesto: How to Get Things Right, Gawande, Atul

The idea of a simple checklist to raise the quality of a routine practice seems innocuous enough. It also seems to rankle those with lots of education and experience as an unnecessary intrusion on their autonomy.

The canonical example is the story of the effort at Johns Hopkins Hospital to reduce central line infections in critical care settings. A central line is a catheter inserted into someone’s jugular vein in order to deliver medications. It’s a routine step for many patients in a critical care unit. It’s also a primary source of infection for patients in hospitals. While inserting a central line is straightforward for someone with the proper training, medical professionals will skip steps in the hustle and bustle. Peter Pronovost, a critical care specialist at Hopkins, developed a five-point checklist of the steps necessary to avoid central-line infections.

There’s absolutely nothing on the list that practitioners aren’t already trained to do and absolutely nothing controversial about the steps called for. Many of those professionals considered it an insult to have the obvious pointed out to them in written form. Yet when this checklist was deployed at Hopkins, central line infections dropped from 11% of patients to zero. Comparable results have been routinely achieved elsewhere.

Gawande reported these results first in an article in The New Yorker. In this book he expands on that story to look at

the origins of the modern checklist in WWII aviation
multiple examples of checklists deployed in other health care settings
the challenges inherent in developing checklists that work well in complicated environments
the difficulties in gaining meaningful acceptance of checklists among highly autonomous professionals

We live in an increasingly complicated and faster-paced world. But our memories are limited and fallible. The right piece of paper in the right place can compensate for those limitations and increase our capacity to deal with that world. The first balancing act is to design a checklist that increases our capacity to handle a situation significantly more than it increases the load on our limited memories. Pronovost’s checklist only touched on the five items most critical to preventing infections. It made no attempt to spell out every possible step in the process.

A checklist shouldn’t be confused with a procedure manual. Avoiding that confusion is an essential element in making organizational acceptance of checklists possible. Checklists are intended to improve and systematize the performance of those who are already proficient. In themselves, they are poor tools for developing proficiency in those still learning their craft.

This confusion between checklist and procedure is at the root of most resistance to efforts to deploy checklists in suitable settings. Unfortunately, Gawande contributes to this confusion himself when he conflates checklists with project plans. Both are useful documents but they serve different purposes and are constructed differently. I’d suggest that you skip the chapter on "The End of the Master Builder" on first reading. It makes the core argument clearer.

Even when properly designed and targeted as relevant aids for the proficient, there is still a change management and leadership challenge to address in deploying a checklist to support more effective practice. While Gawande offers a number of excellent stories and examples of implementing checklists in various settings, he isn’t looking for or tuned into the relevant details of organizational change. This book provides excellent insight into why checklists work and what to think about when constructing them. Expect to look elsewhere for comparable advice on managing the associated change. Expect to need to do so as well.

As compelling as the rational evidence for checklists may be, orchestrating their adoption into the work practices of professionals presents a large hurdle. The hurdle, of course, is emotional. A checklist can be viewed as diminishing one’s expertise rather than as reinforcing it. Reversing that perception for both the expert and the rest of the organization is the key.

Chromakey and knowledge work

I came across the following YouTube video the other day while checking out Boing Boing (one of my favorite sources of interesting and provocative stuff).

Fascinating in its own right, but I keep coming back to it and thinking what it also has to say about the world we work in. Some thoughts:

Don’t let the scenery distract you from the action
Focus on a powerful story to lead your audience’s attention where you want it to go
Anchor your stories in people and their interaction

What do you think?

The problem of incentives in knowledge work

Image by The Value Web Photo Gallery via Flickr

I’m struggling with the issue of incentives in organizations trying to promote improved knowledge management and more effective use of new collaboration tools such as blogs, wikis, and the like. Invariably, after an early spurt of activity and experimentation with the new systems, usage plateaus and talk turns to devising incentive systems to promote more participation. Behind the talk is the assumption that we can treat knowledge workers as rational economic actors and that the proper incentives will produce the desired behaviors.

The problem is the raft of research demonstrating that we are anything but rational economic actors. Spend any time digesting the insights in such work as Dan Ariely’s Predictably Irrational or Daniel Pink’s Drive: The Surprising Truth About What Motivates Us, to pick two recent examples, and you conclude that most organizational incentive systems are naively designed at best and actively harmful at worst. While carrots and sticks might be marginally useful if you need to crank out widgets or insurance claims, they aren’t for any work requiring significant creativity or discretion. Yet, we keep trying to devise simple reward systems and wondering why they fail.

The underlying issue is that focusing on designing incentives feels safer and easier than dealing with the hard managerial work of sitting down one-on-one with the individuals and planning out how to integrate these new tools into the day-to-day execution of knowledge work tasks. As Tom Davenport put it so pithily in Thinking for a Living the default managerial approach to knowledge workers is to "hire smart people and leave them alone." If the quality of knowledge work done by an organization is, in fact, a key differentiator in overall success, then this laissez-faire approach to managing knowledge work isn’t likely to be sustainable.

Behavioral complexities of knowledge work

There are actually two problems to be solved. The first is to get a handle on the behaviors that contribute to more effective knowledge work. The second is to understand what kinds of feedback will influence whether knowledge workers engage in the desired behaviors.

Consider the kinds of behaviors that you might see in an organization using its existing knowledge more effectively than average. Activities you might expect to see include:

Seeking out and finding experts elsewhere in the organization who can answer your questions
Experts in the organization making time to respond to questions they receive
Experts recognizing when repeated questions signal an opportunity for a new service or a deeper problem to address
Project teams experimenting with and adopting new practices such as After Action Reviews as part of their standard project plans
Individual knowledge workers revising their work practices to more easily find and incorporate previous work into new work

Multiplying examples would only reinforce the point that these behaviors are significantly more subtle and complex than those that find their way into typical incentive systems.

Rewarding something because it happens to be measurable isn’t going to help, even if that is the all too common response in organizations that have fallen hostage to empty dictums that "you manage what you measure." You manage what you talk about. If that conversation can be boiled down to where the needle is pointing on one or two dials, then you live in a much simpler world than I do and I envy you.

In my world, there is a complicated and often mysterious relationship between what people do and what happens sometime later. You invest in getting to know the key people at a small software vendor. They get an email inquiry from a company interested in updating their approach to knowledge management that the software vendor forwards to you. You reply to the email, have a brief phone conversation, develop and submit a proposal over the weekend, and, three days later, land a substantial contract with someone you still haven’t met face-to-face. How do you map that into a performance measurement system?

Consider another example. A consulting firm is encouraging experts to submit their best work to a central document repository. Your call center expert responds and contributes an Excel spreadsheet used to analyze operating performance in an outbound call center. One of your smartest consultants (with an Ivy League Ph.D. in Applied Mathematics) grabs the spreadsheet for another call center project. Unfortunately, the Ph.D. mathematician doesn’t have time to discuss the document with the resident expert and proceeds to employ it incorrectly. Client damage control ensues. Is this a design flaw in the knowledge management system? A training problem? A developmental opportunity? Was it a staffing problem when our Ph.D was originally assigned to the project? What measurement system would signal this problem before it occurred? What measurement system would reveal the problem after the fact?

Focus on better feedback systems instead of incentives

You certainly want feedback systems that provide a picture of how knowledge workers in your organization are interacting with the tools and information you make available to them. Better yet, these feedback systems ought to let you detect and deconstruct patterns of practice over time. What you can’t get is a manageably small set of measures that you can reliably link to performance. You can’t operate on autopilot.

Two approaches come to mind. Both assume that individual knowledge workers have primary responsibility for figuring out how they contribute to creating value for the organization. Secondary responsibility for coaching knowledge workers through this effort lies with their immediate supervisors.

The first approach is to look for successful patterns of use within the existing knowledge sharing system. Use After Action Reviews or other techniques to examine and evaluate how a particular knowledge sharing opportunity played out.

The second approach is to add some basic instrumentation to the knowledge sharing system. Make it simple to count things like blog posts made, comments made, documents contributed, documents consulted, and pointers shared. Use that data to distill and identify patterns of practice worth emulating. For example, some knowledge workers might be adding value by connecting and integrating materials in the system to create new knowledge. Others might be helping by weeding out obsolete information or adding important caveats. There won’t be a single pattern of successful usage that all should emulate. It is much more likely that there will be multiple patterns. The managerial task is to help knowledge workers identify the patterns that they are most adept at, helping them refine their usage patterns over time, and monitoring the system as a whole to ensure that there is a good balance among usage patterns.

This is clearly a more complex and judgmental task than simply rewarding everyone for contributing more content. But it feels more suited to the actual complexities of doing and managing knowledge work in today’s environment.

Jordan Frank on ‘responsibility to collaborate’ – lessons in enterprise 2.0 implementations

Jordan Frank is VP of Sales and Business Development for Traction Software. Last Fall, Paula Thornton ( @rotkapchen) interviewed Jordan during Traction’s annual user group meeting.

Jordan has been working with a variety of knowledge intensive organizations over the much of the last decade. Here he shares some of his insights on the interplay between technology capabilities and knowledge work practices.

Although there are some pretty good sound bites such as "responsibility to collaborate" and "documents as knowledge traps", i would encourage you to spend time not only listening carefully, but also reflecting on Jordan’s observations.

You need to develop a well-tuned design sense to take full advantage of the technologies intended to support collaborative and creative knowledge work. You need to be especially careful to avoid the temptations to over-engineer the technology or the process. The examples that Jordan shares are rooted in the augmentation philosophies of Doug Engelbart rather than the automation philosophies of Frederick Taylor.

Leadership and knowledge workers

Here’s a typically thought provoking session from TED. Conductor Itay Talgam uses videos of conductors leading performances as a launching point for reflecting on leadership.

For organizations that depend on the active and creative engagement of their knowledge workers (who doesn’t), Talgam’s perspective is especially relevant.