This website covers topics on knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

The user is the group, not the individual

Someone pointed to a 2003 article from Clay Shirky called A Group Is Its Own Worst Enemy that comes from a keynote talk he gave. He had a funny statement right at the start that grabbed me:

Prior to the Internet, the last technology that had any real effect on the way people sat down and talked together was the table.

And I kept reading because the topic of group dynamics, social software and community management are parts of what I am interested in. And he brings a lot of good research and experience to the topic. He also peppers the talk with quotes like the one above.

The article (the talk?) has three sections. In the first he tells us why the group is its own worst enemy: while there is a basic nature of people that wants to form groups, they also have a familiar nature within groups to want to devolve the group away from its primary aim (sex, group enemies, and religion-of-the-group). Without some kind of structure to defend (Shirky's word) the group from this devolution, the group will likely die.  I couldn't help but think of Dave Snowden's birthday party story where there has to be some means of bounding the group without placing too much structure around it. The group needs some way of preventing the natural human tendencies from destroying the group itself.

The second topic is that technology is allowing for interesting things. After ten years, I think most of what he was seeing has only continued. I didn't even know the term social software had been around in 2003. (Of course, a quick look at my blog, and I see that I have been using the term since 2003.) The one key idea here that is so easy to forget is that the technology that supports the group and the social behavior within the group are impossible to separate. The group uses the technology to do what it wants, AND the technology limits/expands what the group can do. They work hand in hand.  In my experience, I have seen groups attempt to move from one supporting platform to another and go through all sorts of pain because the new technology doesn't allow them to do the things in familiar ways.

In the final segment of the article, Shirky lists some key elements that should be considered in designing (selecting?) social software. 

  1. The social software has to support "handles," so that people know who is talking and so that they can remember who did what useful (or not useful) things in the past. He's not talking about badges or full-blown identity systems, just simple, persistent handles.
  2. Then you need a way to be understood as a "member in good standing" so that it can be somewhat clear who is new and who has been around a while.  This allows for the creation of core groups who might be interested in helping to set the direction and norms of the group.
  3. He also suggests that there need to be barriers to participation - at least at some levels of the group. Not everyone should be part of the core group, for example. What are the criteria for making it that far? I've seen many a group fade away when there is no clear guiding membership, and people just join or not on personal whims. But if no one is there to perform the welcoming and orientation and crowd control functions, how long am I going to stick around?
  4. Finally, there has to be a mechanism to protect users from scale. As the group gets big, how will the group handle this? The software needs to support what you want to do, and the group needs to decide what it wants to do. 

A key aspect of this is that the software needs to be designed for the group, not the individual. Sure people have to be able to use it, but the whole point of social software is that it supports the interactions of the group. Shirky doesn't say it directly, but consideration of these four things (and a host of others) has to be part of an ongoing process for groups. 

I wonder: I bet a lot of this discussion might apply to any concept that supports the function of a group. I've been using Kanban as David Anderson describes it, and I have seen conversations that look a lot like the technology-sociology discussions. Any other methodology probably fits in here too. The ideas are brought to a group and, if adopted, the group is changed by the ideas AND the ideas need to be flexible enough to withstand bashing by the group.

It's interesting to find this article and see that it is still relevant, particularly as the discipline of community management grows and solidifies itself.

Collaboration and its opposite

Flash on your iPad (and other iOS devices)