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)

http://farm2.static.flickr.com/1390/1424241488_9de86fefbb_m.jpg http://farm2.static.flickr.com/1142/1423359835_cad0b5609b_m.jpg    (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)

“Learning Community” Words

Deborah Meehan led the Leadership Learning Community‘s board through a quick exercise today that was partially inspired by Gail Taylor‘s “love” experiment. She read us a quote from last year’s Creating Space conference, then asked us to write down five words we think of when we hear the words “Learning Community.” We each wrote our word phrases on Post-It notes, then proceeded to cluster our words on a large surface.    (M6L)

http://farm1.static.flickr.com/176/454816833_a28778125d_m.jpg    (M6M)

There were 12 of us participating, which resulted in a total of 62 word phrases. (I split two Post-It notes into two word phrases. One was separated by a slash, the other by “and.”) Out of those 62 word phrases, 10 were used more than once. They were (in order of frequency):    (M6N)

You can see a cloud visualization of the words we chose.    (M6Y)

Some observations:    (M6Z)

  • Only one person (me) wrote, “learning.” Only two people wrote “community.” That could have been because people assumed that they could not use those two words.    (M70)
  • No one wrote “teaching.”    (M71)
  • The value of the clustering versus the cloud visualization is interesting. The clustering exercise (which is similar to an Affinity Diagram in the usability world) is an exercise in semantic convergence. All the cloud view does is match words, character-by-character. Both tell you different things. Both are valuable.    (M72)

If we were to do this exercise again, it would be interesting to do 10 rather than five words. I think there would be more overlap in that case, although the beauty of this exercise is, one never knows. And it would be interesting to do this exercise again with the same group of people six months from now to see if the results are different.    (M73)

The Banana Hoarding Problem

I spent a good portion of this weekend listening to (and laughing at) my friends, Andrew and Elene, who are having a little problem at work. They both work at a large Silicon Valley company that has fresh fruit delivered each week — apples, oranges, and green bananas. Each week, the bananas disappear right away. Why? Because people hoard a week’s worth of bananas at their cubicles, rather than taking only what they’re going to eat right away.    (LXI)

What should my friends do? Here were some answers I and others came up with:    (LXJ)

  • They should hoard bananas for themselves.    (LXK)
  • They should take bananas from one of the hoarders.    (LXL)
  • They should bring their own bananas.    (LXM)
  • The company should order more bananas.    (LXN)
  • The company should appoint a banana distribution manager.    (LXO)
  • They should hoard all the bananas themselves, and become the de facto banana distribution managers.    (LXP)
  • The company should hire an old person to stand in the kitchen at all times, a la Wal-Mart. This will shame people from hoarding.    (LXQ)
  • They should poison one bunch of bananas, then put up a sign saying that one bunch is poisoned without indicating which one.    (LXR)

What would you do? Blog (and link here) or tell me your answers.    (LXS)

Not only was it incredibly funny to see how dismayed my friends were (what can I say, I’m a sadist?), but it was actually interesting to think through the problem. It’s a real-life instance of the Prisoner’s Dilemma, a classic cooperation (but not necessarily collaboration) problem.    (LXT)

At the St. Louis Collaboratory workshop last October, we spent the day working on the Iterated Prisoners Dilemma, appropriate since the workshop was held in a former police station. It was fascinating to watch people work through the problem. I’ve been sitting on a pile of notes about it for months now, and this latest real-world dilemma may motivate me to sort through them and blog about it.    (LXU)

Update    (LY4)

Clearly, the Banana Hoarding Problem is more widespread than I originally thought, as the empathy and some possible solutions are already starting to come in. Once again, we see the Wisdom of Crowds at work (or not).    (LY5)

Keep your answers coming!    (LY8)

Talking Technology

Todd Johnston posted an outstanding summary of our informal session this past Saturday. He mentioned our first exercise, which was to have Todd, Gail Taylor, and Tiffany Von Emmel explain how email worked to Matthew O’Connor and myself, who had had sudden bouts of amnesia. Todd wrote, “This exercise, as you may imagine, did a lot to uncover assumptions, vantage points and metaphors we use to shape our understanding.”    (LX9)

The point of the exercise was two-fold. First, we wanted the group to have a better understanding of how the Internet worked. Second, rather than tell them how it worked, we wanted them to figure it out by thinking through the problem. Most of us have the mental tools to understand technology; we just choose not to use them. We wanted to get them to use them.    (LXA)

What was interesting about the exercise was that they did an excellent job of drawing a basic conceptual picture. However, when Matthew and I started asking probing questions to help fill in the gaps, they abandoned their mental models and started reverting to buzzwords. They mentioned things like packets and algorithms and server farms, all of which demonstrated knowledge of Internet lingo, but none of which was necessary to explain how email worked.    (LXB)

Matthew pointed out that techies often do the same thing. When confronted with basic questions about technology, they often start throwing around concepts and language that aren’t critical to the core question. In these cases, they do this because they’re unaware of the other party’s mental models and are feeling around for context.    (LXC)

Why would non-techies do the same thing? In this particular case, it was for the exact same reason. Even though Matthew and I were playing dumb, they knew that we knew the answers. When we started asking questions, they abandoned their model and started feeling around for the answers we might be looking for, hence the lingo.    (LXD)

When one person has knowledge that the other person doesn’t have, that often results in a power relationship, and power relationships affect how people behave. What makes this relationship dangerous is when people assume that this knowledge is somehow sacred and unattainable. Many non-technical people are guilty of this. It’s evident when people preface their statements, “I’m not a techie,” as if that makes them incapable of understanding technology. It’s an attitude problem that stems from fear.    (LXE)

The important thing is that everyone is capable of understanding technology. Don’t let those supposedly in the know bully you away from being confident in what you understand and what you don’t understand.    (LXF)

On a separate note, Todd also describes Finding Your Hey, an exercise that the band, Phish often performs. Todd first told me this story two years ago, and I dutifully blogged about it, but I didn’t know what it was called, and I didn’t know the exact quote. It’s a wonderful story.    (LXG)

Relay Racing Synergy

The informal gathering this past Saturday was the result of conversations that Gail Taylor and I have been having for some time about the synergies between process and digital technology. (The “digital” distinction is important. “Process,” in our world, is just another “technology.”)    (LX6)

Gail recently posted her vision of what we’re trying to do. I especially liked this story:    (LX7)

As a relay racer in a much earlier life, I studied the passing of the baton. When we were “magic” we neither passed or received as separate events. Rather, something more happened… a synergy that I cannot describe.    (LX8)