Group Counting Redux: Behind the Curtain

Posted on Published by Eugene Eric Kim

When Kathia Laszlo asked me to be a guest “lecturer” for her class, “Evolutionary Leadership, Collaboration, and Systems Thinking,” I jumped at the opportunity. Kathia and her husband, Alexander Laszlo, speak my language when it comes to collaboration and learning, and I was as excited to learn from them as I was to practice my craft with their class.    (MLW)

I had a difficult problem, though. What could I possibly do in two hours that was meaningful and interactive?    (MLX)

When I design a workshop, my goal is not to teach, but to create a space for collaborative learning. When done well, the experience is far more meaningful and engaging, and it results in deeper learning, both for the participants and for me, the facilitator. As much as I know about collaboration, groups know more. The design challenge is figuring out how to tap the Collective Wisdom of the group rather than broadcast my own knowledge.    (MLY)

The design ultimately depends on the size and makeup of the group, its familiarity with the topic, and the amount of Shared Language on that topic within the group. In this case, the class had just started, and it met infrequently. The students were familiar with the topic of collaboration, but they had not yet established a high-level of Shared Language about the topic.    (MLZ)

My game plan was simple. I expected the students to be intelligent and introspective. I would focus on modeling collaborative behavior and on building the groundwork for Shared Language. I would accelerate the Shared Language process by explicitly making it the goal of the exercises, something I rarely do when I have more time. And I would count on the students to synthesize their learning on their own time, rather than as a group.    (MM0)

We spent the first half hour working on a group counting exercise, which I first learned from Deborah Meehan. The game is normally played as an icebreaker, but when I saw Deborah lead it, she always followed it with a debrief, which seemed appropriate, given her emphasis on leadership. Since this class was also about leadership, I thought I’d have an extensive debrief as well as a few twists on the game.    (MM1)

Previously, I wrote:    (MM2)

Playing this game successfully with large groups seems to be a task that is crying out for top-down hierarchy. Maybe our intuition is wrong. Maybe we can — as a group — be aware of each other and learn to act as one without having someone tell us how to act. The group counting exercise seems to imply as much.  T    (MM3)

When you play the game a few times, you’ll notice a few things. First, the group typically learns from experience. If a pattern emerges, the group often repeats it. Second, because there is no time to prepare in a typically hierarchical process beforehand (i.e. “Let’s figure out our strategy!), leadership needs to emerge in different ways. For example, someone could start the pattern of raising his or her hand before naming a number.    (MM4)

There were about 40 people in the classroom. I wanted the group to play the game a few times, then think about these strategies in silence. I then would ask them to play with their eyes closed, figuring that all of the potential strategies required some visual cue.    (MM5)

However, someone in the class outsmarted me before we even started to play. After explaining the rules, I asked if anyone had any questions. One woman raised her hand and asked, “Is there anything preventing us from going around the room in order?” I smiled and ignored her question, but this is what was actually going through my head:    (MM6)

  • “Damn it. Shouldn’t have asked if they had any questions.”    (MM7)
  • “It’s all good. Just because someone proposed it, doesn’t mean the group will actually do it.”    (MM8)
  • “Even if they do it in a circle, it’s still good learning. We’ll just play a second time and explicitly disallow it.”    (MM9)
  • “Okay, now that that’s resolved, pretend that the question didn’t throw you.”    (MMA)

Ah, the joys of facilitation.    (MMB)

Here’s what ended up happening:    (MMC)

  • The first time, after I said “one,” two people immediately jumped in with “two,” forcing us to start over.    (MMD)
  • The second time, people tried to play the game randomly, and we choked quickly.    (MME)
  • The third time, we started going in a circle. About a third of the way through, however, the next person in line decided to break the circle and not say anything, defaulting the group to more typical game play. We choked quickly after that.    (MMF)
  • I then asked people to spend a minute thinking of strategies, then asked them to close their eyes and listen to their breathing. We got to the mid-20s before we failed.    (MMG)
  • I decided to try playing the game one more time with our eyes closed, but the class was obviously sick of it at this point, as we ended up going around in a circle.    (MMH)

We closed with a wonderful debrief. I asked the woman who broke the circle the first time around why she did it, and she said that she didn’t think it would be very interesting. Several people echoed her comments, saying that their motivation was more to see what happened than to “win” the game.    (MMI)

Several people noted that when we started, people were jumping in, because they wanted to make sure they got their number out of the way. When we closed our eyes, however, the energy shifted away from being heard to listening to others. The pace slowed down, and even though we weren’t successful, there was a rhythm that felt more promising.    (MMJ)

One student was reminded of an experience he had had in a group, where he decided to suppress his usual “leadership” instinct and just listen. To his surprise, everything that he had wanted to say was said by others. He concluded, “Sometimes the best thing you can do is be a follower.”    (MMK)

His story resonated with me in many ways, not the least of which was this very debriefing session, where I didn’t state a single observation. It was unnecessary. However, I didn’t completely agree with the student’s final comment. I approached him afterwards, told him how much I loved his story, but added, “I have to disagree with one thing. When you decided to just listen, you weren’t being a follower. You were still being a leader, maybe even moreso.”    (MML)

In my next post, I’ll conclude my summary and commentary of the class.    (MMM)

Quick Thoughts on BarCampBlock

Posted on Published by Eugene Eric Kim

I emerged from my summer hermitdom to attend parts of BarCampBlock this past weekend. My favorite part of Bar Camp was actually something I missed because I overslept on Saturday morning: the unveiling of the original Bar Camp attendee list (photo by Chris Heuer):    (MJC)

https://i0.wp.com/farm2.static.flickr.com/1352/1176806198_263159d5ab.jpg?w=700    (MJD)

This is such a wonderful picture on so many levels. Seeing it brought back vivid memories of the first Bar Camp: the sense of excitement about what a few passionate folks had created in a ridiculously short amount of time, the forging of new friendships and the strengthening of old ones. This little touch created a strong sense of continuity between the first camp, this third year anniversary celebration, and everything in-between. It also demonstrated the subtle difference between holding space well and simply holding space. Masters of this art understand the importance of the artifact, of Leave A Trail.    (MJE)

I didn’t get to stay as long as I would have liked, but here are some quick thoughts on what I did see:    (MJF)

  • The organizers (Chris Messina, Tara Hunt, Ross Mayfield, Liz Henry, and Tantek Celik) and volunteers did an incredible job of making everything run smoothly. The hardest part of a collaborative event isn’t the process; it’s logistics. In this particular case, the organizers had to deal with a sudden spike in registrations — 900 to be exact — with no clue as to the actual number who would show up (564 on Saturday, 260 on Sunday) and a location literally spread out over 11 locations within a few square blocks. When I saw various organizers on Saturday morning, I noted with surprise how calm everything was, and everyone just looked at me and laughed. There’s a ton amount of behind-the-scenes hard work and stress required to make any event run smoothly. Kudos to all who contributed.    (MJG)
  • There were a ton of first-timers there. I saw several people I knew, and many more I didn’t. I like to see about 25 percent yield of repeat attendees at events like these, and this came close to that. I think that’s outstanding. The danger of events like these is that they become cliques. That wasn’t the case with this Bar Camp. In some ways, I think the oversaturation of networking events in the Bay Area — including many Bar Camp spin-offs — as well as the spirit of Bar Camp prevented this from happening.    (MJH)
  • I heard a few folks comment on the lack of depth in the sessions, and I experienced some of this myself firsthand. This is common at open, collaborative events, but most folks misunderstand what this means. Open Space-ish events are particularly conducive to building Shared Language among disparate folks. Deeper learning and collaboration often occur as a result, but it doesn’t necessarily happen at the event itself. You can facilitate this deeper learning at events by making them more intentional — Internet Identity Workshop is a great example of this — but Bar Camps are more meta than that.    (MJI)
  • I loved the Continuous Learning, not just from the Bar Camps that the organizers had played an active role in, but from the wider Bar Camp community. The demo party, for example, was an idea borrowed from Bar Camp Toronto, and while the execution needed tweaking, I loved the spirit of experimentation.    (MJN)

More good thoughts from Liz, Ross, and Tara.    (MJJ)

Open Source Mergers and the Circle of UNIX

Posted on Published by Eugene Eric Kim

Lloyd Budd wrote a post today entitled, “GPL Encourages Collaboration,” that was highly serendipitous and that triggered a flood of thoughts, some of which I’ll try to capture here. Earlier today, I was rereading an interview I did with Sunir Shah a few months back for a paper I’m writing, and I latched onto a point that Sunir made about the proliferation of Wiki communities:    (MHR)

I see so many people start their own Wikis. They go to these other Wikis that are disorganized. They don’t feel like jumping in and learning everything because everything’s in different places, and they are not coherent. So they start their own.    (MHS)

There are now thousands of public Wikis, and they are all balkanized, because no one wants to collaborate. I understand that. It’s human nature. You collaborate within your group, but you don’t collaborate outside of that group.    (MHT)

On the one hand, I encourage the proliferation of Wikis, because if you disagree with someone, you should be able to do your own thing. On the other hand, true collaboration is showing a willingness to actually pull these communities together, a willingness to subsume your immediate need to be a true leader, build relationships, and pull people together.    (MHU)

Sunir’s insight is an important one. The existence of a commons isn’t in itself enough to guarantee collaboration. Ultimately, collaboration is intentional. You have to want to collaborate with others, and you have to be proactive about it. And it only takes two for starters.    (MHV)

That said, if you want to encourage collaboration, you have to start by eliminating as many barriers as possible. The first barriers are Shared Understanding and Shared Language. In the Open Source community, both of these have been indoctrinated in the form of Open Source licenses. The main reason for the effectiveness of these licenses as vehicles for Shared Understanding is Richard Stallman.    (MHW)

When RMS originally wrote the GPL, he embedded the philosophy behind the terms in the license itself. It was not simply a legal document, but an essay on the principles underlying software freedom. Regardless of how you feel about the GPL or RMS, these remain the fundamental principles behind why Open Source works, and more importantly, why collaboration is so rampant in Open Source communities.    (MHX)

However, as Sunir notes, this isn’t enough to guarantee collaboration. We see a lot of redundancy in Open Source, just as we see lots of redundancy in Wiki communities. And that’s okay. There are sometimes good reasons for this redundancy, and it’s healthy to facilitate it. But eventually, you want convergence also.    (MHY)

This is the crux of Lloyd’s post. He writes, “Forking is good, but not as good as merging.”    (MHZ)

Lloyd also cites a few examples (WordPress, gcc) and asks for others. There are tons of good ones, but my favorite is a bit obscure: UNIX.    (MI0)

That’s right, UNIX. Yes, the history of UNIX is fraught with ugliness, some of which still continues today. But it’s also one of the greatest examples of Open Source forking and merging. This is important, because it’s also the birthplace of the modern Open Source movement.    (MI1)

Here’s the quick summary. UNIX came from AT&T labs, and the original license terms were ambiguous (a massive understatement if there ever was one) for a number of reasons, the main one being that most people weren’t thinking about software as IP at the time. Stallman, of course, was one of the exceptions, and in 1984, he started the GNU project, whose goal was to reimplement UNIX under the GPL.    (MI2)

A few years earlier at UC Berkeley, Bill Joy had taken a different approach. He simply forked AT&T UNIX into what is now known as BSD UNIX. The new code eventually was distributed under the BSD license, which essentially allowed anyone to do whatever they wanted with the code, as long as they gave credit to BSD and didn’t sue anybody. This led to many, many new forks, especially proprietary ones from Sun (cofounded by Joy), IBM, DEC, SGI, and many, many others.    (MI3)

With the advent of the 386 in the late 1980s came a number of PC forks, including 386BSD (which begat FreeBSD, NetBSD, and OpenBSD), BSDI, SCO, and MINIX (which begat Linux). At this point, most versions of UNIX were also borrowing heavily from the GNU project.    (MI4)

By the late 1990s, we started seeing massive convergence. IBM, Sun, DEC (now HP), SGI, and SCO (yes, SCO) all switched over to Linux, and started merging some of their proprietary capabilities into the Linux kernel. Apple moved to FreeBSD.    (MI5)

What the heck happened? You could attribute this phenomenon to market consolidation, but that would only be telling part of the story. Market forces indeed played a strong role, just as they a play a strong role in anything that involves… well, markets. But the important points are these. The ability to fork UNIX into both proprietary and free versions allowed the market to innovate rapidly, and that innovation was critical to both the success of UNIX and to the growth of the industry as a whole. However, the existence of a free version of UNIX was critical in enabling the consolidation of all of these different UNIXes, even if they weren’t necessarily formal mergers. Why were all of these competing companies willing to throw their hat into the Linux ring? Because of the Open Source license, which protected companies from their competitors hijaacking the commons and using their own code against them.    (MI6)

Ironically, the story of UNIX is also one of the reasons I believe that the GPL’s terms are unnecessary for the proliferation of software freedom. The BSD license enabled proprietary forks, which arguably enabled innovation that wouldn’t have happened otherwise. In fact, it’s still enabling this today; look at Mac OS X. In the end, however, culture won out; these same proprietary companies are all supporting Open Source software, not because they had to (although they do now), but because they wanted to. Empowerment is stronger than enforcement when it comes to communities and collaboration.    (MI7)

I can’t resist one more small rant, a teaser if you will. Most Web 2.0 companies seem to have learned the superficial lessons of Open Source, but they’ve missed the main point. The argument that Open APIs obviate the need for Open Source completely ignores what history has taught us over and over again. One of these days, I’ll blog about this.    (MI8)

Being Ambushed by Terrell Russell

Posted on Published by Eugene Eric Kim

Gail Taylor told me an excellent story last Saturday that reminded me of an incident at the Internet Identity Workshop this past December. I was doing something that I am deeply opposed to — participating in a face-to-face conference without being fully present. Basically, I was sitting in the middle of the space doing work on my laptop while everyone else was participating in the conference. I felt guilty about it, but I wanted to talk to some people while they were in town, and I had a ton of work to do at the same time.    (LWP)

So I gave a talk on Identity Commons, attended a few presentations, talked to a few people, and spent the rest of my time doing my work and ignoring everyone else. It was actually quite nice. I was sitting in the middle of the large conference room at the Computer History Museum, visible to everyone, with people constantly milling around me. People who knew me stopped by to chat for a few minutes; people who didn’t just ignored me.    (LWQ)

Towards the end of the second day, I was basking in my productive anti-socialness, when a fellow who was sitting at my table started making small talk. It was harmless chatter, stuff that I could respond to while remaining focused on my work, but at some point, it felt wrong continuing to talk without introducing myself. Turns out the guy was Terrell Russell of claimID fame. I knew about claimID, but I knew nothing about Terrell. The same could not be said of him, who had known all along who I was, and who apparently follows this blog. (Hi, Terrell!)    (LWR)

That bastard must have used that knowledge against me, sharing ideas that he must have known would suck me into conversation. Either that, or he was just a nice guy who was passionate about his work. Either way, it worked. I ended up closing my laptop and having a great conversation with him.    (LWS)

What was he doing that I found so compelling? It was his Ph.D. research on Contextual Authority Tagging. The basis of the idea is simple: The best way to identify an authority on a topic is not to ask people to self-identify themselves as such, but to ask others to identify the people they consider to be the authorities. We can leverage this principle to locate expertise by building tagging systems where users tag other users with information about their expertise.    (LWT)

Terrell has thought really deeply about this, and several of his ideas are documented at his website and on his blog. Phil Windley and David Weinberger have also commented on his work.    (LWU)

I heard more original ideas about tagging in that 20 minutes of conversation than I’ve ever heard from anyone else. The one that really struck me was the notion of tag disparities: comparing what people say about you to what you say about yourself as a way of measuring reputation. Sound familiar? It’s a real-life instantiation of the Squirm Test!    (LWV)

I think there are some interesting tools that can be built on these ideas, and I have no doubt that Terrell will build them. There are also some face-to-face group exercises based on these same principles, and I’ve actually done one of them before (described below). You could also apply these ideas towards group evaluation.    (LWW)

I’ve been vividly reminded of our conversation on two occasions. The first happened later that week at the Blue Oxen Associates anniversary party. Peter Kaminski decided to do some social engineering of his own, and instead of asking people what they did, he asked them to tell him about someone else attending the party. Real-life, face-to-face, Contextual Authority Tagging! We actually did this for real at the 2005 anniversary party, where we had people literally stick name tags on other people’s back. It was an idea I stole from Chris Messina, who in turn had stolen it from a previous SuperHappyDevHouse gathering.    (LWX)

The second occasion happened this past Saturday. Gail recounted a story about a group exercise with five people, where each person was asked to write ten words that have to do with “love.” Out of the 50 total words, only three were the same! It was a stark lesson on how challenging it is to achieve Shared Understanding and how critically important Shared Language is.    (LWY)

The Blue Oxen Way

Posted on Published by Eugene Eric Kim

Back when Chris Dent and I started Blue Oxen Associates, we often referred to something called the The Blue Oxen Way. It was something that we both understood and recognized, but that we never actually articulated. Over the years, I tried to rectify this, and I generated pages and pages of notes (including three years worth of rambling blog posts) in the process, to no avail.    (LVU)

Recently, Chris articulated his visions for “Wiki Everywhere,” where he referenced some of our early conversations. As I read it, I relived many of these discussions, and suddenly, it all clicked for me.    (LVV)

The essence of The Blue Oxen Way can be boiled down into three ideas, each of which form the framework for our entire philosophy about collaboration:    (LVW)

The Squirm Test    (LW0)

The Squirm Test is a thought experiment for measuring the amount of Shared Understanding in a group by observing the amount of squirming in a room. Shared Understanding (which is not the same as “same understanding”) manifests itself in the formation of Shared Language. Shared Language is a prerequisite for collaboration.    (LW1)

Much of the messiness of the collaborative process can actually be attributed to lack of Shared Language. Great collaborative design accounts for this rather than wishing it away, which is how most of us deal with it.    (LW2)

Shared Language is The Red Thread that binds all of the crazy things I’m involved with, from Pattern Languages to Wikis, from face-to-face facilitation to organizational strategy. The Squirm Test is a wonderful embodiment of Shared Language.    (LW3)

Be Less Dumb    (LW4)

If Shared Language is the tie that binds, then being Less Dumb is the state that we are all striving to reach. Why are we playing this game in the first place? To be Less Dumb, of course! As you go to bed every night, if you can’t look in the mirror and say, “Today, I became Less Dumb,” then you’re not doing your job.    (LW5)

Less Dumb is the negative framing of “augmentation,” but it sounds a heckuva lot better, and it embodies the same philosophy. Tools should make people Less Dumb. Processes should make people Less Dumb. How do we measure collaboration? One way is to see if we’re Less Dumb in the process.    (LW6)

That’s obvious, you say? If it’s so obvious, why do most tools and processes make us More Dumb rather than Less Dumb? And why are we so often willing to live with that? It may sound obvious, but are we really paying enough attention to this?    (LW7)

Bootstrapping    (LW8)

With Less Dumb and Shared Language (as embodied by the Squirm Test), we have our target and the glue that keeps us together. Our process — the way we get to our target — is bootstrapping. Bootstrapping is building on top of things that already exist, then building on top of that. (The notion of bootstrapping is also the reason why we called ourselves Blue Oxen Associates.)    (LW9)

The most vivid images of my best experiences collaborating have to do with movement — my actions resulting in other people’s actions, which result in even more actions, which inspire me to act further. This is bootstrapping at its best.    (LWA)

Purple Numbers are ultimately about building ideas on top of pre-existing ideas — knowledge synthesis (i.e. becoming Less Dumb) by reusing existing ideas. Also known as bootstrapping.    (LWB)