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.)
6 thoughts on “Going with the flow”
Obviously I am a big fan of blogging. But I see mandatory blogging as just another out-of-the-flow KM system.
I would rather have a project blog or wiki where the project team communicates. Yes, that could be mandatory. It would replace email. “Keep me up to date on the project blog! and don’t send me emails except for confidential information!”
I think most people are willing to share. They just do not want to go out of their way to do it. Replacing email with platform communication tools can go a long way towards to making it easier to share.
I agree, Doug.
I ran out of steam somewhat at the end of this post. What I meant to say in conclusion is that blogging is a valuable tool to allow who already have an interest in knowledge sharing to get better at it, and knowledge sharing can be a useful objective for those who already have an interest in blogging.
The key thing is that good quality blogging and good quality knowledge sharing are both directed at some focused purpose (ideally one with real value). Unfocused blogging or knowledge sharing is inevitably low quality. Mandatory blogging or knowledge sharing is likely to be unfocused, especially when it is driven by blunt metrics (Dave Snowden has something to say about this too: http://www.cognitive-edge.com/blogs/dave/2008/06/if_you_try_and_set_targets_for.php) or meaningless incentives.
You’re right about the risk of forced blogging resulting in unfocused, poor quality content. This definitely is not what I had in mind when I initially endorsed the discipline of regular blogging at work. Undoubtedly, people who blog because they want to blog will produce better content because they care. This is compelling support for a purely voluntary system.
On the other hand, how long must we wait to achieve reasonably high levels of good quality knowledge sharing? The promise of these social media tools was that they would facilitate and expedite this sharing. However, we could be waiting a long time for this if adoption is allowed to be purely voluntary.
The social media party is probably like any other party: some people come because they were invited, some gatecrash, and others come only because their friends dragged them there. Perhaps we should permit all three methods of participation for social media as well.
Great post. The Xerox example is a great illustration of how in-the-flow solutions can be effective. I’m finding that solutions like that one, where knowledge is captured in-the-flow, are challenging traditional conceptions of knowledge management. In theory, knowledge management is supposed to be all about synthesizing and contextualizing. Anything less is supposed to be mere “information”, not to be confused with knowledge. But what I’m seeing in in-the-flow wikis is a more informal, less structured exchange of observations. It’s more like email threads, meeting minutes, and whiteboard transcriptions–the kind of content that people are creating anyway, but that doesn’t usually end up in a place that’s very useful. That’s where I see the big opportunity for knowledge capture.
[…] Going with the flow from Mark Gould […]
[…] we are relieved of the obligation to carry on supporting past KM endeavours — they become part of the flow. As a result, we are free to move on to new projects. Isn’t that a better place to […]
Comments are closed.