GivingSpace – Eugene Eric Kim

The Unjoy of Panels

Published August 2, 2005 by Eugene Eric Kim

I’m a veteran panel moderator. I’ve been doing it since high school, and I think I’m pretty good at it. But I’m thinking about retiring from the business. (JKL)

Last week, I moderated the SofTECH / SDForum July meeting on “Architecting Community and Collaboration Solutions.” Tony Christopher had suggested me to Ron Lichty, the meeting producer. Ron and I, as it turned out, had met a few years earlier at a GivingSpace workshop. Ron explained to me his goals for the panel, told me who the panelists would be, and I said, “Sign me up!” (JKM)

The panel went well. The panelists — Tony Christopher, Zack Rosen, Sylvia Marino, and Scott Wilder — were great. Everyone told lots of great stories, but also respected the other panelists, and no one tried to dominate the floor, which made my job incredibly easy. More importantly, the audience was engaged with the topic and the panelists. Ron was great also. He had done a masterful job of organizing the event and preengaging the panel. (JKN)

The problem was that the panel format was wrong. Panels work best when they emerge as entertaining and informative roundtable discussions. As good as our panelists were, that was not going to happen, because the format did not optimally align with our goal — educating the audience. A panel format can achieve this goal — and ours did — but only in a broadcast model, which does not maximize group potential. (JKO)

It was clear from an informal poll I took at the beginning of the panel and the number of faces I recognized that we had a lot of expertise in the audience itself. It would have been far more engaging and educational for all involved had we done a more interactive format, where we spent an hour in break-outs, possibly followed by a moderated plenary discussion. The panelists, in this scenario, would have been co-participants with the rest of the audience. (JKP)

I moderated two panels and gave a talk at last June’s Collaborative Technologies Conference. One panel was in a traditional format for reasons largely out of my control, but I decided to play with the other two formats. In both of those cases, I turned the tables on the audience, rearranging the stage format into a circle, and basically played discussion moderator rather than panel moderator. Several people had already camped out in the back with their laptops open — almost assuredly planning to check email rather than listen to the talk — and a look of fear and shock came over their eyes when I told them to join me in the circle. (JKQ)

Several people approached me afterwards and praised the format. (My favorite moment was one night at dinner, when I introduced myself to Stowe Boyd, who wrote a great essay on panels. Upon hearing my name, Stowe said, “I want to thank you.” I was completely baffled by this, as we had never met, and Stowe had not attended any of my talks. Apparently, he had heard about my panels — probably from Arieanna Foley — and he was grateful that someone had tried something different.) These folks were clearly suffering from panel fatigue, and just the fact that we were doing something different and engaging improved the experience wildly for them. I guarantee that the circle format was also more informative for the audience as a whole, because it addressed their specific concerns and it introduced a set of viewpoints far more rich than just mine or a panel’s. (JKR)

As much as people respond to these more interactive formats, they are mere baby steps. Kindergarteners get in circles, for pete’s sake. Pre-school can be fun, but once you’ve been in kindergarten, you don’t want to go back. Facilitation techniques like Conversation Cafe and Open Space are at the first grade level, Aspiration is at second grade, and MGTaylor is at third. The latter techniques augmented with cutting edge collaborative tools is at least the fourth grade level, and we’ve only scratched the surface as to what’s possible. It’s just sad that the vast majority of conferences are at the pre-school level. (JKS)

There are situations where panels work well as a format, but they are vastly overdone. In any case, don’t let this post prevent you from inviting me to moderate a panel. Just expect me to make some strong demands concerning format. (JKT)

(See also Mary Hodder‘s excellent panel diatribe.) (JKU)

Blue Oxen and the Commons

Published October 6, 2004 by Eugene Eric Kim

There’s a fascinating discussion going on in the GivingSpace collaboratory about the commons, instigated by Phil Cubeta. Since that discussion is really focused on the Omidyar Network, I thought I’d throw in my two cents by describing how I see the Blue Oxen Collaboratories fitting into this discussion. (2DK)

We currently host 22 alpha collaboratories, some of which are private spaces for organizations. The vast majority of them are public, however, and we encourage all of our groups to have public spaces. In fact, we will probably mandate that all of our organizational members have at least some public space in order to use our infrastructure. (2DL)

We have not yet explicitly licensed the content of those discussions. It’s not an easy problem, although I suspect one of the Creative Commons licenses will work. However, we do know what principles we want the license to espouse: (2DM)

You own your own words. (2DN)
You’re speaking in public, so react accordingly. (2DO)

Blue Oxen is interested in open discourse, the free exchange of ideas, and most importantly, collective learning. We’re not interested in demanding royalties from someone else’s idea, just because that idea was formulated in our space. We’re interested in facilitating a better ecosystem, and we’re betting that we will benefit far more from a better ecosystem than we would by making claims on other people’s IP. (2DP)

“Facilitating the ecosystem” is something people hear me say often. It’s why all of our research is available under a Creative Commons license, and why all of our software is developed as Open Source. It’s why we emphasize interoperability with our tools, and why we’re doing our best to make it easy to export content from our collaboratories over to other sites. Our goal is to improve collaboration, and a policy of openness enables us to do that. (2DQ)

All that said, it’s not as simple or as easy as it sounds. For example, what do you do about requests to remove content from a Wiki or one of our mailing list archives? (We discussed this issue a few months ago at the Collaboration Collaboratory.) Also, what about governance? Our collaboratories are not the commons. Although we try to be as open as possible, I’m not inclined (as of yet) to make the space entirely self-governing. That said, because our tools are Open Source and because we share our knowledge openly, people have the flexibility to create a self-governing commons using our tools and knowledge. In this way, we’re supporting the creation of commons. Again, it’s all about the ecosystem. (2DR)

There’s also the question of sustainability. We’ve obviously closed off potential sources of revenue by being as open as we have. I strongly believe that we can not only sustain ourselves. We haven’t proven that yet, but I’m confident that we will soon enough. (2DS)

ChiliPLoP, Day 4

Published April 20, 2004 by Eugene Eric Kim

Last Friday was the last day of Chili PLoP. Ofra Homsky, Josh Rai, Linda Rising, Joe Yoder, and I met at our usual spot outside of the dining hall for our morning kickoff. We had two items on our agenda: workshop the patterns we had discussed the day before and that Josh and I had written up, and discuss next steps. (1DF)

Stone Soup (1DG)

We started with Collab:StoneSoup and decided to temporarily combine forces with the GivingSpace group, which had independently come up with a pattern of the same name. That experiment resulted in some constructive feedback but was short-lived. The most important lesson was that “Stone Soup” was a completely inappropriate name. (1DH)

The pattern had arisen from a point I had made the previous day about faith in process. I stated that people about to participate in a new process had to demonstrate a certain amount of faith up-front; otherwise, they risked subconsciously hijacking the process. You want to give the process the chance to succeed or fail on its own merit. (1DI)

Joe suggested calling this pattern, “Fake It ‘Til You Make It.” Ofra was reminded of a story, “Stone Soup,” which went like this. (1DJ)

A weary soldier discovered a village in the desert and knocked on every door asking for food. Everyone turned him away.    (1DK)

Undaunted, the soldier took his pot, filled it with water and a large, round stone, and put it over a roaring fire, constantly stirring and tasting.    (1DL)

The curious villagers came out of their houses and watched, until finally, one of them asked how it tasted. The soldier replied, “It’s good, but it needs some salt.” So the villager went inside her home and brought out some salt.    (1DM)

She again asked the soldier how the soup tasted, and he responded that it could use some carrots. So another villager brought some carrots. The process repeated itself until eventually, there was enough tasty soup to feed the entire village.    (1DN)

During our group writing exercise, it quickly became apparent that we all had slightly different understandings of the pattern. Mine focused on the point of view of the participant and on adopting new processes. Everyone else seemed centered on initiating new collaboration, setting up enough structure to make the collaboration seem real, at least until the collaboration became real. (1DO)

When I started refactoring and combining our work into a single pattern, I decided that there were multiple contexts for the same pattern, but that the solution was the same. I also decided to call it, “Stone Soup” instead of “Fake It ‘Til You Make It,” mostly because the former was a noun phrase. I had reservations, however, and our final day’s proceedings confirmed them. When we combined with the GivingSpace team, it became clear that there were at least three different versions of the Stone Soup story, each with different morals. (1DP)

After we split with the GivingSpace group, my team continued giving feedback about what I had written. I picked up lots of good advice and promised to incorporate their comments into a revision. (1DQ)

Kick Off (1DR)

I was happy when Josh willingly took on the Collab:KickOff pattern, because I didn’t think we were close to Shared Understanding. That said, Josh’s work on the pattern helped us make that leap. (1DS)

Originally, we called the pattern, “Kick Off Meeting.” I had asked whether the Kick Off meeting was, by definition, the first meeting. Ofra and Joe had said that it was not. However, as we started fleshing out the pattern, it wasn’t clear to me what the distinction was. People were mentioning a lot of things that supposedly happened at Kick Off meetings that I felt would happen regardless of whether or not a meeting was designated, “Kick Off.” The key distinction, in my mind, was whether or not those things would happen well. It wasn’t clear to me that denoting a meeting “Kick Off” was enough to make those things happen well. (1DT)

Josh’s work on the pattern made some of those flaws apparent. Having something concrete to work from allowed us to quickly zone in on the vital piece — benefits from the ritual celebration of initiating a new project. We decided to remove “meeting” from the name. (1DU)

In the end, this made perfect sense to me. We had defined collaboration as needing shared, bounded goals. We had also cited a pattern, Grand Finale (discussed in Linda and Mary Lynn Manns‘s upcoming book). It made sense that we also had a pattern for the beginning of a project as well. (1DV)

Next Steps (1DW)

One of the things I made clear to the group was that I considered this workshop to be the Kick Off to Blue Oxen Associates‘s ongoing Pattern Language effort. One of my broader goals is to do an ongoing series of workshops involving philanthropic foundations, nonprofits, and a variety of other organizations. These workshops would involve telling stories, mining for patterns, capturing those patterns, reinjecting them into the conversation, refining them, and so on. (1DX)

In the meantime, I plan on further developing the language that began forming at our workshop with the help of our Collab:PatternsWorkGroup. I also plan on submitting some patterns to the PLoP conference in September. (1DY)

I had an exceptional time at Chili PLoP. Lots of great people were there, and Arizona is warm and beautiful this time of year. More importantly, I was fortunate to have a great group of participants. Ofra, Josh, Linda, and Joe brought a tremendous amount of experience and enthusiasm to the process, which made the process both enjoyable and productive. I’m looking forward to the challenge of continuing what we started here, including another date at next year’s Chili PLoP. (1DZ)

ChiliPLoP, Day 3

Published April 20, 2004 by Eugene Eric Kim

Last Thursday, my workshop met for a second day. Having agreed on a working definition for collaboration (see Collab:Collaboration), we started working on the Pattern Language. As was the case the previous day, I knew exactly what I wanted to accomplish, and I made that clear when we got started. What differed this day, however, was that Linda Rising, Ofra Homsky, and Joe Yoder — our three experienced Pattern Language authors — led the way in terms of process. (1CT)

We began by laying out the index cards we had collected the previous day onto a table. The goal was to see what patterns we had and what seemed to be missing. The definition that we had collectively agreed on the day before helped us tremendously with this process. For example, because collaboration — as we defined it — required bounded goals, that meant there were patterns related to the start and end of the collaborative process. There were also patterns related to interaction (meetings for example) and knowledge exchange (Shared Display). (1CU)

Mapping out our cards also helped us identify gateways to other Pattern Languages, such as Linda and Mary Lynn Manns‘s patterns for introducing new ideas into organizations, Ofra’s patterns for leadership, Jim Coplien and Neil Harrison‘s organizational patterns, and GivingSpace‘s patterns of uplift. (1CV)

Lots of brainstorming and storytelling happened throughout. My favorite was a story that Joe Yoder told about a factory where he had previously worked, which literally left its financial books open on the factory floor. Anyone who worked at the company could examine the books and suggest improvements. The open books were a form of Think Out Loud that showed that the company treated its operations as a collaborative process involving all of its employees, regardless of position. Tremendously empowering stuff. (1CW)

Linda, Ofra, and Joe constantly stressed the importance of iteration and cautioned Josh Rai and me about getting too caught up with formality too early in the process. Ever fearful of being berated by Ralph Johnson or Jim Coplien, I would periodically complain, “That name isn’t a noun phrase!” Fortunately, the rest of the group kept me on track. We had plenty of time to weed out and refine our patterns after the brainstorming process. (1CX)

We ended our brainstorming at lunch, at which point we had 36 cards. After lunch, we picked two patterns — Collab:StoneSoup and Collab:KickOff — and Linda led us through a group pattern writing exercise. (I’ll say more about these two patterns when I describe Day 4.) She gave us a letter-sized piece of paper for each component of the Coplien Form (name, problem, context, forces, solution, rationale, resulting context, known uses, and related patterns). Each of us took one piece of paper, wrote down our ideas, then exchanged it with someone else for another piece of paper. The cycle continued until we all had our say to our satisfaction. Afterwards, we discussed what we had written. (1CY)

This was the first time Linda had tried this particular exercise, and I think it worked very well. It was particularly good at helping us reach Shared Understanding. We all had slightly different views of both patterns. Actually going through the group writing process helped make these differences explicit, at which point we were able to talk through our differences. (1CZ)

Because Josh and I were the pattern-writing newbies in the group, we each collected the sheets for one of the patterns and promised to combine, edit, and rewrite them into a readable draft. I chose Collab:StoneSoup; Josh took Collab:KickOff. The plan for Day 4 (which was only a half day) was to workshop our results. (1D0)

I ended the day with a brief overview of how blogs and Wikis integrated with Backlinks could be used to tie stories with corresponding patterns. (1D1)

Chili Beer (1D2)

Since that night was our last in Carefree, I decided to organize a margarita BOF. Earlier, somebody had told us about the Satisfied Frog, a legendary Mexican restaurant and bar that had “a thousand different kinds of margaritas.” This was the obvious place to hold our BOF, so Josh, Jerry Michalski, Gerry Gleason, and I trekked on over. (1D3)

As with most legends, the facts had been slightly exaggerated. The Satisfied Frog only served one kind of margarita, although in fairness, it did give us the option of frozen versus on-the-rocks and with or without salt. (1D4)

The restaurant did, however, brew its own special beer — chili beer — which was bottled with a serrano chili pepper. It had a nice kick to it, but it wasn’t overpowering. I recommend it to those with a a penchant for adventure and a bit of a heat tolerance. (1D5)

ChiliPLoP Day 1

Published April 14, 2004 by Eugene Eric Kim

Yesterday afternoon, I arrived in Phoenix, Arizona for Chili PLoP
2004. I hitched a ride with Ralph Johnson and Joe Yoder to Carefree,
Arizona, and soon found myself at the Lutheran Retreat Center, where the
conference is being held. (1BJ)

The post-dinner agenda was to discuss the structure of the
conference. Other than the meal schedule (which is strictly
enforced), there is no structure. This is what differentiates
Chili PLoP from Hillside Group‘s other PLoP conferences. The setting is
more relaxed, and the agenda is entirely flexible. (1BK)

Once we got business out of way, the fun began. There were a lot of
great conversations, and a few of us stayed up late into the night
chatting about everything from Pattern Languages to politics. (1BL)

Tom Munnecke got the discussion started by asking about the
generativity of Pattern Languages. This is an ongoing beef that Tom
has with Pattern Languages, a misunderstanding that’s important to
clarify. (1BM)

Tom’s thesis is that society is too problem-centric. For example, our
approach to healthcare is to cure sickness rather than to promote
healthy living. Tom’s GivingSpace project — and the reason he’s here
— is to identify and propagate patterns of uplift. This is a
wonderful effort. It’s related to our work on patterns of
collaboration, and it’s an effort I fully support. (1BN)

Patterns are often defined as solutions to problems in a context.
Tom’s complaint is about the term “problem”; he think it prevents
patterns from being generative. “Problem” in this context, however,
means, “Something that needs a solution,” not, “Something that is
wrong.” In other words, describing things in terms of problems and
solutions does not necessarily prevent the solution from being
generative. (1BO)

In fact, Christopher Alexander stresses the importance of identifying
generative patterns. Linda Rising cited an example first described by
Don Olson (and is also discussed in Linda’s book, The Patterns
Handbook). Beginning skiiers often have a tendency to lean back,
something that will cause them to lose their balance. You could say
that one pattern is, “Don’t Lean Back.” This is not very useful
advice. Leaning back is an instinctive, not conscious action. (1BP)

Don’s suggested pattern is “Hands In View.” This is a conscious action
you can perform, and the end result is that you lean forward. This is
a great example of a generative pattern. (1BQ)

Ralph cited a similar example in software development:
qmail. The motivation for qmail was to
build a secure mail server. The approach, however, was not to
identify and fix every security problem. The approach was to design
small, modular programs that were easy to verify as secure. In other
words, security was an emergent property of the software’s design. (1BR)