What is Collective Leadership?

Posted on Published by Eugene Eric Kim

One of the reasons I joined the board of the Leadership Learning Community (LLC) is that leadership and collaboration are closely related. But what exactly is the nature of this relationship? That is a question I’ve dutifully ignored for the past four years. Thankfully, the good folks at the LLC have unwittingly encouraged me to get off my lazy butt and think a little bit deeper about this question. Much of our discussion at the Evaluation Learning Circle last month was about Collective Leadership, which is also the theme for the upcoming Creating Space gathering. What the heck is “Collective Leadership“? I’ll try my hand at that one too, but first things first.    (LTZ)

On Leadership    (LU0)

What does it mean to lead? When I think about the word, I envision movement in some direction. It could be shared movement among a group of people, or it could be individual movement (e.g. how you lead your life”). If it’s shared movement towards a bounded goal, then by definition, it’s collaboration.    (LU1)

There are many ways you can create shared movement. You could describe a vision, and encourage people to get there anyway they can. You could start moving in that direction yourself, and hope that others follow your example. Or you could pull people along, kicking and screaming. All of these are forms of leadership.    (LU2)

The word, “leader,” implies the existence of a “follower,” which suggests a power relationship. However, leadership is a role, not a title. Roles can be shared, and they can be reversed, depending on the context. They can be pre-assigned, and they can emerge.    (LU3)

People often assume that collaboration implies shared leadership. This is incorrect. Take dancing. Dancing almost always necessitates a single leader. The only exception I know of is contact improvisation (first explained to me by Brad Neuberg), although I welcome other counterexamples from people who actually know how to dance.    (LU4)

The single leader is a pattern in many fields. In cooking, for example, there is almost always one executive chef. The word “chef” is French for “chief.” In music, there is almost always a single leader. Orchestras have conductors, string quartets have first violinists. Even in jazz ensembles, someone always leads, and everyone else riffs off that person.    (LU5)

In rowing, you have the coxswain, who is responsible for navigating the boat and keeping the rowers in sync. Even though the coxswain does not physically contribute to the movement of the boat, the coxswain always trains with the rest of the rowers. Why? Trust and respect. If the coxswain did not participate in the training, the rest of the crew would not accept him or her as a member of the team, much less the leader.    (LU6)

On Collective Leadership    (LU7)

What about driving? Would you want multiple people driving a car at the same time? I sure as heck wouldn’t.    (LU8)

Is the driver a leader? To the extent that he or she is moving the passengers in some shared direction, absolutely. But the driver is not necessarily the only person determining where to go. Who decided on the destination? Who is telling the driver how to get there?    (LU9)

All of these roles are legitimate leadership roles, and some of these could very well be shared among multiple people. Are they better when shared? That depends.    (LUA)

There are two factors that help us think through this question. The first is the boundedness of the goal. When you must achieve your goal very quickly, you don’t necessarily have time to gain consensus on an issue. In these situations, having a single leader can be more efficient.    (LUB)

The second factor is the wickedness of the problem. When Jeff Conklin describes Wicked Problems, he often shows people this chart:    (LUC)

https://i0.wp.com/www.cognexus.org/4660c8d0.gif?w=700    (LUD)

In the collaborative design process, there are people who ponder the problem first, and there are people who immediately dive into the solution. Neither is wrong. In fact, when problems are so complex (wicked), you don’t even know what the exact problem is, then you need to attack the problem both ways. Our traditional notion of efficiency is no longer an option. Because we need to attack these kinds of problems in multiple ways, there are multiple opportunities for leadership. More importantly, there must be a shared vision for the end state, even if the path for reaching that end state is not universally shared.    (LUE)

For more thoughts on Collective Leadership, see my post, “Dumbells and Collective Intelligence.”    (LUF)

Recent Dialog Mapping Lessons

Posted on Published by Eugene Eric Kim

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

Posted on Published by Eugene Eric Kim

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)

Tonight: Jeff Conklin on Dialog Mapping

Posted on Published by Eugene Eric Kim

Update: Unfortunately, Jeff cannot make it tonight due to flooding near his home. We’ll reschedule him for another time, and I’ll post the new date here.    (K9T)

Jeff Conklin, facilitator extraordinaire and inventor of gIBIS and Dialogue Mapping, will be giving a talk tonight for the SDForum Collaboration SIG in Palo Alto, 6:30-9pm. Be there! Jeff is an awesome speaker, and — as with all of our events — there will be a great interactive session, where you’ll get to experience Dialogue Mapping first-hand.    (K9Q)

Also, podcast from last month’s meeting, “How Hackers Collaborate,” is now available. See Scott McMullan‘s commentary on the event (and another event I co-organized, “Tools for Catalyzing Collaboration,”, which I’ll blog about soon).    (K9R)