Knowledge work Archives - Page 21 of 35

Culture, Process, and Practice – Effective leverage for Enterprise 2.0

The discussion about organizational culture in knowledge management and Enterprise 2.0 efforts is evolving in useful and pragmatic ways. The earliest discussions ignored culture entirely and implicitly assumed that technology would magically shape the organization as needed. The next round of discussion identified sharing as a desirable global cultural characteristic. If you were in a sharing culture, all was good. Time would ultimately reward your virtue. Those with equal need but less virtue whispered of incentives and WIIFM (what’s in it for me?). Crass and vulgar, but perhaps sufficient for most organizations.

In general these open ended discussions of culture are unsatisfying. They make gross assumptions on the basis of little data. Dave Snowden’s principles of knowledge management (see Rendering Knowledge) provide important pointers to a better answer with his emphasis on the behavior of individual knowledge workers.

Enterprise 2.0 as the extension of ERP

Michael Idinopulos of SocialText noted a shift in the debate at the recent Enterprise 2.0 conference in Boston. In a post titled The End of the Culture 2.0 Crusade?, he observed that:

Last week, the Enterprise 2.0 world turned a corner. Nobody pounded the table for cultural change. Nobody talked about incentives or change management. Nobody talked about transparency or modeling collaborative behavior.

Instead, people talked about process.

…

This is the most pragmatic shift in focus since the inception of Enterprise 2.0. It will have huge effects on the pervasiveness of social software in the enterprise, because it shows a clear path to the business value companies can realize from their implementations.

I ve been arguing for some time that social software achieves widespread adoption only when workers use it in the flow of work. Asking your colleagues to step outside their daily processes and tools to share what they know or network with others won t get you very far. (Trust me, I ve tried.) Bringing your colleagues collaborative tools and practices that make their daily processes better, faster, cheaper, and more interesting does work. It s all about process. Improve the process, you win. Don t improve the process, you lose.

This point of view squares with Ross Mayfield’s that broken business processes contribute to email overload and that

(Employees) spend most of their time handling exceptions to business processes. That s what they are doing in their inbox for four hours a day. E-mail has become the great exception handler.

While this is a very attractive position, it is incomplete in an important, and potentially dangerous, way. If you focus Enterprise 2.0 efforts solely on business process you may get scale, you will likely avoid the issue of culture, BUT you risk missing an opportunity for great leverage.

Leaving Process for Practice: Leveraging Knowledge Work as Craft

Focusing solely on Enterprise 2.0 efforts as an extension of existing business processes treats Enterprise 2.0 as a residual, clean-up, effort. It presumes that the goal worth pursuing is the efficient execution of well-defined processes. It reduces Enterprise 2.0 to an afterthought to ERP.

There is an assumption in this process-centric view that all relevant behavior can be reduced to business rules in the automated system. Exceptions are viewed as system failures or design failures. Moreover, failures in the system are attributed to resistance on the part of system users and operators. Instead of interpreting failures as resistance, what if we start by treating them simply as data?

If you start with process, your goal is uniformity at scale. Ideally, every situation should be treated in exactly the same way. This is eminently logical if you are calculating payroll withholding taxes. It is clever when you extend that logic to treating airline seats as a perishable commodity whose price might vary depending on the day of the week. Can you push in this direction forever?

Are there situations where uniformity and scale are not the appropriate criteria? Of course. The realm of art and craft is all about uniqueness and the value of limited scale. What happens if we opt to start from the art and craft end of the spectrum?

One choice is to accept the dichotomy. There is a class of problems suited to process thinking and a class of problems suited to art and craft. Another choice is to continue to force fit problems into a process view of the world. This has been a successful approach. Consider the number of problems that have been transformed into algorithmic problems well-suited to automation — inventory control and demand forecasting to name two.

A third choice is to ask how to improve art and craft without presupposing that uniform process is the goal. This was the approach started by Vannevar Bush, Doug Engelbart, and their intellectual heirs. This approach spawned much of the technology environment that we operate within today. Oddly, we’ve largely ignored their motives in creating this technology; to support more effective ways of wrestling with intellectual problems.

Engelbart, and those working on his agenda, started building new technology tools because our previous tools and methods were inadequate for the problems we had to solve. They built tools to support new kinds of problem-framing and problem-solving practices. We’ve adopted the tools without considering the practices and behaviors they were designed to enable.

Culture as the sum of shared behaviors

Those who lay the blame for failed efforts to introduce knowledge management or Enterprise 2.0 tools on organizational culture are picking up on this behavioral issue. They are doing so, however, at the wrong level of detail. Organizational culture is a convenient shorthand for the practices and behaviors that constitute "they way we work around here." Changing culture is hard because it’s an abstraction; there’s nothing to push against to get it to move.

While changing behaviors can also be hard, as anyone who’s tried to adopt a new habit can attest, it is possible. Change the right behaviors and eventually you have a new culture. The opportunity in Enterprise 2.0 technologies lies in the new behaviors that become possible. The challenge is that these technologies do not dictate a single set of obvious behaviors. In fact, it is possible to adopt the technologies and make no behavioral changes at all.

Focusing on behavior is still a challenge. Technology opens up possibilities while setting few constraints. The activities we are interested in here are equally unconstrained by business process; we’ve defined them as the behaviors that don’t fit within the mantle of process. We need to go back to observing how work is currently being done, ask what flows smoothly, see where things get stuck, and design alternate ways to make use of the new range of available tools. We’ll visit those questions tomorrow.

LATE BREAKING LINK: As I was about to publish this post, John Tropea of Library Clips posted a lengthy piece on Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management. I’ve only just skimmed it, but it’s squarely part of this evolving conversation.

Observable work – more on knowledge work visibility (#owork)

My post on the visibility of knowledge work last week generated some some excellent comments and excellent blog posts around the web. For my own benefit I wanted to gather up what I’ve come across so far and put it in one place.

Recap

Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.

Balancing Uniqueness and Uniformity in Knowledge Work

Image via Wikipedia

The essence of good knowledge work is uniqueness not uniformity. The ideal knowledge work product is exactly what your client asked for and could only have been created by you. The challenge is that we have been conditioned by the industrial economy to value uniformity and see uniqueness as undesirable variation instead of the essential quality it has become.

To deliver better knowledge work products, we need to unlearn habits and develop new perspectives. Our inappropriate habits stem from assumptions about industrial work. With industrial thinking, once you ve created a new product the goal becomes how to replicate it predictably. You specify the characteristics of the output precisely, lock down the process, or, ideally, do both. That works if you need to manufacture cars or calculate every employee s pay stub correctly. It doesn t when the goal is to create the new product. The primary challenge here is to shift focus away from the issue of replication and toward creation. The question becomes how do we manage to create this? instead of how do we produce the same thing all over again?

Creating good knowledge work has a challenge beyond simple uniqueness. It is the same challenge faced by artists who once worked at the pleasure of their patrons. You want to create your art, but ultimately, you have to please your patron as well. You need to educate your patron about the nature and qualities of the output you have been commissioned to create and you need to learn from your patron what limits and constraints they face in putting that output to work. The unique insights where value resides may need to be packaged in a document or presentation package comfortable to the organization. Or you may need to place those insights in a more familiar context that lets them be seen by the organization.

Working out a feasible balance between the unique and the familiar is more complex and more subtle than either simply delivering what the customer asks for or creating an off-the-shelf product. It is not precisely a negotiation, nor is it generally a full-bore collaboration.

A basic strategy for discovering an appropriate knowledge work output has three parts.

1. Defining a deliverable.

If you ve grown up in a professional services environment, what s the deliverable? gets tattooed on the inside of your eyeballs. It s essential in professional services because it creates something tangible for which you can get paid. In any form of knowledge work the notion is valuable in that it makes something tangible out of what can otherwise be an amorphous process. A deliverable might be a spreadsheet or a presentation, an executive workshop, or a first release of a new information system; regardless, it needs to be something that both you and your client can point to and decide that it is done.

2. Understanding how the deliverable will be used.

The most important thing to understand about a deliverable is what your customer intends to do with it. Will it be used to identify a decision to be made? Justify that decision to someone higher in the food chain? Generate or eliminate alternatives?

Each of these possible uses influences what is important about the deliverable and what is secondary or irrelevant. For example, if your customer wants to understand whether a particular technology does or doesn t work in their current environment, a lengthy analysis of the current state of the software market isn t likely to be relevant.

That same analysis may be the essential requirement of someone evaluating whether to introduce their technology to the market. Whether you invest in preparing the analysis depends first and foremost on whether someone needs it.

3. Determining how the deliverable can be created.

Understanding how a deliverable will be used sets limits and focuses your attention on how it should be created. An executive who needs an answer about whether to invest in a new distribution channel may prefer that answer delivered on a one-page memo. However, if your customer is that executive s support staff, you may need to create substantial supporting analyses. Even in that case, whether you deliver that supporting analysis as a bound report, an electronic document, or organized as a series of frequently asked questions will affect both its value to the customer and its cost (to you) to create.

This three-step process should be followed for every piece of knowledge work we create. The urge to standardize outputs or processes is a holdover from industrial practices that is inappropriate in a knowledge work environment. Applied here, it risks short-circuiting the essential interaction. We must define and deliver the unique output that integrates client needs with your ability to create an appropriately unique solution.

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.