Going with the flow

I had a number of discussions with people last week that brought to mind Michael Idinopulos’s description of the relationship between wikis and work.

Wikis can be used for many different activities, which fall into two broad categories:

• In-the-Flow wikis enable people do their day-to-day work in the wiki itself. These wikis are typically replacing email, virtual team rooms, and project management systems.

• Above-the-Flow wikis invite users to step out of the daily flow of work and reflect, codify, and share something about what they do. These wikis are typically replacing knowledge management systems (or creating knowledge management systems for the first time).

When wiki champions complain that it’s hard to get people to use wikis, they’re usually thinking of above-the-flow wikis. Modeled on  Wikipedia, these wikis typically aspire to capture knowledge and insights that people collect in the course of their work. That’s a hard thing to get people to do.

Michael’s assertion is true for know-how systems generally. Too many appear to have been built on the Field of Dreams principle (“if you build it, they will come”). Even if that isn’t true, my impression (derived from reading articles and listening to conference presentations) is that many firms spend inordinate amounts of time devising elaborate systems of incentives and cajoling their people to contribute to the know-how database. Why do they have to do this? Because the capture and collection of knowledge is above the flow.

More importantly, the availability of rewards for know-how is not likely to make participation in the knowledge process part of the flow. In fact, I suspect that they make it easier for people to opt out of that process (or to become free-riders on the labours of those who support it). The challenge is not to get people to break out of their flow so that they engage with KM systems, but to change the flow so that those systems become part of the flow — a natural part of the daily routine.

That is easier said than done, of course. There is an upside, though. In essence, this is what we need  to do in order to create a knowledge culture. Expressed in those terms the problem becomes much more tangible and therefore potentially more manageable. If someone is asked to create or change the knowledge culture, the task looks (and probably is) insuperable. If it is defined as moving certain activities into mainstream processes, the task can be broken into smaller pieces that are less daunting.

The classic example of knowledge systems that fit in the flow must be the case of the Xerox photocopy engineers. As part of work developing an expert system for photocopier fault diagnosis, Xerox discovered that their engineers were less than impressed with the system because the hardest problems they encountered were not already documented and therefore outside the scope of the expert system.

We decided to spend more time observing what technicians actually did day to day. We started with US technicians, accompanying them on their service calls. Most of the time, they would look at the machine, talk to the customer, and know exactly what to do to put it in good working order. Occasionally, they ran into a problem that they hadn’t seen before and for which there was no documented answer. They would try to solve these problems based on their knowledge of the machine. This often worked, but sometimes they were stuck. They might call on a buddy for ideas, using their two-way radios, or turn to the experts—former technicians now serving as field engineers—who were part of the escalation process. When they solved unusual problems, they would often tell stories about these successes at meetings with their coworkers. The stories, now part of the community, could then be used at similar gatherings and further modified or elaborated.

The story-telling referred to actually took place informally as part of the daily routine. As these technicians travelled around their areas, they would meet their colleagues in coffee-shops or rest-stops. Their conversations — part of the daily flow — would probably cover the usual range of topics, as well as the tips they had learnt or developed to deal with previously unforeseen copier faults. In order to make the most of these interactions, the system that Xerox developed (named Eureka) had to expand on them, and keep the knowledge-sharing process in the flow. As their director of knowledge management for worldwide customer services, Tom Ruddy, put it:

When people hear about Eureka, they always want to see the software. But it’s really the environment that we are creating. We realized early on that technology wasn’t the solution-that if we didn’t work on the behavioral side of the equation, it wouldn’t be successful. We concentrated on understanding what would make people want to share solutions and take their personal time to enter stuff into the system.

Coincidentally, one of the hottest blog posts of the weekend touches on a similar cultural problem: how do you get people to share knowledge using blogs? Tim Leberecht’s solution: mandatory employee blogs. As Doug Cornelius points out, there is a strong tide of opinion against this choice. In part, this tide is driven by the desire to reflect people’s normal work patterns and habits in knowledge sharing and collaboration. In part, I think there is also a recognition that blogging is not yet mature enough to become a part of those work patterns and habits. (In a separate post, Doug refers to some work done by Forrester which suggests that only 13% of consumers would participate in social media to the extent of creating content (which covers blogging as well as uploading video to Youtube.)

Pollyanna-like, I have a tendency to see opportunities in problems. I don’t want to make blogging mandatory, but I am sure that there are people who would blog, but don’t share knowledge, just as there are people who would like an easier way to share knowledge as part of their work. I want to bring those people together (and then throw a few non-sharing non-bloggers into the mix) to see what kind of culture we can create. At the same time, I want to find as many ways as possible of bringing knowledge into the work-flow. (It looks like Mary Abraham and I have similar views.)