Something Special in St. Louis

There’s something special brewing in St. Louis, and it ain’t Budweiser. My side of the story begins in the Bay Area. We’ve got this special culture here in California. It’s a culture of openness, of collaboration, of entrepreneurship, and of tolerance. Combine that with a wonderfully diverse and intellectual community, and you get a tremendous amount of good vibes and innovation. The Bay Area is so wonderful, most of us don’t see any need to go anywhere else, and those who do often experience severe culture shock. Yes, Virginia, not everyone is like us Californians.    (LBJ)

In some ways, that’s a good thing, but in many ways, it’s sad. True, California is beautiful. True, the people here are brilliant and wonderful. But, there are brilliant and wonderful people who live outside of California, and there’s no reason why those folks can’t enjoy the same community vibe that we do out here. The Internet allows us to transcend geographical boundaries and form a virtual community with a similar vibe, but it still pales in comparison to the experience of being physical immersed in this type of environment. The barrier to this sort of vibe emerging in a geographical community is usually culture.    (LBK)

Is it possible to shift the culture of a community (or an organization) to be more collaborative, more tolerant, more innovative? Absolutely. It’s not easy, but it’s possible, and like all great things, it starts with great people, and it has to start small.    (LBL)

St. Louis has these ingredients as well as a growing consciousness about what is possible. The right people are there, and they are starting to discover each other. If this growing community fosters these opportunities, a wonderful prairie will emerge.    (LBM)

This past Wednesday, I did my part by co-facilitating the first gathering of the St. Louis Collaboratory, which was formed by Kellee Sikes and three of her colleagues (Mark Richman, Donna Mickens, and Valerie Hartman). (Pictures from the event.) The gathering was modeled after the “Tools for Catalyzing Collaboration” (TCC) workshops I co-organized with Jeff Shults earlier this year in San Francisco. Kellee attended our second workshop, and enjoyed it so much, she decided to try and bring a similar experience to her community in St. Louis.    (LBN)

https://i0.wp.com/static.flickr.com/92/273875599_bd3b84ff7d_m.jpg?w=700    (LBO)

Kellee, Mark, Donna, and Valerie recruited a fantastic and diverse group of participants. We had folks from both non- and for-profits, from large and small companies, from technology, health care, and organized labor. These people were thoughtful and open-minded. They came into the workshop with a healthy dose of skepticism, but also a willingness to play. What surprised me the most was that several of them had thought as deeply about collaboration as anyone else I’ve ever met.    (LBP)

I learned a tremendous amount listening to this group and watching them work. I could write 50 blog entries about the things I learned, stories I heard, and insights I gained. (I’ll be happy if I manage three.)    (LBQ)

At dinner later in the evening, I told several people that it would be a travesty if they did not continue engage with each other. You can do amazing things in a day. My goals were to expand their consciousness, to make them aware of each other, to start seeding Shared Language, and to give them an opportunity to experience a different kind of collaboration. We met these goals, but they barely scratch the surface of what’s possible.    (LBR)

The opportunity is there. Kellee and company are planning another workshop in January, and hopefully some of the participants from this week will play a more active role in designing the next event. Moreover, there are complementary events cropping up in St. Louis.    (LBS)

Through a serendipitous conversation with Jay Cross last month, I discovered Dave Gray, the founder of St. Louis-based XPLANE, which does visual modeling and facilitation. Dave introduced me to Matt Homann, a lawyer by trade who recently formed a company, LexThink, to organize more collaborative gatherings. Matt has been experimenting with a different kind of networking event in St. Louis known as Idea Markets, and the second one just happened to be this past Tuesday. It was an excellent event, and I’d encourage people from the area to go. This style of event is a dime a dozen in the Bay Area, but we rarely see the mix of people that Matt managed to draw.    (LBT)

https://i0.wp.com/static.flickr.com/91/273871891_6afb850afc_m.jpg?w=700    (LBU)

What’s different about St. Louis Collaboratory and events like Idea Markets is that they’re not about Drive-By Networking. They’re not about, “What can you do for me?” They’re about, “What can we do with each other?” That, my friends, is what collaboration is about. I’ll be watching these developments closely to see what emerges.    (LBV)

BlogHer: Not Just a Conference

Elisa Camahort, Lisa Stone, and Jory Des Jardins, the founders of BlogHer, spoke at last Monday’s Collaboration SIG meeting, and they absolutely blew me away. I’ve got many great female colleagues, and I’d heard great things about BlogHer last year, so I figured it was a good thing. What I didn’t know was how thoughtful these three women were about collaboration and how active a role BlogHer was playing in facilitating this network of women bloggers.    (KRT)

They won me over right from the start when I approached them about format, and they said they preferred to do it Donahue-style. I asked them whether they needed a moderator, and they said the three of them would just play off of each other and go from there. I asked what they thought about shifting the room into a circle, and they said they preferred it.    (KRU)

https://i0.wp.com/static.flickr.com/70/176131867_6e142892ca_m.jpg?w=700    (KS2)

The talk was entitled, “From Hierarchy to Community,” and they spoke both about their relationship with the community-at-large (which they played a big role in bringing together) and with each other, as equal partners of an LLC. Much of what they said about collaboration resonated strongly with me, and I found myself nodding a lot. For example:    (KRV)

  • Lisa said, “Collaboration is not consensus.” Being collaborative does not mean getting everyone to agree on everything.    (KRW)
  • Elisa talked about the transition between conversation and action, and noted that setting boundaries played a big role in making sure that action happened.    (KRX)
  • Jory talked about the importance of attribution — Spotlight On Others. She also called collaboration “laborious” a number of times. There’s overhead when you collaborate, and it can be a frustrating process, but there’s a huge payoff as well. The big ones are Shared Language and trust. Charles Welsh, one of our co-chairs, noted afterwards that the three mentioned “trust” 14 times throughout the evening. (Thanks for counting, Charles!)    (KRY)

There are a lot of organizations right now who are trying to figure out how to facilitate networks sustainably. I think BlogHer is onto something good — their values are on-target, and they’ve got three very smart and competent leaders — although whether or not their model is sustainable is still an open question. I wouldn’t bet against them, though. They’re doing some interesting things with their advertising network, for example.    (KRZ)

There’s also a lot they can learn about even more powerful models of collaboration and transparency. For example, I liked their approach to the BlogHer conference, but I couldn’t help thinking about how they were going through the exact same process that Harrison Owen went through 20 years ago before he invented Open Space. It’s not an indictment of them, but a constant reminder that those of us who are passionate about collaboration are still not close to knowing what everyone else knows, and it’s further reinforcement that Blue Oxen Associates‘ mission is an important one.    (KS0)

In any case, I’m looking forward to following BlogHer‘s progress. Check out the podcast from the meeting, and also Elisa’s comments afterwards. The next conference is July 28-29 at the Hyatt San Jose in San Jose, California, and there are still spots open for the second day, so check it out.    (KS1)

Developing Shared Language

Drummond Reed recently wrote about the Identity Rights Agreements session at last month’s Internet Identity Workshop. While the outcome was fruitful, Drummond wrote, “The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject.”    (KNJ)

Jamie Dinkelacker told me a similar story last year in describing a SOA gathering of gurus. The goal was to share knowledge and to advance the state of the art, but the participants spent most of their time arguing over the definition of “services.”    (KNK)

The problem in the first case was with expectations. The participants should have expected some ramp-up time would be necessary to get started, because they needed to establish some Shared Language. The problem in the second case was with process. The participants did not have an effective strategy for developing Shared Language, and thus, the latter ended up monopolizing the whole workshop.    (KNL)

Shared Language is a prerequisite to collaboration. Without Shared Language, we can’t collaborate. It’s as simple as that. When a group tries to collaborate without having Shared Language, the group will try to create it, whether it’s aware of it or not. This creation process is often frustrating and painful, and as a result, people sometimes try to skip this step or belittle the process. This is a problem. You can’t skip this step.    (KNM)

When designing collaborative spaces — both online and face-to-face — you have to build in time and space for developing Shared Language.    (KNN)

If you examine every good collaborative, face-to-face process for large groups, you will find that all of them generally recommend a minimum of three days. I haven’t found a rigorous explanation for why three days work so well, but the pattern is consistent, and we can certainly speculate. Much of it has to do with building in enough time to develop Shared Language. (Michael Herman, Open Space facilitator extraordinaire, has suggested that it’s less about the three days and more about the two nights — having our minds go through two natural work-process-rest cycles. I think he’s onto something.)    (KNO)

The first day is always about developing Shared Language. MGTaylor calls it the “Scan” day. Phil Windley calls it the “butt-sniffing” day. Regardless of what you call it, you need to design for it. It’s going to happen whether you like it or not. The question is whether or not it will happen effectively while leaving time for action.    (KNP)

There are two myths regarding how you create Shared Language. The first is that “shared” is equivalent to “same.” They’re not. Shared Language means that you understand how others around you are using terminology. Some level of sameness is obviously useful, but when you’re dealing with something relatively complex, sameness is both impossible and undesirable.    (KNQ)

I devised a metric several years ago called the Squirm Test that’s similar in concept to Wikipedia‘s Neutral Point Of View. The test is simple. Sit your team around the table. Have each person stand up and give a brief project description and status report. During the pitch, no one is allowed to talk, other than to ask clarifying questions. You have a perfect level of Shared Understanding and Shared Language if you make it around the room without anyone squirming.    (KNR)

The second myth is that creating Shared Language consists of creating a dictionary. That’s certainly one way to approach it, but it’s not the only way, and often times, it’s not the best nor the fastest way.    (KNS)

There are three elements to creating Shared Language:    (KNT)

  • Share individual contexts    (KNU)
  • Encourage namespace clash    (KNV)
  • Leave enough time and space to work things out    (KNW)

Sharing individual contexts is a fancy way of saying, “Know your audience.” Or, more accurately, know who you’re working with — their world view, their values, etc. You don’t have to use the same terminology the same way; you just have to understand what people mean and where they’re coming from. For some techniques on how to do this, see Collab:KnowTheParticipants.    (KNX)

I’ve written many times about how Wikis and tagging encourage namespace clash, which in turn encourages Shared Language. From a facilitation standpoint (both face-to-face and online), if you pose questions that stretch the mind, you also draw out namespace clash. MGTaylor is especially good at doing this with its Design Shops. Allen Gunn uses a technique called a spectrogram where you stretch a piece of masking tape across the room, ask a controversial question, then tell people to go to the place on the tape that represents their position on the question. You then ask people along the spectrum why they’re standing where they’re standing, and you give people the chance to move around based on other people’s answers. If you ask the right question, you’ll not only quickly get a great sense of your audience, but you’ll also draw out different interpretations of language.    (KNY)

Finally, simply scheduling time and space where Shared Language is the primary goal is useful. People are good at figuring out how to communicate with each other if you give them the space to do it. If you set unrealistic expectations on the first day of a three day event, then you just stress out your participants. If you spend the first day exploring broader questions, your participants may feel flustered or frustrated, but they will find that the work goes much more smoothly in the ensuing days.    (KNZ)

Developing Shared Language is an ongoing process. Doing actual work is one of the best ways to build shared context, which in turn builds Shared Language. The trick is to have stagger your work goals based on the Shared Language that already exists. The exercises you go through can become more and more focused over time, as the amount of Shared Language increases.    (KO0)

At the Blue Oxen Associates Tools for Catalyzing Collaboration workshops — one-day workshops with about 25 participants — we don’t do participant introductions. We assign teams and have people go straight into their exercises. However, we pay careful attention to how we assign the initial teams, and we structure the exercises accordingly. For example, at our January workshop, we started by pairing people who either already knew each other or were in similar fields, and we had them start their exercises immediately. We then grouped pairs and had them present their work to each other. Finally, we had a plenary session where each group reported on their work, followed by a plenary discussion. Our participants were engaged right away, and the shared experiences acted as an icebreaker, which made it easier to meet new people and to talk in our designated networking times (e.g. lunch). We also had online profiles up on our Wiki, so that people could find out more about the other participants before, during, and after the workshop. Several people commented afterwards about the lack of group introductions. All of them liked it.    (KO1)

The Story of Glormf: Lessons on Language and Naming

Jack Park recently asked about Link As You Think on the Blue Oxen Collaboration Collaboratory. I’ve written several blog posts on the matter, but there’s not much else out there. This was a great excuse for me to tell a few vignettes about Shared Language and the importance of names.    (KMO)

Glormf    (KMP)

This is Glormf, courtesy of the uber-talented cartoonist, Brian Narelle.    (KMQ)

(KMR)

Fen Labalme coined the term (originally spelled “glormph”) at an Identity Commons retreat in July 2003. We were strategizing about next steps, and we found that we were all struggling to describe what it was that we were all working on. Although we all had different views of the proverbial elephant, we were also convinced that we were talking about the same thing. In an inspired moment of clarity, Fen exclaimed, “It’s Glormf!” Much to our delight, Brian was listening to the conversation and drew Glormf for all of us to see.    (KMS)

Glormf’s birth lifted a huge burden off our shoulders. Even though Glormf was mucky, it was also real. We knew this, because it had a name and even a picture, and we could point to it and talk about it with ease. The name itself had no biases towards any particular view, which enabled all of us to use it comfortably. Each of us still had a hard time describing exactly what Glormf was, but if anyone challenged Glormf’s existence, any one of us could point to Glormf and say, “There it is.”    (KMT)

We had created Shared Language, although we hadn’t rigorously defined or agreed on what the term meant. And that was okay, because the mere existence of Shared Language allowed us to move the conversation forward.    (KMU)

Ingy’s Rule and Community Marks (KMV)

Ingy dot Net‘s first rule of starting a successful Open Source project is to come up with a cool name. I like to say that a startup isn’t real until it has a T-shirt.    (KMW)

Heather Newbold once told a wonderful story about how Matt Gonzalez’s mayoral campaign buttons galvanized the progressive community in San Francisco and almost won him the election. As people started wearing the green campaign buttons, she described the startling revelation that progressives in San Francisco had: There are others out there like me. A lot of them. I was amazed to hear her speak of the impact of this recognition, coming from a city that has traditionally been a hotbed of activism.    (KMX)

There’s a pattern in all of these rules and stories. I struggled to come up with a name for this pattern, and the best I could do for a long time was Stone Soup (courtesy of the participants in my 2004 Chili PLoP workshop). I loved the story associated with this name, the parable of how transformational self-awareness can be. But, it wasn’t quite concrete enough for my taste.    (KMY)

I think Chris Messina‘s term, “Community Mark“, is much better. Chris has actually fleshed out the legal implications of a Community Mark, which I recommend that folks read. Whether or not you agree with him on the details, the essence of Community Marks is indisputable: Effective communities have Community Marks. Community Marks make communities real, just as the term “Glormf” made a concept real. That’s the power of Shared Language.    (KMZ)

Pattern Languages and Wikis    (KN0)

Pattern Languages are all about Shared Language. Much of Christopher Alexander‘s classic, The Timeless Way of Building, is about the importance of names. In his book, Alexander devotes an entire chapter to describing this objective quality that all great buildings have. As you can imagine, his description is not entirely concrete, but he does manage to give it a name: “Quality Without A Name.” Call it a copout if you’d like, but if you use the term (or its acronym, “QWAN”) with anyone in the Pattern Language community, they will know what you’re talking about. Shared Language.    (KN1)

Ward Cunningham was one of the pioneers who brought Alexander’s work to the software engineering community. He created Wikis as a way for people to author and share patterns. Not surprisingly, an important principle underlying Wikis is the importance of names. Regardless of what you think about WikiWords, they have important affordances in this regard. They encourage you to think of word pairs to describe things, which encourages more precise names. They discourage long phrases, which also encourages precision as well as memorability. The more memorable a term, the more likely people will use it.    (KN2)

Ward often tells a story in his Wiki talks about using Class-Responsibility-Collaboration Cards to do software design. One of the things he noticed was that people would put blank cards somewhere on the table and talk about them as if there was something written there. The card and its placement made the concept real, and so the team could effectively discuss it, even though it didn’t have a name or description. (Ward has since formalized leaving CRC cards blank as long as possible as a best practice.) This observation helped him recognize the need and importance of Link As You Think, even if the concept (or Wiki page) did not already exist.    (KNG)

Open Source: Propagating Names    (KN3)

One of Blue Oxen‘s advisors, Christine Peterson, coined the term, “Open Source.” In February 1998, after Netscape had announced its plans to open source its browser, a few folks — Chris, Eric Raymond, Michael Tiemann, Ka-Ping Yee, and others — gathered at the Foresight Institute to strategize. At the meeting, Todd Anderson complained that the term, “Free Software,” was an impediment to wide-scale adoption. After the meeting, Christine called up Todd and suggested the term, “Open Source.” They both loved it. But, they didn’t know how to sell it.    (KN4)

So, they didn’t. At the followup meeting a few days later, Todd casually used the term without explanation. And others in the room naturally picked up on the term, to the point where they were all using it. At that point, they realized they had a good name, and they started evangelizing it to the rest of the community.    (KN5)

Names change the way we think about concepts, and so propagating names widely can shift the way people think about things. This is what happened with “Open Source.” This is what George Lakoff writes about in Moral Politics.    (KN6)

The mark of a good name is that people naturally start using it. A name can come from the top down, but it can’t generally be forced onto people.    (KN7)

Angry Rant on Wikis

Earlier this month, Jonas Luster invited me to speak at WikiWednesday. I didn’t have anything prepared, and I didn’t feel particularly motivated to prepare anything, so, I told Jonas that I was just going to rant. Jonas, being Jonas, loved the idea. So after IIW wrapped on May 3, I headed up to Palo Alto. I promised folks at IIW that I was going to give an angry rant on Wikis, and so several people decided to come watch, including Phil Windley, who blogged it. Feedback was great, except for a few complaints that I wasn’t all that angry. I promise to get more worked up next time, folks.    (KK2)

I’ve made all the points I made in my rant before in some form or another, often on this blog. Nevertheless, it was the first time I shared these ideas as one semi-cohesive thought, and so it’s worth rehashing the points here.    (KK3)

Overview    (KK4)

There are two things that make Wikis cool:    (KK5)

Lots of folks have latched onto the open access part, and there’s been some interesting exploration in this area. Very few folks know about or understand the Shared Language aspect. I think this is a huge loss, because it’s what makes Wikis truly transformational.    (KK8)

Open Access    (KK9)

Since I had just come from IIW, I started with digital identity. First, I said that all Wikis should support some form of distributed Single Sign-On, be it OpenID or something else. Implementing Single Sign-On does not imply loss of anonymity. Most Wikis give you the choice of logging in or not; implementing Single Sign-On would give you the additional choice of using a single identity across multiple sites.    (KKA)

Why would this be useful? Consider Wikipedia. As my friend, Scott Foehner, commented in a previous post on this topic (to be visible again when I turn comments back on), Wikipedia actually consists of a number of different Wikis, one for each language plus a number of special Wikis, such as its community site. Each of those Wikis require a separate user account. Not only is this a huge inconvenience, it effectively prevents you from having a single digital identity (along with your associated reputation) across each of these sites.    (KKB)

Simply having Single Sign-On across all of the Wikipedia Wikis would be valuable. More importantly, the identity community has converged to the point where it doesn’t make sense to roll your own protocols. There are several good existing protocols to choose from, and many of those are in the process of converging.    (KKC)

Reputation is closely associated with identity, and it’s also been one of the most popular topics in the Wiki community over the past year. However, most people have a misguided notion of what reputation is and what we should do about it. Reputation is what others think about you. Reputations exist in every system, whether or not they are explicitly represented. Reputation cannot be quantified. However, you can identify the factors that determine reputation and make those factors more explicit.    (KKD)

In Wikis, this could manifest itself in a number of ways. For example, one way to determine the quality of a page is to view the number of people who have edited it. You could make that number explicit by subtly changing the background color of that page — slightly yellowed for a page with few contributors and bright white for a page with many contributors.    (KKE)

The important point here is that you are not making a value judgement on reputation. You are not saying that a page that has many authors is better than a page that does not. All you are doing is making it easy to see that a page has many authors. Readers can determine for themselves how much weight (if any) to place on this factor for the reputation algorithm in their heads.    (KKF)

The most important button on a Wiki page is the Edit button. That button implies Permission To Participate. It should be one of the most visible buttons on any Wiki. If a Wiki looks too good, that discourages participation. Who wants to edit something that looks like a finished product? Ward Cunningham used to suggest sprinkling typos across a Wiki page to encourage others to participate.    (KKG)

At this point in the rant, I plugged both Ward and MeatballWiki. The Wikis success is no accident. A lot of the fundamental design features that make Wikis powerful were completely intentional, a testament to Ward’s brilliance. Additionally, most of what I ranted about is not new to the Wiki community. A lot of it — and more — has been discussed on the venerable MeatballWiki. If you really want to get a deeper understanding of how to improve Wikis, you should be on Meatball.    (KKH)

Shared Language    (KKI)

Last September, I wrote:    (KKJ)

What really makes the Wiki’s LinkAsYouThink feature special is that it facilitates the creation of SharedLanguage among the community that uses it. As I’ve said so often here, SharedLanguage is an absolute prerequisite for collaboration. The lack of SharedLanguage is the most common roadblock to effective collaboration, be it a small work team or a community of thousands.  T    (KKK)

It bears repeating over and over and over again. Wikis are transformational because they facilitate Shared Language. This is a feature that should be propagated far and wide, both in Wikis and other Collaborative Tools.    (KKL)

I noted two possible convergences. The first is Wikis and tagging. They both share a similar principle, namely namespace clash, and we should look at ways of combining these two concepts. For example, where’s the tag cloud view of a Wiki’s page index? Another idea: Clicking on a tag should also return Wiki pages of the same name. Technorati should be indexing Wiki pages and treating their titles as tags.    (KKM)

The second is implementing Link As You Think in all tools. Blogs that are built on top of Wikis (such as TWiki and JotSpot) have these features, but you don’t have to build a tool on top of a Wiki for this to work. This blog runs on blosxom, but it has Link As You Think. Chris Dent‘s blog runs on MovableType, and it has the same feature. It shouldn’t just apply to blogs, either. It should work in web-based forums and other Collaborative Tools.    (KKN)