Blog | Wiki | Photos | Publications | Software | Talks | About

---

Wed, Jan 03, 2007

Group Information Hygiene    #

Last August, I wrote:    (LPS)

Poor PersonalInformationHygiene can often interfere with group trust, and trust is a prerequisite for good collaboration.    (LPU)

In an ideal world, everyone on your team would be masters of PersonalInformationHygiene, but in reality, that's rarely the case. Frankly, I'm not sure if it's always desirable. People have different kinds of intelligences, and it may be that certain kinds of intelligences are critical to a high-performance team, but are also orthogonal to good PersonalInformationHygiene.    (LPV)

Is it possible to have good GroupInformationHygiene if people on a team have poor PersonalInformationHygiene? Moreover, is it possible for the whole to be greater than the sum?    (LPW)

You all know what my answers are.    (LPX)

Part of the MGTaylor facilitation philosophy is to offload all potential distractions so that the participants may focus entirely on the task at hand. When you attend an MGTaylor DesignShop, there are several KnowledgeWorkers present, who are responsible for managing the distractions (among other things). They set up and reset the environment. They scribe your conversations. They manage the clock.    (LPY)

The philosophy is not exclusive to MGTaylor. The AspenInstitute follows a similar process. So do high-level politicians and actors in big-budget films, where their schedules are minutely managed so that they can focus entirely on acting... er, and policy-making. So do fancy restaurants. The food at Gary Danko in SanFrancisco is fantastic, but the service is unbelievable. There are literally six servers hiding in the shadows, anticipating your needs and making sure your table space is always pristine. Your glass is always full. Your napkin is always folded. If you're about to go to the bathroom, a server will pull out your chair and point you in the right direction. Remarkably, they pull this off without being overbearing and creepy.    (LPZ)

We can debate whether or not this is always a good thing. (I think the answer is no.) We can certainly agree that this level of service is not always practical. What's indisputable is that in a collaborative situation, these things need to be done by somebody. The question is by whom?    (LQ0)

The SacrificialLamb (stolen from JimCoplien and NeilHarrison's SacrificeOnePerson pattern) is both a pattern and an antipattern. Most of us are familiar with it as an antipattern, where someone "takes one for the team" and essentially does someone else's job because that other person isn't doing it. (We discussed this in great detail at last year's StLouisCollaboratory workshop.)    (LQ1)

When it's a result of broken trust, SacrificialLamb is short-term positive, because the job gets done, but it's long-term negative because it hurts your working chemistry and often overloads your most productive team members. When it's intentional and explicit, it's net positive, because it's not breaking any trust relationships. The essence of Jim and Neil's pattern is that instead of dividing the necessary but dreary tasks among multiple peers, you designate one person as the SacrificialLamb and that person handles all of those tasks, at least for one cycle. You increase the likelihood of the tasks getting done and getting done well, and you increase the productivity of your other team members. If done right, the whole will be greater than the sum. The KnowledgeWorkers in the MGTaylor process are essentially SacrificialLambs.    (LQ2)

The role of the SacrificialLamb is most often to maintain good GroupInformationHygiene. Project managers will find this role familiar. For example, when scheduling meetings, you send frequent reminders, both to compensate for others who are not good at maintaining their own calendars and to correct potential miscommunications. These tasks are laborious, but they're necessary for HighPerformanceCollaboration.    (LQ3)

Collaboration can be a difficult thing to measure, but measuring GroupInformationHygiene is relatively easy. I used metrics associated with GroupInformationHygiene extensively with a client last year as one indication of the state of collaboration within the community and the potential for improvement in the future. Poor GroupInformationHygiene is a natural obstacle to scale.    (LQ4)

/collaboration/patterns | Posted at 3:58pm

Tue, Nov 07, 2006

Quilting Patterns from Gee's Bend    #

Last month, I went to see "The Quilts of Gee's Bend" exhibition at the de Young Museum with my friend BettyToole. To be honest, I found most of the quilts disappointing. The story is very compelling, even if most of the quilts are mediocre. I wish the quality of the collection wasn't as hyped as it was, as it took away from the overall experience.    (LHY)

There were a few beautiful quilts, however. My favorite was a red quilt in an "H" pattern by NettieYoung, and the story accompanying it is a wonderful commentary on the danger of patterns.    (LHZ)

   (LI0)

Young said:    (LI1)

/collaboration/patterns | Posted at 11:54pm

Wed, Sep 27, 2006

Intellipedia Shovel    #

After the workshop yesterday, the CIA presented me with a shovel. That's right, a shovel.    (L8Y)

   (L8Z)

The shovel was inspired by MeatballWiki's BarnStar (which is also used by Wikipedia). It is an honor that people bestow on others for gardening Intellipedia, and it exists in both virtual and physical form. It's a wonderful example of SpotlightOnOthers.    (L90)

I am the first person outside of the intelligence community to have ever received one of these shovels, and I consider it a tremendous honor. Of course, I shamelessly and unapologetically cajoled them into giving me one, but as my momma used to say, you won't get it if you don't ask for it. I plan on showing it off every chance I get.    (L91)

/collaboration/patterns | Posted at 11:50pm

Mon, Mar 13, 2006

Leave A Trail: Stigmergy and Effective Large Group Collaboration    #

One of the challenges with large group collaboration is keeping track of what others are doing. With a small group, the project manager or group leader can take on the responsibility of keeping others informed. If it's a single organization, you can theoretically mandate a communication strategy from above, although in reality, this doesn't work effectively when the organization is large and diverse. For large-scale collaboration between different groups, neither of these are realistic options.    (KCB)

How can large groups communicate most effectively? The answer is stigmergy, a term ChrisDent first introduced to me about four years ago. Stigmergy is a form of indirect communication where organisms react to signs left by others. Ants communicate by stigmergy. They leave a trail of pheremones that other ants pick up and react to. Stigmergy -- not centralized command-and-control -- is responsible for those amazing anthills.    (KCC)

There is an equivalent pattern in effective large group collaboration: LeaveATrail. I've called this pattern ThinkOutLoud and VisiblePulse in the past, but I like "LeaveATrail" better, because of its association with stigmergy. (Obligatory karma reference: I first heard this name from PeterKaminski, who in turn credits ChrisMessina for explaining it as a principle of BarCamp.) MGTaylor calls this pattern ShipProduct? and often describes it in the context of StuartKauffman's work and patch theory.    (KCD)

The idea is simple. When you work, leave an artifact somewhere where others can find it. An artifact doesn't have to be comprehensive; in fact, it's often better when it isn't. A brief meeting summary is usually more useful than a full transcript. A brief summary with links to specific instances in the transcript is even more useful.    (KCE)

When you LeaveATrail, you're communicating to whomever wants to listen, which may effect how you express yourself. This can be disconcerting to some. People often point to the lack of response as a sign that tools like online forums, blogs, or Wikis aren't working. That's not necessarily the case. There may be a whole slew of lurkers who are reacting to the signs that you are leaving. (That said, ImmediateFeedback? is also an important pattern in OnlineCommunities?.)    (KCF)

This can also be difficult when determining what kind of trail to leave. Because you don't know who will be reacting to your signs, you can't target them. The solution is to ScratchYourOwnItch.    (KCG)

Emergence can't happen without LeaveATrail. However, LeaveATrail is just one of many conditions for emergence. You can't dictate whether emergence will happen, and when it does, you can't control what actually emerges. The best you can do is create conditions for emergence and hope that good things happen. This is disconcerting to many, and folks often react by trying to assert more control, which makes things worse.    (KCH)

LeaveATrail and other principles are helpful in designing community spaces. For example, if you are trying to integrate blogs or Wikis into a community's practice, the best way to do that is to apply the tool in such a way that it scratches an individual's itch while also leaving a trail. For example, many good project leaders are good at doing meeting summaries. Instead of having them email a small subset of individuals, have them email a public, archived mailing list. Better yet, have them blog their summaries and email links to the blog. You're not significantly changing individual behavior in these situations, but you are significantly improving your chances for large-scale collaboration.    (KCI)

/collaboration/patterns | Posted at 4:21pm

Sat, Aug 13, 2005

Patterns at WikiMania 2005    #

When I first met ChrisPeterson (now a BlueOxenAssociates advisor), she told me the story about coining "OpenSource." The sign of a good name, she explained, is when people naturally start using it on their own. At a meeting of developers and evangelists in early 1998, rather than argue strongly in favor of the term, she introduced it subtly. Although the response wasn't enthusiastic at the first, everyone in the room found themselves using the term, and by the end of the meeting, they all agreed to evangelize it.    (JMS)

Similarly, my strategy for introducing and identifying patterns of high-performance collaboration is to subversively introduce patterns into various communities and then to listen. If people naturally use a pattern in conversation, the name is probably good and the pattern itself is probably real and repeating. As people become familiar with the concept, they are more likely to identify and name other patterns. Over time, the language shifts your thinking, giving you a cognitive framework for thinking about, talking about, and improving collaboration and collaborative tools. Moreover, the process itself is iterative and collaborative, which is both the right way to develop PatternLanguages and also another application of collaborative patterns.    (JMT)

I've been giving some variation of a stock talk on patterns for over a year now, including last week at WikiMania 2005. It usually consists of a quick introduction, a few examples, and an interactive portion where I tease out patterns from the audience. The audience banter is always the best part. It's always different, and it's provided me with entertaining anecdotes, new patterns, and better pattern names.    (JMU)

Last week, I mentioned four patterns that Wikis facilitate: PermissionToParticipate, SharedDisplay, VisiblePulse, and WorkingDraft?. TimStarling followed my talk with an overview of MediaWiki development, and when he mentioned their IRC channel, he said, "This is our community's VisiblePulse." I love it when the process works!    (JMV)

The discussion teased out other patterns, especially [Celebration]? and [Initiation]?. (LindaRising and MaryLynnManns mentions both of these in their book. They have a better name for the latter, but I don't remember it off-hand.) One person told a great story about both. His team met for the first time in Australia, and before embarking on their project, they brewed beer that they planned on drinking after they finished their project.    (JMW)

Other patterns observed and not observed at the conference and within the community:    (JMX)

• The [Celebration]? at the end of the conference was great, but the [Initiation]? wasn't particularly remarkable. This isn't unusual for conferences, where [Initiation]? tends to be in the form of a keynote.    (JMY)
• One pattern closely related to [Initiation]? is [Introductions]?. At conferences, this generally comes in the form of name badges, which we had at WikiMania. I think there's a huge opportunity for further facilitating this pattern at conferences, which is something BlueOxenAssociates is working on. Hacking Days also would have been significantly more effective if we simply went around the room each day and quickly introduced ourselves. It's one of those patterns that sound obvious when you hear about it, but is often forgotten when actually designing an event.    (JMZ)
• Conferences usually do WaterCooler? well, and WikiMania was no exception. We had long lunches, a party on the last night, an IRC channel, and some organized activities in FrankfurtAmMain for stragglers following the conference. In particular, the organizers did two things really well. The HausDerJugend was an excellent choice of venue, because it was an intimate space where social interaction was practically unavoidable. Most of the participants stayed at the hostel, which meant that there was always an interesting conversation to be had by simply going downstairs and hanging out in one of the common rooms. Plus, most of us who stayed there also had roommates, which is not typical for the conferences I attend. The restaurants and bars -- touristy though they were -- were in very close proximity, which made it easy to grab a beer and talk. ([Food]? is a closely related pattern.) Finally, Hacking Days served as an unintentional WaterCooler?, at least for those of us who were not MediaWiki developers. Coming early is something the organizers should encourage more widely next time.    (JN0)
• I'm very biased towards highly interactive event design, and it seemed like it would have been especially appropriate for a Wiki conference. That said, the panel format worked better than at most conferences, and I think the Wiki culture of PermissionToParticipate had a lot to do with that. The audience interacted easily with the presenters at all of the talks I attended, and most of the speakers did a nice job of incorporating feedback into their presentations. One thing they did not do well was actively promote and integrate the conference Wiki as a place to take notes and have additional discussions. Again, this seemed surprising for a Wiki conference -- yet another indication that making patterns explicit is a good thing.    (JN1)
• Another favorite -- also found in Linda and Mary Lynn's book -- is SpotlightOnOthers. This runs rampant throughout the Wikipedia community, which is wonderful. Tim cited me when mentioning VisiblePulse, and by the next morning, SunirShah had incorporated PermissionToParticipate into his talk on conflict resolution. I found this time and again in people's talks. One reason it occurred so often during the conference is that the organizers used a Wiki to develop the program transparently. People watched other people's talks develop and incorporated their content even before the conference began.    (JN2)
• A critical pattern, especially for inter-organizational collaboration, is NeutralSpace. Wikipedia would not have been successful if it did not have an open content license (which facilitates NeutralSpace) and, to some extent, if it were a for-profit company. At the board panel on the last day, several people brought up the question of online ads. On the one hand, ads have the potential of bringing in a tremendous amount of revenue, which could be put to good use for the community. On the other hand, it breaks the NeutralSpace pattern that has served Wikipedia so well. The community was more or less split on this issue. My vote: No ads!    (JN3)

One last pattern that I both observed and missed was UsersTalkToDevelopers?, a pattern I first described in, "An Introduction to Open Source Communities." Previously, I criticized the MediaWiki developers for not practicing it enough. With the whole conference finally behind me, I want to both soften and and strengthen my statement.    (JN4)

Many of the MediaWiki developers came to the project as Wikipedia contributors. BrionVibber, one of the leaders of the project, probably never would have joined had it not been for the Esperanto Wikipedia, of all things. After having more time to interact and observe the developers, I think that on average, community interaction is more prevalent among the MediaWiki developers than it is with many other projects.    (JN5)

That said, it's still not nearly what it can and should be. During the sessions on politics and developing countries, several panelists complained that the tools had a way to go to meet their needs, and yet, none of the developers were attending their sessions. HosseinDerakhshan? noted that techies are generally not interested in issues outside of their sphere.    (JN6)

Not all the blame falls on developers, however. As great as it would have been to see more developers abandoning the technical sessions in favor of the more social ones, it would have been fantastic to see more Wikipedia contributors attend some of the technical sesssions. Both communities need to learn and respect each other's language if they truly want to engage collaboratively. [Bridges]? are critical to make this work. Note that this applies not only to MediaWiki, but to all OpenSource projects.    (JN7)

/collaboration/patterns | Posted at 12:07pm

Wed, Nov 26, 2003

"Turn Off Your Computer" and Other Pattern Ramblings    #

As I mentioned previously, BlueOxen is finishing up its second research report. We spent several hours developing a survey for the report, and all of us were quite satisfied with the final draft. Then we e-mailed the surveys. Almost immediately afterwards, the three of us thought of several more questions we would have liked to have asked.    (CR)

The experience struck a chord in JoshRai, who suggested there was a force there that manifested itself in several patterns. Last Thursday, he came up with a pattern as an example: TurnOffYourComputer. It's both a pattern for good living -- or as Josh called it, a "Martha Stewart" pattern -- and also a pattern for knowledge work. I think the underlying force is one that crops up constantly, and is worth discussing. I also think explaining this particular pattern is a useful way of demonstrating the difference between a pattern and a force.    (CS)

See more....

/collaboration/patterns | Posted at 6:33pm

---

Copyright © 2001-2007 Eugene Eric Kim. Some rights reserved.