Evolutionary Leadership Workshop: Final Exercise

For the last exercise of my guest stint at Alexander Laszlo and Kathia Laszlo‘s Evolutionary Leadership class a few weeks ago, I decided to have the group come up with a working definition of “collaboration,” as well as thoughts on patterns of and metrics for effective collaboration. If this sounds boringly familiar to regular readers of this blog, it should. This conceptual framework is fundamental to everything I do, and I spend a lot of time thinking, writing, and leading workshops about it.    (MMQ)

It was all par for the course for me, except I only had 90 minutes. The way I usually approach this in my workshops is to start with storytelling, model the collaborative experience, then have the participants synthesize the framework themselves based on their own learning. We didn’t have time for that. I thought about giving up and doing a traditional lecture, and if I had had slightly less time (say, an hour), I probably would have. But, that would have been extremely lame, and I wanted to see if I could pull off something interesting in 90 minutes.    (MMR)

What I decided to do in the end was create a makeshift anthropology experiment, with the students acting as both the subjects and the anthropologists. I divided the class into four teams. The first three teams would spend half an hour working on the same problem: Define collaboration. However, each team would have different process and tool constraints. The fourth team would observe the other three working.    (MMS)

The three teams were Team Nike, Team Wiki, and Team Taylor. Team Nike’s constraints were simple: It had none. I gave them the challenge without guidance or constraints, and it was up to them to figure out how to go about solving the problem. Their task was to just do it.    (MMT)

Team Wiki was divided into three subteams. They were allowed to interact as much as they wanted and however they wanted with their subteams, but they were not allowed to verbally communicate between subteams. There was a laptop projected in the middle of the room running a text editor. The team’s final product would be whatever was written on the text editor at the end of their time. Only one group could be at the keyboard at a time, and they could write whatever they wanted on the editor.    (MMU)

https://i1.wp.com/farm2.static.flickr.com/1390/1424241488_9de86fefbb_m.jpg?w=700 https://i1.wp.com/farm2.static.flickr.com/1142/1423359835_cad0b5609b_m.jpg?w=700    (MMV)

The final team, Team Taylor, was given a process similar to one I’ve used in many other workshops. They initially broke up into small groups and shared personal experiences with great collaboration. They then regrouped and worked through a series of “Is it Collaboration?” scenarios. Finally, they were given the final exercise and asked to put together a definition given their previous work. (They were named after Blue Oxen advisor Gail Taylor and her husband, Matt Taylor, who were my advanced introduction to workshop designs like these.)    (MMW)

Why this breakdown? I really wanted the students to think carefully about their experiences collaborating with each other as much as the content of the exercise itself. By having three processes going simultaneously, it was clear that the compare-and-contrast would be an important element in this exercise. By having full-fledged observation teams, this process discussion would be a major part of the report-out as well as the resulting work products.    (MMX)

I think the exercise worked moderately well. The participants seemed to enjoy the process, and the comments in the debrief were excellent. The timing was predictably tight, and there were some aspects of the exercise that could have been tightened up some. The most frustrating omission for me was the lack of a collective synthesis process, but I knew that would be the case from the start.    (MMY)

I was most curious to see what Team Nike would do, since they had the least constraints. Both the team itself and its observers noted that initially, there was a lot of talking past each other. I think that’s very natural for large groups that are new to each other, especially when under time constraints. I observed something similar during the Hidden Connections breakout I participated in earlier in the day, and we all saw this during the group counting exercise as well.    (MMZ)

There are several ways to counter this phenomenon. The method most people tend to default to is “stronger facilitation” — having a designated facilitator maintain tight control over the process. There’s a time and a place for this, but I think the resulting order is largely artificial, and that the group will likely fail the Squirm Test. If you do have a designated facilitator, one simple technique that is remarkably effective and underutilized is to simply ask the group to listen to and respect their peers. We saw this work with the group counting exercise, and I’ve seen it work again and again in other meeting contexts.    (MN0)

Although there was no designated facilitator for Team Nike, a few individuals stepped up to take on that role. There was no decision-making process up-front. One student simply started acting as the facilitator, and the others followed. (Leadership is action.) Another student started taking notes and often validated what other people said, which helped slow down the discussion and validated individual participation. This is an outstanding example of the artifact playing a strong, facilitative role, a premise underlying patterns such as Shared Display and processes such as Dialogue Mapping.    (MN1)

At one point, Alexander Laszlo, who was participating in Team Nike, approached me and asked, “Can we collaborate with other groups?” I laughed and said, “You can do anything that wasn’t expressly forbidden.” Because of the time constraints, Team Nike didn’t end up pursuing this, but I was glad they had this insight in the first place. It’s always one of my favorite moments when somebody realizes, “Is there any reason why we couldn’t collaborate with others?” It often takes surprisingly long for someone to figure this out, even at workshops where collaboration is one of the stated goals. It’s a sign of how culturally engrained it is for us not to collaborate with each other.    (MN2)

In my opinion, strong design is much more powerful than strong facilitation, and those were principles I hoped would emerge when comparing Team Wiki and Team Taylor’s processes with Team Nike’s. Two design constraints all three teams shared were a concrete goal and a time constraint. Nothing motivates a group to collaborate more effectively than a sense of urgency, and both of these constraints help to create that urgency. One of the most important elements of Blue Oxen‘s definition of collaboration is the notion that the goal is bounded — that it has both a beginning and an end. If there’s an end, then the goal is measurable, and you can have a time constraint. None of the teams identified this in their definitions of collaboration, although I’d be willing to bet that it would have emerged if we had more time.    (MN3)

Another useful design constraint is the power of small groups. Conversation flowed better within both Team Wiki and Team Taylor, and that flow carried over when Team Taylor got together as a large group. It’s a simple principle, and yet it’s also vastly underutilized.    (MN4)

Besides being broken into small groups, Team Wiki’s major design constraint was the use of a Shared Display as a medium for both creating their deliverable and communicating between the group. My goal was to simulate a Wiki-like collaborative pattern in a very short timespan. Given my well-known love of Wikis, I enjoyed watching this group the most. The content itself evolved predictably in a way that was reminiscent of Wikis, starting with a straw man of content, some side conversations in the document itself, and plenty of refactoring. The group dynamic, however, was anything but predictable. One group went directly to the laptop and started working. Another group saw this, realized only one group could type at a time, and decided that it would spend most of its time talking amongst themselves. Throughout the half hour, two groups regular switched off on the laptop while the third group didn’t participate until the very end. The last few minutes was mostly frantic typing while everyone else stood around and watched.    (MN5)

Several people noted the challenge of having only a single keyboard, and expressed curiosity about the possibility of having multiple people work simultaneously. We could have accomplished that a number of ways, the best of which would have been to use a real-time collaborative editor such as Gobby or SynchroEdit. However, the point of this exercise was to simulate asysnchronous collaboration. I think this was an exercise that would have benefited from a bit more time.    (MN6)

Two interesting things emerged from Team Taylor, one which I expected and one which I didn’t even notice until the team itself pointed it out. At one point, the team observed that two people were monopolizing the conversation, and that they were both men, even though the majority of the group comprised of women. This observation was complicated by the fact that the observation team — in this case, all men — were sitting with the group in a circle rather than outside of the group. As a result, it was hard to say whether this was indeed a gender dynamic, or whether the two who spoke the most just happened to be the biggest talkers in the group. Nevertheless, the awareness of the gender dynamic was an important one that a lot of facilitators — especially males — miss.    (MN7)

Team Taylor didn’t do a particularly good job at the stated exercise, but one participant observed that if they had five more minutes, they would have done an amazing job. I believe this, and I think the resulting definition would have scored the highest on the Squirm Test. The reason for that was that their process was optimized for building Shared Language and trust. The personal storytelling was especially important for trust-building. When you have both of these in great amounts, the actual collaboration is far more effective. Truthfully, they were also hamstrung by the fact that I didn’t tell them what their actual goal was until the final ten minutes of their exercise. That would have been an appropriate thing to do if they had much more time, but given the time constraints, it probably would have been more fair to tell them the exercise ahead of time. I agonized over this when designing the exercise, and I chose not to tell them the exercise in advance because I was afraid the urgency of the deadline might cause them to skip through the first two exercises.    (MN8)

Finally, a word on the actual definitions. I wasn’t expecting to be blown away by any of the definitions, again largely due to the time constraints. I was more interested in the group learning. However, I thought all three definitions were pretty good, and I was impressed by the context and the patterns that emerged: the importance of trust, communication, and Shared Language, for example. I also saw something that I’ve seen with other folks and with other definitions. Everyone tried to define “effective collaboration,” when in fact, the exercise called for simply defining “collaboration.” I think it helps to separate the two. Ineffective collaboration is still collaboration. There is something cognitively liberating about separating the question of whether or not you are collaborating from whether or not you are collaborating effectively.    (MN9)

I was very impressed by the quality of the group, and I had a blast working with them. I recommend folks interested in learning more about collaboration, systems thinking, and leadership in a business context to check out the Presidio School program, and in particular, to take a look at the various classes that the Laszlos teach.    (MNA)

Being Ambushed by Terrell Russell

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

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)

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)