RDVP Seminar: Eugene Eric Kim (11/10/2004)

Eugene Eric Kim of Blue Oxen Associates spoke about collaboration. Blue Oxen is a think tank devoted to the study of collaboration and the distribution of best practices by sharing them through writing and meetings. He provided a formal definition of collaboration: "Two or more people share knowledge in pursuit of a shared, bounded goal," and also some instances of collaboration that resulted in differing degrees of success. He argued that collaboration requires a shared language and understanding (not 100% agreement on all definitions and terms, but at least an understanding of what the other parties mean when they use them). Then he reached the meat of the talk: the identification of collaboration patterns (like software design patterns or architect Christopher Alexander's patterns of successful buildings). Since people do a lot of collaboration, most are familiar with at least some of the patterns, but calling them out, making them explicit means that people are more likely to incorporate them into other collaborative settings increasing their effectiveness overall. Some sample patterns:

1. Shared display: Generally interactive with joint ownership
   
2. Neutral space: A place where all can put ideas and build on them without worrying about ownership. Open source is a good example.
   
3. Scratch your own itch: People will generally do things that help out their particular problem, and share the solution. Enables emergent grassroots cooperation.
   
4. Sacrificial Lamb: Designating one person from a team to handle all of the interruptions caused from the outside world kills that person's productivity, but makes the team as a whole more productive. This position generally rotates.
   
5. Spotlight on others: Share credit--go out of the way to acknowledge others
   
6. Mentorship: A way of integrating newbies into a community.
   
7. Developers talking to users: In organizations that build unusable products (or software) it's usually because the developers are insulated from the demands of the end user. In order to build successful products, they need to be integrated with users.

He also offered a couple of misconceptions about collaboration:

1. You can't force self-organization: Presented with examples of highly functioning self-organization (e.g., Dean's Meetup; Wikipedia) organizations or companies say "I want that," but they can't dictate it. They can create a space, perhaps even catalyze a move toward self-organization, but not force it.
   
2. Self-organization does not mean "No organization": Self-organized groups are not always flat, equitable organizations: they can have roles, structure, authority, etc.
   

He closed by looking at some tools, praising those that enabled the community to be engaged, self-policing, and yet have automated extraction of structure (often link structure) of the implicit knowledge added by people. He showed the example of http://www.technorati.com.