Networks and Enrollment

Los Angeles Union Station

I spent this past Wednesday with some of my favorite colleagues talking about networks and social change. Garfield Foundation had brought us together to surface our collective mental models about networks and to see where they overlapped and where they diverged. The day was rife with wonderful twists on familiar topics, and I learned a tremendous amount exploring different nuances with the others.

One of the important themes that emerged was enrollment. The classic careless way to approach design is to say, “Let’s just get everybody into a room together and see what happens!” There’s an element of openness here that should be encouraged, but beyond that, this approach is likelier to create more problems than solve them. It’s critical to think through the following questions:

  • Whom do you want to engage in your process?
  • How do you enroll them?
  • At what stage do you enroll them?
  • How do you want them to engage with each other?

Taj James shared a wonderful metaphor for how to think about enrollment: Picking people up at the train station. Do you want to pick people up at the first stop? The second stop? The third? What would happen if you had picked up the people from the third stop at the first stop instead? What if you want to pick up a group of people at the first stop, but they’re not ready to travel? Maybe they’re not packed yet, or maybe they don’t want to travel with people they don’t really know.

Here are three examples of how I dealt with issues of enrollment in previous projects:

Wikimedia Strategic Planning

The purpose of the Wikimedia Strategic Planning process (2009-2010) was to build a movement-wide set of priorities through a bottoms-up process. We had to navigate around two conceptual myths:

  • “We have to work in small, closed groups before we can open up the process. Otherwise, it will be too chaotic, and we’ll never get anything done.”
  • “Once we have something to show people, we’ll put it out there, and thousands of volunteers will magically start working on it.”

The first myth is a common one. It is easier to get things done and build relationships when working with small groups. But should the first stage of a process like this be about “getting things done”? Who gets to be part of that initial small group, and what will be the impact of the people you leave behind at that first station? Also, is “closed” truly a prerequisite for working in small groups?

When I came on board, the team had already drafted a plan that did not open up the process until three or four months into a 12-month process. I immediately changed that, and two weeks later, we were engaging with the community in an open, large-scale way. My reasoning was this:

  • The end goal was co-creation and broad-scale ownership of the strategy. If you don’t give people the opportunity to get on board early, then it won’t be co-creation.
  • Even if you gave people the opportunity to get on board, why would they? Wikipedians are overwhelmingly young (in their teens and 20s, many of them students). Most of them had never heard of strategic planning, much less participated in a planning process. Many of them didn’t even know what the Wikimedia Foundation was or that it even existed. They were there because they liked writing carefully crafted, thoughtfully researched articles about areas of interest. Why would they spend time participating in a strategy process?
  • We already had a small group of people who were committed to working on strategy, and we had some norms and relationships in place. Given that core, I was confident in my ability to open up participation while maintaining a high-level of productivity.

We engaged our core community immediately around questions that mattered to them, and we listened. The initial question we asked was, “If you had the opportunity to change anything, what would you change, and why?” The “why” question pushed people to start thinking strategically, because it forced them to connect tactics to purpose. It helped everybody — not just us — understand what people were seeing and thinking, and it also surfaced people who were already thoughtful and engaged whom we could more actively target in later stages of the project. Because it was many-to-many conversation as a opposed to something like a survey, people were building relationships with each other while they worked through these questions.

We also continued doing our preparation work, but we did it openly, inviting others to jump in and participate. The deluge of distracting volunteers that people feared never came. Instead, the people who did come helped shape and improve the work that we were doing, and many of them became critical leaders later in the process.

Delta Dialogues

With the Delta Dialogues (2012 and still continuing without me), we were dealing with the wickedest of problems: California water issues. One of the ongoing dynamics was the lack of inclusion in existing planning processes. People involved in planning feared disruption, and so they would either exclude stakeholders from early stages of the process, or they would try to control their participation through a set of discouraging ground rules. That simply reinforced the rampant mistrust that already existed in the region, especially when the resulting plans felt one-sided, which made those stakeholders even more disruptive. It was a self-fulfilling prophecy.

We originally proposed a joint small-group / large-scale engagement process, but for a variety of reasons, we ended up focusing on a small, representative group of stakeholders. It was a network leadership play. Our goal was not to “get things done.” That approach wasn’t working, because people were not taking the time to listen and understand to each other. Our primary goal was shared understanding.

Once again, our biggest challenge was going to be enrollment. There was severe planning fatigue in the region, and the people we were targeting were extremely busy. The exact timing (beyond our control) was even more challenging, because it came in the heart of harvest season, when farmers in the region were literally working around the clock, seven days a week. How were we going to get people into the room? How could we keep them coming back?

We played a number of cards:

  • We focused on people, not just organizations. People didn’t really know much about our organizational client, the Delta Conservancy. But everybody knew, liked, and trusted its Executive Director, Campbell Ingram. People came the first few times because of their relationship to him. It was our responsibility at that point to keep them coming. If he had not already been such a trusted network weaver, we probably could not have gotten this process off the ground.
  • We bet that participants would buy into the goal of shared understanding versus something like planning.
  • We invested a considerable amount of time creating a space that was safe, inviting, and transparent. Instead of hosting the conversations in a “neutral space,” we rotated locations among the stakeholders. That deepened empathy and relationships, because people were not only talking to each other, they were immersed in each other’s worlds. It was also far more inviting to spend a day on a farm or in a nature preserve than it was to be stuck in an office building.
  • We thought explicitly about people we wanted to bring on board at future stations, and we tried to set the stage for that. We produced artifacts that people could easily share outside of meetings, all centrally located at a public website that anyone could point to. We assigned each other buddies, and we encouraged people to talk to their buddies between meetings. We also had a leadership development component to encourage people to have these same kinds of conversations outside of our process. (This part of our process wasn’t working, and we quickly scrapped it. We were trying to do too much.)

Our ongoing challenge was making sure people kept coming back. And, at each meeting, people would consistently say that they had felt swamped and had considered skipping, but that they were glad they came and that this was their favorite time of the week.

Organizational Change Initiatives

I don’t really differentiate an “organizational approach” from a “network approach” in my mind, because an organization is simply a type of network, and the same principles apply. I’ve been in a few large-scale organizational change efforts, and enrollment was always a huge, sometimes overlooked challenge. People don’t necessarily think this is the case, because if you’re working with C-level leadership, they can essentially “force” people to “participate.” The power dynamic here is similar to what many foundations experience. They can easily get people into a room. However, getting people into a room is not the same as enrollment.

Many organizational consultants make  two mistakes in their processes. First, they spend all of their time with leadership, which simply reinforces both a narrow perspective as well as a power dynamic that gets in the way of broad participation. Second, they focus entirely on the meetings. Again, you can leverage power dynamics to get people to a meeting, but your success depends on what people do outside of those meetings.

I always apply the same principles of participatory processes to my organizational work, and I invest just as much time building relationships with people at all levels of the organization. Those leaders are critical in getting other people on board at future stops.

Groupaya

A web site for a new company called Groupaya quietly cropped up last week. If you read the first blog post, you’ll see that I founded it with Kristin Cobble, and that Rebecca Petzel is part of our little cohort. I did a bit of explaining over there, and I’ll be doing much more over the coming weeks. What I’d like to do here is tell a more personal story about why Groupaya came to be and what it means for me moving forward.

Leading Change

2010 was a great and a challenging year for me professionally. My professional reputation had crossed some threshold where I had a steady stream of projects coming in, and the projects were getting bigger, harder, and more meaningful. I was also dissatisfied and completely burnt-out.

Blue Oxen Associates should have failed back in 2003, shortly after I had started it. We had no clients, a misguided strategy, and lots of debt. My cofounder had just left the company, and I felt very alone. We survived because of faith (both in ourselves and from others), because we worked like the dickens, and because we were very, very lucky. That survival process is a great teacher, but it comes at a personal cost, and if you’re not careful, you never heal.

As well as things were going in 2010, I wanted more. I was getting work opportunities, but I didn’t feel like I was fully empowered. I had big ideas about possibilities, and I was gradually moving toward those, but it was too slow, and I was exhausted from seven years of scrapping.

So I started creating space for myself so that I could think about what I really wanted and what I could do to get there. It was the healing process that I had put off for years. As I got clarity, I created new structures for myself, and the cycle of healing and clarity reinforced itself. One thing became very apparent very quickly: I was ready for a big change. I just didn’t know what that change should be.

That’s when beautiful, reliable serendipity took over.

Courage and Vision

In 2009, Pete Leyden, a journalist and entrepreneur who had been one of the founders of Wired, was returning to San Francisco after a stint in D.C. as director of New Politics Institute. He had this brilliant, wildly ambitious idea of combining the best of Silicon Valley and the web with a more traditional think tank as a way of revolutionizing public policy. He called his new company Next Agenda.

Part of his vision entailed bringing the best tools and processes for both face-to-face and online collaboration into a single, coherent practice. He started recruiting a team to help him make this happen. Henry Poole, one of Blue Oxen’s advisors, suggested that he talk to me.

Through his friend and former colleague, Katherine Fulton, president of the Monitor Institute, Pete also discovered Kristin Cobble. Kristin was an organizational and leadership development superstar. She had started her career at Innovation Associates (Peter Senge‘s consulting firm), and she had served as the Director of Strategic Change at Banana Republic.

Several years ago, Kristin had started to formulate a vision of a large-scale, participatory process that would empower the people in this country to take ownership of our future. When Pete discovered her, she had just left Monitor Group to try and make this vision a reality. She called her new company, “Courion Group,” where “Courion” was a combination of “courage” and “vision,” values that she herself embodies.

I immediately bonded with Kristin. We shared strong values around group process and the future of the world, and we brought complementary lenses and experiences to our work. Plus, I simply admired the heck out of her abilities. She is a tremendously skilled coach, designer, and facilitator, and she has the ability to think through complex, systemic challenges quickly and deeply.

We spent a lot of time outside of Next Agenda talking about our respective philosophies around collaboration, coming to a much deeper shared understanding in the process. Kristin also became a valued friend and advisor, and I started leaning on her as I worked through my professional angst.

New Life

By April 2010, I was 99 percent sure that I would shut down Blue Oxen and pursue new opportunities, most likely at someone else’s organization. I was exhausted, I needed a break, and frankly, I was curious to know what sort of opportunities were out there. Then I got an unexpected email.

My friend, Scott McMullan, is responsible for partnerships for Google Apps. One of his customers (let’s call him “Harry”), then a CIO at a Fortune 500 company, wanted to explore an initiative for improving collaboration across his organization. It was a very big, very vague idea, and he was looking for a non-traditional thinking partner who understood collaboration deeply and who wasn’t afraid to play and take risks. Harry asked Scott if he knew anyone, and Scott generously mentioned me.

So Harry sent me an email. One energizing conversation later, I realized something about myself: As tired as I was, I still felt passionate about my work and my path. All it took was the right conversation with the right person to get excited again.

I knew that Harry was talking to other larger, more reputable firms. I also knew that we could do a better job than any of those firms. So I started putting together a team and a plan.

This was also an opportunity to start testing some of my structural changes. One of those was a requirement that I bring in a senior partner for all big projects. The first person who came to mind was Kristin, who, to my delight, agreed to join me.

Another change was an intention to create opportunities for people who were less experienced than me, but who were as passionate as I was about collaboration and who were hungry to learn.

I had recently met Rebecca Petzel at a tweet-up organized by Christina Jordan. I was literally on my way out the door when I met Rebecca, but she stuck out for three reasons. First, she had started a cohort in graduate school that called themselves “collaboration ninjas.” Second, she had moved to the Bay Area without a job because she was drawn by the people here and their purpose. Third, when I told her I was a collaboration consultant, she was absolutely delighted. She had no idea that such a job title actually existed!

We had coffee a few times, where I learned more about her work and her drive. In the process of putting together our team, I learned that Rebecca was thinking about transitioning from her job as community catalyst at Myoo Create. I told her about Harry, and I set up a meeting with Kristin. The three of us clicked, and the third member of our team was in place.

Groupaya

Kristin and I filled out the rest of our team from our network of colleagues, we made our pitch, and we got the gig. Thus began the best working experience of my life. We were working on a complex project in a large, global organization with strong leadership support. We had a superstar team in place that kept challenging my thinking and motivating me to work harder. Everyone on the client’s team was smart, great at execution, and simply good people.

Working with Kristin was just really generative. It broadened and deepened my thinking, and it emboldened me to step into my vision. It had a reverberating effect on the rest of my work and even my personal life. I was happier and more productive, and I felt a renewed passion for my work.

In September 2010, we decided to join forces. Rather than ask Kristin to join Blue Oxen Associates, I decided I wanted to create a new organization with her. I’ll explain why in a more detailed post on the Blue Oxen blog, but the short explanation is that I wanted a sense of closure and starting anew.

We’ve spent the better part of a year figuring out what we were going to do together, and we finally signed our partnership agreement last month (September 15, 2011). We’ll be documenting that part of our journey over the next few weeks on the Groupaya blog. It’s a great story, and it involves a lot of important people in our lives. I can’t wait to tell it.

And the journey continues. We’re still getting clear and moving forward, but we wanted to start sharing earlier rather than later. It’s part of our ethos of openness, and it’s also a great way for us to learn with a broader group of people.

In some ways, I feel like I’m getting married after living with someone for a long time. It’s special, but it’s not really new. Kristin and I have been working together for over two years now, we’ve been working with Rebecca for almost a year, and we’ve been operating as if we were already a company since the beginning of the year. That said, we have so much ahead of us, and I’m really excited to be making more and more people a part of this story.

You can follow the ongoing Groupaya saga at our blog, on Twitter (@groupaya), and on Facebook. I’d love to hear what you think!

Straying Off Point

Meeting Best Practices #1 and #2:    (N3K)

  1. Have a goal    (N3L)
  2. Have an agenda    (N3M)

The meeting facilitator’s challenge is to keep the group on point and to finish the meeting on time. That’s where the agenda comes in.    (N3N)

Here’s the problem: What if the agenda is wrong?    (N3O)

We decide to the best of our abilities what the agenda should be, based not only on the goal but on the makeup and state of the group. The latter factor tends to be the trouble-maker. Everyone may agree that the goal of a meeting is to come up with an action plan that everyone stands behind, but what if the people in the room all speak different languages or have different understandings of the problem? You have no chance of creating that action plan without Shared Understanding and Shared Language, and so an agenda focused entirely on making a plan is doomed to failure.    (N3P)

The challenge is knowing your group well enough to make these decisions. That’s why I often say that good design is more crucial to a meeting’s success than good facilitation, because you are tackling these questions before you even step into the meeting.    (N3Q)

What happens if the goal shifts? This happens often when the problem is complex enough. Everyone agrees before the meeting on what the problem is, then in the course of collectively drafting a solution, you suddenly realize that you don’t understand the problem after all. Now the facilitator’s role is critical, because he or she needs to decide whether to stick with the agenda or revise it on the fly.    (N3R)

The reality is that agendas are important, but they need to be fluid. As a facilitator, you need to reserve the right to stray off point if you feel like the situation merits it. This is one reason that I feel so strongly in hiding the agenda, especially with the kind of highly emergent meetings that I usually design. People tend to cling to the agenda like a life-preserver rather than risk swimming into the unknown, which is certainly scarier, but is often necessary. It’s better to trust the facilitator to stay on point and stray off point when the situation merits it.    (N3S)

This is also why I like Dialogue Mapping so much as a facilitation technique. With Dialogue Mapping, the emergent structure of the conversation along with the key underlying questions are explicit and apparent to all of the participants, so that you can effectively leverage the Collective Intelligence of the group rather than rely on the facilitator to be the sole driver.    (N3T)

Tools and Culture

Tools reinforce power relationships. If you want a more emergent power model within a group, you have to make sure your tools support that. Git is a beautiful example of how a tool can support the right power relationships.    (MRK)

However, just because a tool has affordances doesn’t mean people will pay any attention to them. Linus Torvalds alluded to an example in a software development context: Giving everyone commit access to a centralized repository. He refers to this happening in companies, but there’s precedent for it happening in Open Source communities as well. For example, TikiWiki gives commit access to anyone who asks. The underlying philosophy behind this policy is very Wiki-like: Empowering everyone to make things better offsets the risk of giving everyone the opportunity to screw things up. By not imposing a power structure, the right model can emerge.    (MRL)

In the case of git, the tool explicitly supports an emergent power model. In the case of the TikiWiki community, the tool’s inherent model is overridden by the community’s culture.    (MRM)

What can we learn from this? Tools have the potential to transform culture, but transformation never comes easily. In the Wiki community, the classic case of this is when users email an administrator about a typo in a Wiki rather than fixing it themselves. We in the Wiki community use this behavior as a leverage point to explain that they have Permission To Participate and can change the content themselves. Once people start modeling this behavior, transformation becomes a possibility.    (MRN)

When I saw Michael Herman last month, we talked about how tools do and don’t encourage emergent models of behavior and how often we need to catalyze this process by other means. Michael brought up the phenomenon of a few people gathering at a circle of movable chairs, then sitting on opposite sides of each other with many chairs between them rather than moving the chairs they needed into a tighter circle. Even though the environment was adaptable, people chose to go with the default rather than optimize it for their needs.    (MRO)

I saw a similar phenomenon a few weeks ago at TAG, where I sat in on Eugene Chan, Lucy Bernholz, and Suki O’Kane‘s session on Web 2.0 and philanthropy. They had a very interactive design, which in the context of TAG (a very traditional conference format for a very conservative community), was highly unusual. They kicked things off by doing a spectrogram.    (MRP)

https://i1.wp.com/farm3.static.flickr.com/2197/1914433901_f1acf95cf8_m.jpg?w=700    (MRQ)

Not only did this establish a sense of self-awareness and Shared Understanding among the participants, it also got people moving (and laughing), which was especially important since the session was right after lunch. Without saying anything, it was clear that this was not going to be your traditional talking heads session. Smart, smart, smart. Then they led a discussion. They gave people Permission To Participate by explicitly setting expectations, catalyzed the discussion by asking broad questions, then held space and exercised self-restraint whenever there were awkward silences. Again, very nice.    (MRR)

But they also did something dumb. Look at the space:    (MRS)

https://i2.wp.com/farm3.static.flickr.com/2296/1915270732_369c6fa3e3_m.jpg?w=700    (MRT)

Whereas the leaders of the session were saying, “Please talk! Participate! Learn from each other!”, the space was saying, “Look at the leaders! Keep quiet! Check your email while pretending to listen!” And the space was really, really loud, much louder than the leaders.    (MRU)

In fairness to Eugene, Lucy, and Suki, it would have been a major pain in the rear to rearrange the space, and there were strong disincentives to doing so (specifically, the wrath of Lisa Pool). But space makes a huge difference, and even super smart people don’t account for this as much as they should. Even people who are in the business of collaboration and are constantly preaching about this sort of thing (i.e. me) make these mistakes all the time. Old habits and thinking die hard.    (MRV)

The online tool space is rampant with these examples. How often do you see Wikis where the “Edit this page” button is impossible to find?    (MRW)

Tools can encourage or discourage certain types of behavior, and it is in our best interest to choose and adapt our tools to encourage the behavior that we want. That’s not always enough, but it’s generally a good start. Eliminating obstacles can be as much of a catalyst as a good kick in the pants, but a combination of both is even more effective.    (MRX)

Open Source Mergers and the Circle of UNIX

Lloyd Budd wrote a post today entitled, “GPL Encourages Collaboration,” that was highly serendipitous and that triggered a flood of thoughts, some of which I’ll try to capture here. Earlier today, I was rereading an interview I did with Sunir Shah a few months back for a paper I’m writing, and I latched onto a point that Sunir made about the proliferation of Wiki communities:    (MHR)

I see so many people start their own Wikis. They go to these other Wikis that are disorganized. They don’t feel like jumping in and learning everything because everything’s in different places, and they are not coherent. So they start their own.    (MHS)

There are now thousands of public Wikis, and they are all balkanized, because no one wants to collaborate. I understand that. It’s human nature. You collaborate within your group, but you don’t collaborate outside of that group.    (MHT)

On the one hand, I encourage the proliferation of Wikis, because if you disagree with someone, you should be able to do your own thing. On the other hand, true collaboration is showing a willingness to actually pull these communities together, a willingness to subsume your immediate need to be a true leader, build relationships, and pull people together.    (MHU)

Sunir’s insight is an important one. The existence of a commons isn’t in itself enough to guarantee collaboration. Ultimately, collaboration is intentional. You have to want to collaborate with others, and you have to be proactive about it. And it only takes two for starters.    (MHV)

That said, if you want to encourage collaboration, you have to start by eliminating as many barriers as possible. The first barriers are Shared Understanding and Shared Language. In the Open Source community, both of these have been indoctrinated in the form of Open Source licenses. The main reason for the effectiveness of these licenses as vehicles for Shared Understanding is Richard Stallman.    (MHW)

When RMS originally wrote the GPL, he embedded the philosophy behind the terms in the license itself. It was not simply a legal document, but an essay on the principles underlying software freedom. Regardless of how you feel about the GPL or RMS, these remain the fundamental principles behind why Open Source works, and more importantly, why collaboration is so rampant in Open Source communities.    (MHX)

However, as Sunir notes, this isn’t enough to guarantee collaboration. We see a lot of redundancy in Open Source, just as we see lots of redundancy in Wiki communities. And that’s okay. There are sometimes good reasons for this redundancy, and it’s healthy to facilitate it. But eventually, you want convergence also.    (MHY)

This is the crux of Lloyd’s post. He writes, “Forking is good, but not as good as merging.”    (MHZ)

Lloyd also cites a few examples (WordPress, gcc) and asks for others. There are tons of good ones, but my favorite is a bit obscure: UNIX.    (MI0)

That’s right, UNIX. Yes, the history of UNIX is fraught with ugliness, some of which still continues today. But it’s also one of the greatest examples of Open Source forking and merging. This is important, because it’s also the birthplace of the modern Open Source movement.    (MI1)

Here’s the quick summary. UNIX came from AT&T labs, and the original license terms were ambiguous (a massive understatement if there ever was one) for a number of reasons, the main one being that most people weren’t thinking about software as IP at the time. Stallman, of course, was one of the exceptions, and in 1984, he started the GNU project, whose goal was to reimplement UNIX under the GPL.    (MI2)

A few years earlier at UC Berkeley, Bill Joy had taken a different approach. He simply forked AT&T UNIX into what is now known as BSD UNIX. The new code eventually was distributed under the BSD license, which essentially allowed anyone to do whatever they wanted with the code, as long as they gave credit to BSD and didn’t sue anybody. This led to many, many new forks, especially proprietary ones from Sun (cofounded by Joy), IBM, DEC, SGI, and many, many others.    (MI3)

With the advent of the 386 in the late 1980s came a number of PC forks, including 386BSD (which begat FreeBSD, NetBSD, and OpenBSD), BSDI, SCO, and MINIX (which begat Linux). At this point, most versions of UNIX were also borrowing heavily from the GNU project.    (MI4)

By the late 1990s, we started seeing massive convergence. IBM, Sun, DEC (now HP), SGI, and SCO (yes, SCO) all switched over to Linux, and started merging some of their proprietary capabilities into the Linux kernel. Apple moved to FreeBSD.    (MI5)

What the heck happened? You could attribute this phenomenon to market consolidation, but that would only be telling part of the story. Market forces indeed played a strong role, just as they a play a strong role in anything that involves… well, markets. But the important points are these. The ability to fork UNIX into both proprietary and free versions allowed the market to innovate rapidly, and that innovation was critical to both the success of UNIX and to the growth of the industry as a whole. However, the existence of a free version of UNIX was critical in enabling the consolidation of all of these different UNIXes, even if they weren’t necessarily formal mergers. Why were all of these competing companies willing to throw their hat into the Linux ring? Because of the Open Source license, which protected companies from their competitors hijaacking the commons and using their own code against them.    (MI6)

Ironically, the story of UNIX is also one of the reasons I believe that the GPL’s terms are unnecessary for the proliferation of software freedom. The BSD license enabled proprietary forks, which arguably enabled innovation that wouldn’t have happened otherwise. In fact, it’s still enabling this today; look at Mac OS X. In the end, however, culture won out; these same proprietary companies are all supporting Open Source software, not because they had to (although they do now), but because they wanted to. Empowerment is stronger than enforcement when it comes to communities and collaboration.    (MI7)

I can’t resist one more small rant, a teaser if you will. Most Web 2.0 companies seem to have learned the superficial lessons of Open Source, but they’ve missed the main point. The argument that Open APIs obviate the need for Open Source completely ignores what history has taught us over and over again. One of these days, I’ll blog about this.    (MI8)