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)

Networked Tools and the Email Bottleneck

My friend and colleague, Tony Christopher, recently wrote a wonderful paper entitled, “Tools for Teams: Beyond the Email Bottleneck.” There are two things I really like about the paper, and there’s one thing I want to nitpick here.    (MDS)

First, the good stuff. Tony introduces a new term, “networked tools,” to connote tools that are on the network. These include shared calendars, file repositories, and so forth. Why is this useful? For starters, most people have no idea what a collaborative tool is, and that includes many folks who are ostensibly in the business.    (MDT)

What is a collaborative tool? It’s a tool that facilitates collaboration. Certainly, a shared authoring tool like a Wiki has affordances that facilitate collaboration. But a plain old text editor is just as legitimately a collaboration tool, because it can also be used to facilitate collaboration (for example, when used on a Shared Display).    (MDU)

When most people talk about collaborative tools, what they’re really talking about are networked tools, which is why I think Tony’s term is much more apt.    (MDV)

The main point of Tony’s paper is not to invent a new term, but to shift the focus away from the tool and onto an organization’s needs and processes. His specific advice is a bit oriented towards larger organizations, but the essence of his argument is true for everyone.    (MDW)

My only nitpick with Tony’s paper is that he chooses to pick on email, a favorite practice of another person I like to nitpick on this point, Ross Mayfield. (In fairness to Ross, he’s clearly being a troublemaker — or a good CEO — when he declares email dead, as he’s also written clearly about using email effectively in the context of collaboration. And he’s spot on about occupational spam.) Tony writes:    (MDX)

Email undermines the centralized accumulation of knowledge that could benefit the organization both during the project and long after it’s over. Organizations that have not evolved from email to a broader set of networked tools face lost oportunities and hidden costs.    (MDY)

It’s a bit of a red herring to blame email, because email is a Swiss Army knife. You can do a bunch of things with it, but you’ve got to figure out how to take advantage of this flexibility. This is even more difficult with groups, because if some folks are using their email differently from others, its effectiveness as a collaboration tool drops.    (MDZ)

I suspect that most organizations would see orders of magnitude improvements in how they collaborated if they went through the steps that Tony suggested, then reexamined how they could use email more effectively.    (ME0)

A very simple example of what I mean came out of a conversation with Tara Hunt earlier this week. I was talking to Tara and Chris Messina about their work to move the Freecycle community to something more appropriate to their needs. I observed that while Freecycle could definitely use a better support tool, it’s a great example of how you can leverage a simple mailing list to do amazing collaborative work.    (ME1)

Tara noted that there are 3.5 million people currently on Freecycle, which is amazing. She also observed, “Imagine how many people they would have if the tool were better.” A fair point indeed. When you’ve thought carefully about your patterns and you’ve reached the limit of your tools, the next step for coevolution is to improve your tools. Freecycle — currently serving 3.5 million people effectively — is definitely at that point. Most organizations are not.    (ME2)

pageoftext.com

Gordon McCreight showed off his latest silly creation, pageoftext.com, at the last WikiWednesday. It’s a silly concept, and it’s got a silly lack of features. What’s really silly is how useful this silly little concept is. It’s considerably simpler than Writeboard, slightly more featureful than the various Pastebins, and better than both.    (M4D)

pageoftext.com is a collaborative text editor on laxatives. All features you might think you need have been flushed away to oblivion. There’s no formatting, no registration, and no security. Editing happens in plain text. The URLs are human-friendly, which is good, because you’ll need to remember them if you ever want to find them again. Gordon does have a remind feature, in which you describe what’s on the page, and then he tries to find it for you.    (M4E)

It’s great for when a bunch of people — especially normal people — need to edit a file together quickly and easily. You don’t have to go through the normal hullabaloo of logging in, because you don’t have to login. You don’t have to describe the markup, because there is no markup. It’s totally task-focused.    (M4F)

This, in theory, is what Writeboard was supposed to be, except I think it’s a whole lot better. When I use Writeboard, I’m constantly reminded of what it’s not, as opposed to being excited over what it is. Writeboards are no easier than a Wiki to use, but they’re much less useful.    (M4G)

I love pastebin (known as nopaste in some circles) for a lot of reasons. Pastebin emerged because developers collaborating on IRC needed a Shared Display. It’s brain-dead simple, and it does exactly what it’s supposed to do. pageoftext.com addresses a different goal than pastebin, but it has similar affordances, and could be used the same way.    (M4H)

Gordon has been militant about feature creep, which is a good thing. That said, I started a page suggesting new features. Feel free to add those there. Or, if you prefer not to think about such esoteric things, you can add some Philadelphia-area restaurants and reviews to my Philly restaurants page. (I’m visiting Philly for the first time next weekend, and I need some good cheesesteak recommendations.)    (M4I)

Recent Dialog Mapping Lessons

On the HyperScope mailing list, Jeff Conklin recently asked how we were using Compendium for the project. We’ve been using it for the design phase of the project, walking through scenarios, capturing requirements, and developing specifications. I started the process by developing a template for the project — loosely based on previous projects — and by seeding the map with content from asynchronous sources.    (KFU)

I first presented the map at our weekly face-to-face meeting two weeks ago, and it’s continued to be the centerpiece for our discussions ever since. Other than the initial seeding and nightly refactoring, all of the content was generated during these group meetings. After each refactoring, I would post new versions of the map to the web.    (KFV)

Now that we’ve basically completed the scoping process, I’m going to convert the map into a design document (on Augment!). Compendium isn’t scheduled to make a reappearance at our meetings anytime soon, but you can be sure that if the need arises, I won’t hesitate to break it out.    (KFW)

A few years ago, I published a case study on Dialogue Mapping that described my early work in this area. I’ve continued to apply a lot of the lessons learned from those very early experiences. Here are some standbyes:    (KFX)

  • Take breaks    (KFY)
  • Avoid Yes No Questions    (KFZ)
  • Multiple maps are your friend. When a map grows too large, (take a break and) make a new one.    (KG0)
  • The map should be another participant in the meeting. The physical location of the map is critical to its success.    (KG1)

Here are some new and old thoughts on Dialogue Mapping based on my most recent experience:    (KG2)

  • The fact that so many early lessons are still relevant should be further encouragement for people to give Dialogue Mapping a try. The first few times I did it, it was hard. Once I took those first lumps, however, I shifted into an expert usage very quickly. Once you’ve gained this experience, the tool is invaluable.    (KG3)
  • In that early paper, an observation I made without comment was that I rarely used Argument nodes (Pros and Cons) in my early maps. Over the past five years of using Compendium, that pattern has held true. However, when I have used Arguments, they tend to be Pros rather than Cons. With the HyperScope map, I used Cons much more frequently. This reflects the circumstances of the project. We’re replicating an existing implementation that all of us agree is fantastic. We also have a very tight schedule. Most of our discussions have centered around implementation difficulty and desired constraints, and so naturally, things tend to be framed as Cons.    (KG4)
  • I think that a low percentage of Argument nodes in a map indicates expert usage. In meetings, Arguments are often a reflection of group politics rather than of logic. Reframing Arguments as Questions and Ideas depoliticizes the discussion.    (KG5)
  • When I first start using Compendium with a group, I never explain the tool. I just use it. People find it very natural to follow (assuming you’ve positioned your Shared Display properly), and they often take ownership of the map very quickly. The one thing I do find myself explaining on occasion is that an Idea is just an Idea. It is not a decision, and its presence indicates no value other than that someone in the group proposed it (which is not to be underestimated).    (KG6)
  • You know the process and tool are working when participants start saying, “Make sure you capture that,” or, “Can you put that there?” It’s a sign that they consider the map a participant and that they are taking ownership over its content. It also makes the facilitator’s job easier.    (KG7)
  • The resulting map is an artifact of the discussion, and as such, it’s more useful for participants than it is for nonparticipants. Folks like the fact that the maps are available, but they don’t recognize the value until I walk through the map with them. More importantly, those who have participated in the meetings (and hence, the map’s development) have found it extremely useful.    (KG8)

Here are some new and old thoughts on Compendium, the tool:    (KG9)

  • Compendium calls Idea nodes “Answers.” I understand the logic behind this, but I think “Idea” is a superior framing. This is partially captured by the fact that the node is represented by a light bulb, but I’d still like to see the name changed back to “Ideas.”    (KGA)
  • I used Decision nodes a lot for this project, which was natural, since this was a scoping exercise. I also made a big show every time I created a Decision node. This shifted us away from discussion mode, which may sound obvious, but it had a powerful effect on group participation. It was a group acknowledgement that we had captured the relevant issues and that we were ready to move on.    (KGB)
  • After the last Compendium workshop, I resolved to add some Visual Modeling techniques to my Compendium usage. I’ve managed to incorporate it a bit in other projects, but it hasn’t been useful at all for this project. I love the idea, but Compendium isn’t optimized enough for this kind of usage for me.    (KGC)
  • Compendium still has some subtle but annoying bugs, mostly related to layout. Michelle Bachler has done a great job of stabilizing and improving the code, but the project could definitely use more development resources.    (KGD)
  • My number one most desired feature: A slider bar that cycles through previous versions of your map. It should work with exported maps too.    (KGE)
  • Speaking of exports, using Compendium to work on the HyperScope really emphasizes the utility of things like granular addressability and applying viewspecs on a single document, features that don’t currently exist in exported maps.    (KGF)

Community Engagement and Dynamic Knowledge Repositories

One of the benefits of working on the Hyperscope is not just working closely with Doug Engelbart, but also with many of his long-time colleagues, not the least of whom includes Christina Engelbart, his daughter and former business partner. Christina and I recently had an off-the-cuff exchange on community engagement and maintaining a Dynamic Knowledge Repository (DKR), and it’s started to evolve into a full-fledged discussion. Rather than continue it over email, I thought I’d post some of my thoughts here, especially since they relate to my recent post on Leave A Trail and stigmergy.    (KDW)

On the surface, maintaining a Dynamic Knowledge Repository and community engagement would seem to be two separate actions. Christina suggests that the former is a more tangible entity, whereas the latter is a process. I agree with this distinction, and I would also note that the artifacts of community engagement are part of a DKR. So you’ve got the engagement itself (process), and you’ve got the artifacts of the engagement (part of a DKR).    (KDX)

The distinction starts to blur when the engagement occurs over a digital medium. If I exchange email with someone, then is that community engagement or is it part of maintaining a Dynamic Knowledge Repository? It’s both, because the act of engagement also results in an artifact!    (KDY)

Why is this important? Because when we think of the two as distinct actions, then doing both means double the work. When we think of the two as having significant overlap (via relatively minor shifts in work practice), then we get (at least) twice the benefit for half as much work.    (KDZ)

This conflation is central to methodologies like Dialogue Mapping. Jeff Conklin talks about the importance of Shared Display as being part of the conversation. When the screen is physically part of the conversation, then participants engage with the screen as if it were another participant. That creates shared ownership over the artifact, which makes the artifact far more valuable than a meeting summary that some guy in the corner scribbled onto his laptop and emailed out afterwards.    (KE0)

The benefits multiply even more when you take into account Leave A Trail and scale. Having a closed DKR for a small team is valuable, but opening that DKR up for the entire world to see increases the potential for serendipity and emergence.    (KE1)

I would argue very strongly for folks to think about community engagement and maintaining a knowledge repository as part of the same bucket, because they should be very closely tied to each other. For example, when I add content or refactor the public Hyperscope Wiki, I consider that part of my community engagement strategy. That said, these two concepts are not identical. This is important to remember also. Simply dumping information into a public repository is not a very effective community engagement strategy. However, proactively reaching out to people and encouraging them to interact in the public repository is a great community engagement strategy.    (KE2)

Jeff’s framing is probably the best way to think about it: Your knowledge repository should be thought of as a participant in your collaborative process, not just something external.    (KE3)