|
|
| These aren't |
high-payoff applications... but you can use these tools to help build a team..
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
 | Some people are too shy to participate in a public forum, or too sensitive to potential criticism. |
| Others expect others to provide data for them, and they are disappointed when they're expected to post, too. |
| Still others don't understand the appropriate customs of the place, and wreak havoc through poorly composed messages with little thought to the utility of the information to others. |
These are the problems that need to be addressed to make a DDb successful. And, if you don't, you'll find the familiar pattern of participation:
There are few good models to follow from earlier technologies.
Telephone conferences and face-to-face meetings occur synchro- nously
(that is, at the same time), while on-line conferencing is asyn- chronous.
The exchange of e-mail messages is more like an exchange of memoranda on amphetamines, and
there's no easy parallel to the parallel "threads" of discussion going on over
the same few days or weeks in a DDb.
So, you can't count on people to bring some prior experience to a DDb that you can use as a metaphor for the new technology. The pioneers have had to make up their rules, compose their cultures, as they've felt their way along.
With great anticipation, you roll out a DDb to a population of 100 potential users, 20 of whom actually become active. So, immediately, your expectations (and the expectations of the 20) aren't met. Remedy: Take action to get more people involved. F. ex.: We frequently read the DDb a couple of times a day, just to see if there's something there that might interest someone we haven't seen frequenting the discussion; we'll e-mail them a pointer, suggesting that it's in their self-interest to check it out...and most do.
Next, each participant brings to the discussion a different
set of expectations
which
aren't articulatedand when
those expectations aren't met, they fall away. Remedy: Make sure
expectations get articulated. F. ex.: We always foster some early
discussion about the rules for this nascent community; it's useful to have some sanction
(or even technology, like separate categories) so people can express their concerns and
expectations for this DDb.
One poster may expect to be lauded for insights, but stops posting because there's a persistent lack of response. Others may expect guidance from higher management, but interest wanes when they discover it's an audience of peers. Still others may expect some camaraderie to evolve, and become disappointed with terse postings. Eventually, most fall away, leaving only a few stalwarts. Remedy: Adapt your responses to the participants, and adapt with them over time. F. ex.: We notice those who seem to be playful, and often give them playful feedback; we notice others for whom the whole thing is very serious, and we avoid teasing or joking with them.
Finally, unless all the participants already know each other, there will be serious issues with establishing and maintaining mutual trust. If a group of people already have that trust, and another subgroup is new to them, there's always risk it can evolve into the "in" and the "out" groups, cleaving the group into two. Remedy: Take steps to foster dialog that can foster trust. F. ex.: We always foster some "off-topic" discussion, debate or argument, because it tends to expose people to one another; that exposure may lead to destruction (unless carefully moderated) but more often leads to budding trust among the participants.
See "The Function of the Agora." It explains why people need to have permission to go "off-topic" or engage in "idle gossip."
The key point in all this should be evident by how: Somebody has to take some specific actions and get engaged in the process of fostering a sense of community. If these steps aren't taken, the cohesiveness simply will never materialize.
The only people who will ever participate in the DDb are those who are invited: If they don't know the discussion exists, how can they join? And, if you have to remind people; if they don't hear about it, they'll assume the DDb died for lack of interest. So, you have to invite people.
That begs the question: Who should be involved? And that, in turn, begs the question: What result do you want? If you're clear about the outcome of the discussion process, then you can be clear about who should participate. And, when you're clear about that, you know whom to invite.
If the purpose of the DDB is to foster community among a dynamic or growing population of users, you have to make frequent efforts to publicize the availability. Some people will forget, others (for example, new employees) will have never heard about it.
Every first-time participant (even if they've had experience in other discussions in the past) is a "newbie." They might not know the peculiar customs or specific acronyms or cultural rules of this forum. They deserved to be greeted, and offered a "place at the table."
In many DDb where people generally don't know one another, it's useful to greet people, honor their posts, give them a quick "thanks" or "welcome" message. It's amazing how warm people feel when they check back and see that they've been acknowledged.
Of course, the newcomer might immediately and inadvertently violate some local cultural norms, sort of like walking through the flower bed on the way to the front door. In this case, it's usually best to take the process of new party education off-line, into e-mail. Chastising people in public for not reading the published guidelines, or for doing something they shouldn't almost guarantees they'll never participate again.
You'll find, after a while, some subset of all the participants that are generally recognized as the "core" participants. These are the people the rest of the participants rely on: If their participation declines, the DDb is probably approaching death.
The "core" participants can be identified by seeing how many other people ("core" or not) refer to them by name. The named people are the "core" group. Make sure you remain sensitive to their concerns, for they implicitly speak for the entire population of participants.
There are some people who just don't ever want to post any useful information; they read, but they don't ever contribute. They're called "lurkers." It not a pejorative, just a description.
Your lurkers are important, because they will often help draw other people into the discussion by mentioning the opportunity or referring to information they've learned from the DDb. The problem is, of course, that you'll never know who they are, unless your technology reports who reads postings.
Sometimes, lurkers can be transformed into "newbies." We often use e-mail messages to alert them to places where their unique expertise could be of benefit to someone else. That's often enough encouragement to get them out of "lurker" status...although you may have to keep working on them to keep them active.
Sometimes, you have to take steps to reach past people's
logical minds and "grab them by the [sensitive part of the anatomy]."
When people have strong beliefs, it usually easy to evoke their passions. By evoking
their passions, we elicit their participation. Those exposed passions and positions
are the basis of intimacy, and it is on that intimacy that the trust among principalsso essential to the formation
of communityis founded.
Community is composed of people who trust one another. That is why so few collections of individuals thrust together become effective teams. As Jay points out in "Corporation Man," a team is built on trust, and trust is usually formed under pressure like a major deadline, or a shared life-threatening experience. Since we can't create these kinds of pressure in a discussion database, we have to rely on the other way to build trust: Intimacy. By getting people to open up, to expose their vulnerabilities, to be authentic, others can assess the contexts in which they're willing to extend trust to this individual.
To forge a true community, people have to expose their passions, and that generally means there're going to be heated, passionate dialog that can sometimes border on ad hominem attacks. Ideally, it should never descend to the "flame war" level. But, your ability to spark this passionate exchange, and then to manage it through the rough spots can often be the difference between community formation and mere on-going communication. The goal is to show individual strengths and weaknesses, which they can usually hide through benign postings. However, a passionate debate or discussion reveals who are good mediators, which can be counted on for appropriate humor, and, perhaps, the identities of people who just "don't get it." The latter will usually migrate away, leaving a core group of people with some modicum of trust...and, often, even affection for one another.
You should never seek to create the initial spark; it will naturally arise out of the very nature of human communications. However, when that spark occurs, like the first lightening flash that sets off the forest-purging fire, you need to stand by and resist the impulse to quench it. Let that spark grow, through a half-dozen or more exchanges. After that point, I might even participate myself, to keep the conflagration going.
At the same time, you certainly don't want things to get so out of control that people stop participating. You need to both carefully fan the flames to encourage people to expose and explore their beliefs, and damp the flames to keep them from raging out of control. You're always safer erring on the side of quenching the discussion...but when you do, you're only delaying the inevitable. If the early controversial topics aren't fully explored by the active participants in that thread, you may discourage them from arising until the very survival of the DDb is at stake. What you may notice, over several months, is that contro- versies grow in magnitude and extent as participants feel progressively more comfortable with each other.
During the actual heat of the dialog, be sure to notice which individuals may seem offended by the process...some people are conflict-averse and will flee. A quiet e-mail will give them the assurance they need to stick around until the heat turns to light. New participants, who have little history with the participants in the contro- versial dialog, may be especially concerned that this apparent hostility is indicative of the on-going mood of the emerging community. Again, a separate e-mail, or general posting in the DDb, may help assuage their fears.
Your role is also important when some participant(s) appear to be about to "go over the top." An e-mail...or, in extreme circumstances, a telephoen call...is helpful to support the participant work through the emotions that may come up. We've all learned to "count to ten" to let anger cool; we often need to teach our nascent community that writing the rebuttal, and letting it simmer overnight before sending is the logical equivalent in a DDb.
Here's an experiment for you to try. The next time you're having a casual conversation with someone you trust (I recommend a friend, not a family member), suspend all your feedback. You might not be aware of it, but even your subvocal "uh-huh" and "mmm" sounds, or your occasional head nods, and changes in facial expression are all parts of the feedback loop. It's the way to tell people the receiver is still in operation, the communication channel is still open.
Generally, if we don't get those every ten seconds or so, most speakers will begin to wonder whether they're being heard. If you're persistent in this non-response, I guarantee they'll eventually stop and check to see if you're still listening.
Until they're aware of what's going on and learn how to overcome it, it's tough for most people to communicate without some feedback. I think most of the fear of speaking before groups is that the customary feedback cues aren't there. Socially, we're taught not to subvocalize when we're part of an audience. This leaves a speaker bereft of the customary feedback. Without feedback most speakers get uneasy, and more unnerved as time goes on. It's called "mike fright."
Communication is a bi-directional art and DDbs are usually one- way mechanisms. We can try to facilitate a more natural two-way flow by:
| Providing more feedback. |
| Teaching people to accept delayed feedback or none at all. |
| Accepting postings only from people who are too insensitive to care. |
What can we do to provide feedback? We can take responsibility by posting a response, any response, so postings don't go unacknow- ledged.
I see a lot of "Me too" responses, expressing sympathy with the original poster. Inevitably somebody objects to all those "me too" posts. But those are part of the social lubricant. They encourage people to come back and post again. They're the DDb equivalent of "uh-huhs" or "hmmms."
We can also try to speed up the rhythm of the posting/response pattern. If we notice a post from Helen that Jose could answer but he doesn't, a friendly e-mail on the side might be what's needed. It might goad Jose into overcoming his resistance and give Helen the feedback she needs to encourage her to post again.
This doesn't always require a formal moderator, just a willingness to help others learn the "rules of the road" through experience. Part of the role of an intentional moderator is to encourage others to take on that role themselves, naturally. That's best done by setting a good example, then leaving a vacuum for them to fill. I'll often take on the responsibility of being responsive for 100 instances, or so...then I'll wait the next time, leaving time for somebody else to step and do what I would do in that case (I'll actually suspend posting at all, to leave the impression that I'm otherwise occupied).
Finally, we need to educate DDb users about this new medium, and help them realize that the old customs they learned by osmosis from the culture-at-large may no longer be appropriate.
By helping users understand how their expectations may need to change, we can enrich their range of possible behaviors, making them willing collaborators in the bargain.
We've overcome the simple barriers. How do we move up to the next level? Provide people with an easy way to participate. I find that in some of my better DDbs, I've constantly added forms for certain common data formats. Some people find it easier to fill in a form than a blank screen. Think of it as electronic writer's block.
For example: We could just use a common blank form in the DDb for PC users to solicit help and share answers from their own experi- ence, but I think there's a better approach. Asking for help isn't widely encouraged in our society, so a form could help some people overcome their reluctance.
Instead of a blank form, mark off fields for "Description of problem," "Software in use," "Operating system," and so on. This will encourage a nervous poster to think through what needs to be said to be informative, and increases the likelihood of getting a response. This is a feedback loop that works. Because of the form, the posting is made. Because a posting is made, it gets a response, and because of the response, new users are more willing to try again in the future.
Another approach is to make sure that something people want is tied to asking for it in the DDb. If your office has a central source of files, or office supplies, or a mail room, make sure that the retrieval of a file, or the delivery of supplies, or a change of mail address can only be achieved by posting to a forum, and make sure there's some kind of timely, relevant response.
By the way, don't carry this to extremes. People want their paychecks and promotions, but those rewards are too large to be attached to something as small as a Discussion Database posting. We know of one company that offered "frequent flyer" miles for posts, and got a lot of posts...until the give-away stopped. Then posts diminished to a trickle, and the posts that had been made were seen to be of low value.
If you're going to reward people, make sure that it's a positive reward (that is, getting what they want), not a punishment in disguise (if you don't post, you won't get what you want). Make sure the reward is commensurate with the activity, otherwise people may become suspicious.
When you begin to forge a cabal into a collaboration, people will come to it with differing expectations. Make sure you lead them into some discussion of those expectations. People don't mind changing their expectations, but they resent having their unstated expectations violated.
To be sure, you won't get everyone to express their heart's desire ("Will an egomaniac publicly acknowledge her motivations? I don't think so!")
However, you can get people with differing expectations to thresh out their differences and agree on what's acceptable, and what's not.
This discussion may become one of the liveliest parts of the whole forum. Of course, it's a great training ground for getting people used to posting and responding.
Finally, we have to raise the issue of "Network Etiquette" (also known as netiquette). One of the most effective ways we have to make sure that lurkers and read-only users never jump into the fray is to allow one person to attack another, directly or subtly, in the DDbs.
You have to maintain some control over the impulse of juveniles (and juveniles-at-heart) to "flame" someone they disagree with. This not only inflicts damage on the addressed party, but also upon the dozens of people who read the remark and say to themselves, "Oh, no! I'm not venturing out there! It's not safe!"
If the boundaries are not clearly established, differing expectations will ensure that somebody feels the boundaries have been crossed. That's why it's important to have some published guidelines for behavior.
People need to know what's expected of them, and how they can expect others to behave. That creates a safe space for people to come and experiment (within the boundaries).
Ideally, they'll learn how to transfer those behaviors into other DDbs in the future.
|
|
