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?

Reblog this post [with Zemanta]

The problem of incentives in knowledge work

WFEE09: Knowledge Wall/Gallery

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.

 

 

Reblog this post [with Zemanta]

Patti Anklam on The Year of Personal Net Work

Patti Anklam and I have reconnected after first meeting several years ago. We navigate in the same circles and our networks overlap, but I hadn’t been carefully following her work. My mistake and I’ve fixed that now. Here’s a recent piece from her with a very good overview presentation on moving from a general understanding of networks to concrete actions. Worth taking a look at both for the content and for some good ideas on presentation design.

Chris Brogan writes about his strategy for deepening his personal networks. He starts off his list of tips with this one:

"Devote two hours a week to this effort. If, out of the 60 hours an average person works, you can t find two for this, reconsider how you re running your day.

This is not the only new year’s resolution I’ve seen along this line. As we become more and more connected through social media, the more we are aware of what those connections mean.

My new year’s resolution? I’m resolving to share more of my thinking, especially about personal networks. Here’s a slide show from this past October I hope you will enjoy.

Personal Network Management Km Forum Oct 2009

The Year of Personal Net Work
Patti
Tue, 12 Jan 2010 20:52:00 GMT

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.

Excellent tips for more productive conference calls

Jessica Lipnack provides an excellent set of tips and best practices for making conference calls more productive. For all the time I spend on calls, I frequently find them immensely frustrating. I plan on incorporating these practices in whatever calls I can influence.  I’ve excerpted a few highlights here:

Could you please repeat the question?

As promised, best practices for conference calls. Not surprisingly, I’ve discovered that I’ve done quite a few posts on the topic, for instance, here and here and here.

And…why did I title this post the way I did? Surefire way to know if someone isn’t paying attention on a call: When asked to comment, they have no idea what they’re commenting on, thus, they say, "[see title]."

  1. No agenda, no meeting.
  2. Avoid status reporting
  3. Use screen sharing
  4. Rotate facilitator, note taker, timekeeper, "break" buddies
  5. Keep notes, display them, distribute immediately
  6. Check-in: go around face clock
  7. Get voices in room with "ice breaker" question
  8. Say your name each time you speak
  9. Generate heat: Discuss, disagree, decide
  10. Check-out around clock

The notion of a "face clock" is one of those wonderfully simple and powerful ideas that are so obviously useful once someone else has come up with them:

…6. Check in. Face clock? I better post that right here. One of the graphics that is useful for keeping people aware of one another has each person’s face at a particular hour on the clock. (Thanks, Tom Kunz, for inventing this idea and for allowing us to continue to use this graphic.)

Face clock

 

Could you please repeat the question?
Jessica Lipnack
Thu, 08 Oct 2009 21:03:17 GMT

You would do well to read the entire post (you should be following Jessica’s blog anyway).

Learning to love the backchannel

Just before Thanksgiving I was at the KM World 2009 conference in San Jose listening to a keynote presentation by Charlene Li. Like many others, I was tweeting during her presentation and posted the following:

image

At just about the same time, on the right coast, danah boyd of Microsoft was delivering a keynote at the Web 2.0 Expo in New York City that didn’t go as well. Her experience and the subsequent conversation around it represent the latest installment in the evolving relationship between audience and presenter. It also contains comparable lessons for the successful adoption of social media within the enterprise.

If you ever expect to stand and deliver in front of a group, these are issues you need to think about beforehand. That can be as adrenaline inducing as boyd’s keynote or as seemingly innocuous as running a status meeting while the team focuses on their laptops, Blackberrys, and iphones.

I’ve been gathering and organizing links to some of the more useful and informative material I’ve found on this topic. For starters, here are some key pointers specific to boyd’s experience, including her own reflections and assessment:

danah body isn’t the only one dealing with this new relationship between audience and speaker. Here are some other accounts and overviews of other less than successful encounters, both recent and not-so-recent:

Fortunately, we’re also starting to see some good advice emerging on how to cope:

These examples are highly visible. They also take place in settings where you have the additional problems of a degree of anonymity that seems to encourage a level of boorishness more reminiscent of middle school than anything else. At the same time, they are also leading indicators of a default working environment that will be more public and transparent than we are accustomed to or comfortable with. Paying attention here and thinking through what lessons are available and how they translate into other settings is time well spent. Some of the questions on my mind include:

  • Where and when can you influence the tenor of the backchannel? As a presenter? As a conference organizer? As a member of the audience?
  • What can you do before the fact to set useful expectations or standards of interaction?
  • What can you do in the moment?
  • What can you do after the fact?
  • What’s likely to differ in more private venues? What will differ for the better? For worse?
Reblog this post [with Zemanta]

Asking more relevant questions about focus and multitasking

I’ve been uncomfortable with the ongoing discussions about the promise or threat of multitasking without being quite able to articulate why. Stowe Boyd finally helped my crystallize my concerns with a nice dissection of the most recent wave of debate on the topic. Let me extract two paragraphs from his excellent analysis:

So, the war on flow continues. I liked the study from a few years back that equated multitasking with smoking dope in its effects, and perhaps the most masterful attack was leveled by Christine Rosen in her Myth Of Multitasking (see Christine Rosen Joins The War On Flow), or Nick Carr, who said the Web is making us stupid. They are all looking backward, and using old tools to measure, ineffectively, what is emerging.

….

If you judge a juggler by how many times the balls hit the floor and contrast that with someone throwing and catching one ball at a time, the juggler will lose. But the juggler is doing something else. You could argue that doing it that way makes no sense, that throwing one ball at a time is more efficient, leads to less sleepless nights, and doesn’t confuse the mind. But it isn’t juggling.

The War On Flow, 2009: Why Studies About Multitasking Are Missing The Point
Stowe Boyd
Sun, 30 Aug 2009 12:33:48 GMT

The current discussion around whether multitasking is good or bad flounders on a host of unarticulated and unexamined assumptions. The question is not about whether multitasking is a better way to do old forms of work; it is about what skills and techniques do we need to develop to deal with the forms of work that are now emerging. There is a complex interaction between an evolving environment and developing technologies. Much of the discussion to date is comparable to trying to understand the automobile as a horseless carriage.

I am reminded of an old observation by author Larry Niven; "good science fiction writers predict cars – great science fiction writers predict traffic jams." One of the useful things to be done is to spend a more time watching the juggling (to borrow Stowe Boyd’s image) and appreciating it on its own terms instead of criticizing it for what it isn’t.

Hacking complex knowledge problems: Van Halen and Brown M&Ms

I had never actually heard the story about Van Halen and brown M&M’s before I came across this Boing Boing entry. Of course, Boing  Boing is always a good for fun stories. Here’s one that also has a useful point about dealing with complex knowledge problems between organizations.

 

nomms.jpg
Spotted via Andrew Baron’s tweetstream, this fascinating — no, really! — snopes article on why Van Halen had that line in their concert rider about ABSOLUTELY NO BROWN M&Ms EVER.

Snopes.com: Van Halen Brown M&Ms. The actual 1982 rider was first published online at smokinggun.com in 2008.

 

Van Halen had good reason to ban brown M&Ms in their concert rider.
Xeni Jardin
Wed, 05 Aug 2009 23:49:58 GMT

Take the time to check out the Snopes article (Snopes.com: Van Halen Brown M&Ms). It presents a design problem of how to ensure that an organization you’re contracting with is exercising the appropriate attention to detail. It reminds me of a similar design hack/lesson I learned first back in the 7th grade. A version of that lesson is, of course, available courtesy of a moment’s effort with a search engine(Directions Test).

What makes this example important is that more and more of our work gets done through other organizations. That increases the problems of incomplete contracts where the tasks in question are sufficiently complex and the environment indeterminate enough that it is difficult, in not impossible. to specify all the relevant conditions in advance. "Brown M&Ms" provides an excellent reminder that the point of the contract is to ensure a successful outcome for all parties.