Online Collaboration Isn’t Just About Meetings

COVID-19 has forced many of us to reckon with a working world where we can’t be face-to-face. I’ve been heartened to see how collaboration practitioners have been responding overall. I love seeing folks tapping the wisdom of their own groups before looking outward and sharing their knowledge freely and broadly.

I am especially happy to see people reminding others and themselves to pause and revisit their underlying goals rather than make hasty decisions. There is a lot of amazing digital technology out there, and it’s easy to dive head-first into these tools without considering other, technology-free interventions that might have an even greater impact in these difficult times. It’s been interesting, for example, to see so many people emphasize the importance of checkins and working agreements. When this is all over, I hope people realize that these techniques are relevant when we’re face-to-face as well.

After all, online collaboration is just collaboration. The same principles apply. It just takes practice to get them right in different contexts.

One adjustment I’d like to see more people make is to focus less on meetings. (This was a problem in our pre-COVID-19 world as well.) Meetings are indeed important, and understanding how to design and facilitate them effectively, whether face-to-face or online, is a craft that not enough people do well. However, meetings are just a tool, and a limited one at that. I’d like to offer two frameworks that help us think beyond meetings.

First, try not to think in terms of “online” or “virtual.” Instead, think in terms of work that happens at the same time (synchronous) or at different times (asynchronous), and collaboration that happens in the same or different places (remote).

Many collaboration practitioners tend to focus on synchronous collaboration — stuff that happens at the same time (which often ends up translating to meetings). I think some of the best opportunities for improving collaboration lie with asynchronous collaboration. Many of us assume that we can’t replicate the delightful experiences that are possible when people are in the same place at the same time. I think that’s narrow thinking.

Many years ago, I asked Ward Cunningham, the inventor of the wiki (the collaborative technology that powers Wikipedia), how he would describe the essence of a wiki. He responded, “It’s when I work on something, put it out into the world, walk away, and come back later, only to find that someone else has taken it and made it better.” To me, that beautifully describes what’s possible when asynchronous collaboration is working well, and it resonates with my own experiences. It also offers a North Star for what we’re trying to achieve when we’re designing for asynchronous collaboration.

Second, it’s important to remember that collaboration consists of three different kinds of work: task, relationship, and sensemaking. Breaking collaboration into these three categories can offer greater guidance into how to design and facilitate asynchronous work more effectively.

For example, a common type of task work for knowledge workers is creating documents. Agreeing on a single place for finding and editing documents hugely simplifies people’s abilities to collaborate asynchronously. It also better facilitates the kind of experience that Ward described than, say, emailing documents back-and-forth.

A common sensemaking exercise is the stand-up meeting, where everyone on a team announces what they’re working on and where they need help. (People are asked to stand up during these meetings to encourage people to keep their updates brief.) You could easily do a stand-up meeting online, but aggregating and re-sharing status updates over email is potentially more efficient and effective.

One interesting side effect of so many people meeting over video while sheltering in place is that we literally get a window into each other’s homes and even our families and pets, an emergent form of relationship-building. Pamela Hinds , who has long studied distributed work, calls this “contextual knowledge” and has often cited it as a key factor for successful remote, asynchronous collaboration. (It’s why, when we were designing the Delta Dialogues, a high-conflict project focused on water issues in the Sacramento Delta, we chose to rotate the meetings at people’s offices rather than at a neutral location. We wanted people to experience each other’s workplaces to enhance their sense of connection with each other.)

Once we recognize this form of relationship-building as useful, we can start to think about how to do it asynchronously. In my Colearning community of practice, which consists of ten collaboration practitioners across the U.S. and Canada, each of us posts a weekly personal checkin over Slack, often sharing photos and videos of our loved ones. We post and browse at our own convenience, and the ritual and the artifacts forge bonds that run deeper than what would be possible with, say, a monthly video call, which would be incredibly hard to schedule and would almost certainly prevent some of us from participating.

Similarly, we don’t need video to see each other’s faces. A trick I stole from Marcia Conner many years ago — well before video was ubiquitous — was to get silly photos of everyone on the team, combine them in a document, and have everybody print and post it on their office wall. This not only enhanced our conversations when we were talking over the phone, it created a constant sense of connection and fun even when we weren’t in a room together.

While I hope these examples dispel the notion that synchronous collaboration is inherently more delightful and impactful than asynchronous, I also want to acknowledge that designing for asynchronous collaboration is more challenging. I think there are two reasons for this.

First, you have to compensate for lack of attention. When everyone is in a room together, it’s easier to get and keep people’s attention. When people are on their own, you have no control over their environment. You have to leverage other tools and techniques for success, and you’re unlikely to get 100 percent follow-through.

The two most common tools for compensating for lack of attention are the artifact and the ritual. An artifact is something tangible, something that you can examine on your own time, whether it’s a written document, a picture, or Proust’s Madeleine. A ritual is an action — often with some cultural significance — that’s repeated. It could be a rule (with enforcement) or a norm that people just do. It’s effective, because it becomes habitual, which means people are able to do it without thought.

The trick is finding the right balance of artifacts and rituals. At Amazon, Jeff Bezos famously requires people to write a six-page memo before meetings, but they designate shared time at the beginning of each meeting to read the memo together. On the one hand, writing the memo requires discipline and attention in-between meetings, or asynchronously. On the other hand, rather than save meeting time by having people read the memos beforehand, they devote synchronous time to reading the memos together. I can guess the reasons for this, but the truth is that I don’t know what they are. Different practices work in different contexts. Everybody has to figure out what works for themselves. Certain kinds of cultures — especially transparent, iterative, developmental ones — will be more conducive to these kinds of practices.

Finally, our relationship to technology matters, but maybe not in the way you think. On the one hand, if you are going to use a tool for collaboration, then it’s important to learn how to use it fluently and wield it skillfully. On the other hand, technology has this way of making you forget what you already know. It may be that the tools that will be most helpful for you have nothing to do with the latest and greatest digital technology.

This has always been easy for me to understand, because I have always had an uncomplicated relationship with technology. I love technology, but its role is to serve me, not the other way around. When I design structures and processes for collaboration, I always start with people, not tools, and I try to help others do the same.

What I’ve come to realize over the years is that this is often hard for others, because they’re worried about what they don’t know and they have a block when it comes to learning about technology. I get this. I have blocks about learning many things, and I know that advice that amounts to “get over it” is not helpful. Please recognize that these feelings are not only real, they’re okay. While I’d encourage everyone to find peers and resources that help them learn about digital tools in a way that feels safe, I also want to remind you that collaboration is ultimately about people. Keeping your humanity front and center will not only help you with your transitions to remote work, it will help you through this crisis.

Podcast: Play in new window | Download

Subscribe: RSS

Habits of High-Performance Groups

I am passionately committed to helping as many people as possible get better at collaboration. Within this larger mission, I am most interested in helping groups collaborate on our most complex and challenging problems. Over the past 17 years, I’ve gotten to work on some crazy hard stuff, from reproductive health in Africa and Southeast Asia to water in California. I’ve learned a ton from doing this work, I continue to be passionate about it, and I’ve developed a lot of sophisticated skills as a result.

However, for the past year, I’ve been focusing most of my energy on encouraging people to practice setting better goals and aligning around success. My Goals + Success Spectrum is already my most popular and widely used toolkit, and yet, through programs like my Good Goal-Setting workshops, I’ve been doubling down on helping people get better at using it and — more importantly — making it a regular habit.

I’ve been getting a lot of funny looks about this, especially from folks who know about my passion around systems and complexity. If I care so much about addressing our most wicked and challenging problems, why am I making such a big deal about something as “basic” and “easy” as setting better goals and aligning around success?

Because most of us don’t do it regularly. (This included me for much of my career, as I explain below. It also includes many of my colleagues, who are otherwise outstanding practitioners.)

Because many who are doing it regularly are just going through the motions. We rarely revisit and refine our stated goals, much less hold ourselves accountable to them.

Because much of the group dysfunction I see can often be traced to not setting clear goals and aligning around success regularly or well.

Because doing this regularly and well not only corrects these dysfunctions, it leads to higher performance and better outcomes while also saving groups time.

And finally, because doing this regularly and well does not require consultants or any other form of “expert” (i.e. costly) help. It “simply” requires repetition and intentionality.

Investing in the “Basics” and Eating Humble Pie

In 2012, I co-led a process called the Delta Dialogues, where we tried to get a diverse set of stakeholders around California water issues — including water companies, farmers and fishermen, environmentalists, government officials, and other local community members — to trust each other more. Many of our participants had been at each other’s throats — literally, in some cases —for almost 30 years. About half of our participants were suing each other.

It was a seemingly impossible task for an intractable problem — how to fairly distribute a critical resource, one that is literally required for life — when there isn’t enough of it to go around. I thought that it would require virtuoso performances of our most sophisticated facilitation techniques in order to be successful. We had a very senior, skilled team, and I was excited to see what it would look like for us to perform at our best.

Unfortunately, we did not deliver virtuoso performances of our most sophisticated facilitation techniques. We worked really hard, but we were not totally in sync, and our performances often fell flat. However, something strange started to happen. Despite our worst efforts, our process worked. Our participants gelled and even started working together.

Toward the end of our process, after one of our best meetings, our client, Campbell Ingram, the executive officer of the Delta Conservancy, paid us one of the best professional compliments I have ever received. He first thanked us for a job well done, to which I responded, “It’s easy with this group. It’s a great, great group of people.”

“It is a great group,” he acknowledged, “but that’s not it. I’ve seen this exact same set of people at other meetings screaming their heads off at each other. There’s something that you’re doing that’s changing their dynamic.”

My immediate reaction to what he said was to brush it aside. Of course we were able to create that kind of space for our participants. Doing that was fundamental to our work, and they were all “basic” things. For example, we listened deeply to our participants throughout the whole process and invited them to design with us. We co-designed a set of working agreements before the process started, which was itself an intense and productive conversation. We asked that people bring their whole selves into the conversation, and we modeled that by asking them very basic, very human questions, such as, “What’s your favorite place in the Delta?” and “How are you feeling today?” We rotated locations so that people could experience each other’s places of work and community, which built greater shared understanding and empathy. We paired people up so that folks could build deeper relationships with each other between meetings.

These were all the “basic” things that we did with any group with which we worked. I didn’t think it was special. I thought it was what we layered on top of these fundamentals that made us good at what we did.

But in reflecting on Campbell’s compliment, I realized that I was wrong. Most groups do not do these basic things. For us, they were habits, and as a result, we overlooked them. They also weren’t necessarily hard to do, which made us undervalue them even more. Anyone could open a meeting by asking everyone how they were feeling. Only a practitioner with years of experience could skillfully map a complex conversation in real-time.

I (and others) overvalued our more “sophisticated” skills, because they were showier and more unique. However, it didn’t matter that we were applying them poorly. They helped, and they would have helped even more if we were doing them well, but they weren’t critical. Doing the “basics” mattered far more. Fortunately, we were doing the basics, and doing them well.

Not doing them would have sunk the project. I know this, because we neglected a basic practice with one critical meeting in the middle of our process, and we ended up doing a terrible job facilitating it despite all of our supposed skill. The long, silent car ride back home after that meeting was miserable. I mostly stared out the window, reliving the day’s events over and over again in my head. Finally, we began to discuss what had happened. Rebecca Petzel, who was playing a supporting role, listened to us nitpick for a while, then finally spoke up. “The problem,” she said, “was that we lost sight of our goals.”

Her words both clarified and stung. She was absolutely right. We knew that this meeting was going to be our most complex. We were all trying to balance many different needs, but while we had talked about possible moves and tradeoffs, we hadn’t aligned around a set of collective priorities. We each had made moves that we thought would lead to the best outcome. We just hadn’t agreed in advance on what the best outcomes were, and we ended up working at cross-purposes.

I was proud of Rebecca for having this insight, despite her being the most junior member of our team, and I also felt ashamed. I often made a big deal of how important aligning around success was, but I had neglected to model it for this meeting, and we had failed as a result.

Habits Are Hard

After the Delta Dialogues, I made a list of all the things I “knew” were important to collaborating effectively, then compared them to what I actually practiced on a regular basis. The gap wasn’t huge, but it wasn’t trivial either. I then asked myself why I ended up skipping these things. The answer generally had something to do with feeling urgency. I decided to try being more disciplined about these “basic” practices even in the face of urgency and to see what happened.

I was surprised by how dramatically the quality and consistency of my work improved. I was even more surprised by how slowing down somehow made the urgency go away. The more I practiced, the more engrained these habits became, which made them feel even more efficient and productive over time.

In 2013, I left the consulting firm I had co-founded to embark on my current journey. Helping groups build good collaborative habits through practice has become the cornerstone of my work. Anyone can easily develop the skills required to do the “basics” with groups. They just need to be willing to practice.

I’ve identified four keystone habits that high-performance groups seem to share:

The specific manifestation of each practice isn’t that important. What matters most is for groups to do all four of them regularly and well.

Over the past six years, I’ve had decent success developing practices and tools that work well when repeated with intention. Unfortunately, I haven’t been as successful at encouraging groups to make these practices habits. As I mentioned earlier, I think one reason is that it’s easy to undervalue practices that seem basic. I think the biggest reason is that developing new habits — even if we understand them to be important and are highly motivated — is very, very hard.

In his book Better: A Surgeon’s Notes on Performance, Atul Gawande writes that every year, two million Americans get an infection while in a hospital, and 90,000 die from that infection. What’s the number one cause of these infections? Doctors and other hospital staff not washing their hands.

For over 170 years, doctors have understood the causal relationship between washing their hands and preventing infection. Everybody knows this, and yet, almost two centuries later, with so many lives at stake, getting people to do this consistently is still extremely hard, and 90,000 people die every year as a result. Gawande explains:

We always hope for the easy fix: the one simple change that will erase a problem in a stroke. But few things in life work this way. Instead, success requires making a hundred small steps go right — one after the other, no slip-ups, no goofs, everyone pitching in. We are used to thinking of doctoring as a solitary, intellectual task. But making medicine go right is less often like making a difficult diagnosis than like making sure everyone washes their hands.

If it’s this hard to get doctors to wash their hands, even when they know that people’s lives are at stake, I don’t know how successful I can expect to be at getting groups to adopting these habits of high-performance groups when the stakes don’t feel as high.

Still, I think the stakes are much higher than many realize. I recently had a fantastic, provocative conversation with Chris Darby about the challenges of thinking ambitiously and hopefully when our obstacles are so vast. Afterward, I read this quote he shared on his blog from adrienne maree brown’s, Emergent Strategy:

Imagination is one of the spoils of colonization, which in many ways is claiming who gets to imagine the future for a given geography. Losing our imagination is a symptom of trauma. Reclaiming the right to dream the future, strengthening the muscle to imagine together as Black people, is a revolutionary decolonizing activity.

We all have the right to articulate our own vision for success. When we don’t exercise that right, we not only allow our muscles for doing so to atrophy, but we give others the space to articulate that vision for us. Hopefully, these stakes feel high enough to encourage groups to start making this a regular practice.

For help developing your muscles around articulating success, sign up for our Good Goal-Setting online peer coaching workshop. We offer these the first Tuesday of every month.

Investing in and Designing for Trust

"Bank" in Kano, Nigeria

I spent the first half of 2008 helping a network of reproductive health leaders across several developing countries find ways to collaborate more effectively with each other. As part of this work, I spent a week working with leaders in Kano, Nigeria. When I first arrived there, I asked my host to show me where the local bank was so that I could exchange some currency. He explained that people in Kano don’t go to banks. Thieves knew to hang out there, and even if you managed to avoid getting robbed, you couldn’t trust the banks to give you real currency.

Instead, he introduced me to a guy in a red truck parked outside of a Chinese restaurant, and he negotiated an exchange. When I asked him how he knew where to go and whom to trust, he explained that it was largely word of mouth — family, friends of friends, etc. But he also made it clear that word of mouth wasn’t consistently trustworthy either, and that you had to remain constantly vigilant. Constant vigilance meant constant stress, which is what I felt throughout my trip knowing that I couldn’t trust the institutions that I generally depended on here in the U.S. However, relationships still mattered. Knowing and trusting a few core locals enabled me to acclimate quickly and even learn to thrive.

The Problem with Structure

Trust is an essential part of effective collaboration. Without it, most groups fall apart. However, we are often naive in how we design for trust.

Consider decision-making. One of the easiest ways to gauge how much a group trusts each other is to look at its governance structure. In high-trust groups, people assume that everyone will do what it takes to make the best decisions. Sometimes, this means reaching out to others for discussion and pushback. Other times, it means being proactive about making decisions, understanding that it’s impossible to know everything in advance and that mistakes will happen. These groups often get away with minimal, mostly informal governance structures.

In low-trust groups, people fear that they won’t be properly represented and that others won’t make good decisions on their own, so they insist on being part of every decision. Decision-making is often time-consuming and ineffective as a result. These groups often try to compensate by adding more rigid, formal governance structures.

High-trust groups are about forgiveness. Low-trust groups are about permission.

Even though rigid, overly formal structures are often a symptom of low-trust groups, we often try to compensate for this by creating additional — you guessed it — rigid, overly formal structures. The problem isn’t that new structures can’t help. It’s that the structures we choose don’t necessarily increase trust and may even serve to impede it.

For example, many international aid organizations require some sort of government involvement in order to ensure that money goes to the right places and is used in the right ways. Their assumption is that government is the most trustworthy way for this to happen. As I saw firsthand in Nigeria, this assumption is sometimes wrong, and the work suffers as a result.

There are two ways to navigate around this. The first is to remember that there are other ways to invest in trust beyond building new structures — specifically, investing in relationships. The second is to think more intentionally and creatively about the structures you build.

Investing in Relationships

In 2012, I co-led a multistakeholder process called the Delta Dialogues focused on California water issues. California has been embroiled in a complex and expensive debate over water policy for several years. Rather than propose an alternative policy process, we chose to augment the existing processes by focusing on trust-building between key players.

We mostly focused on building shared understanding using sophisticated mapping tools, but we also placed a huge emphasis on getting to know each other as people. For example:

  • Whenever someone joined the Dialogues, we asked them to share their favorite place in the Delta.
  • Rather than seek a “neutral” location for our meetings, we rotated locations among the participants, so that everyone could see and experience each other’s workplace.
  • We assigned each participant a buddy, and we asked that they talk to each other before and after each meeting.

Journalist, Joe Mathews, who covered the Dialogues, later wrote:

Participants would say the field trips in general were the most valuable part of the Dialogues. All of the participants had lived or done work on the Delta. But even those who had spent their whole lives living in the Delta had seen only parts of the massive estuary. To get a guided tour from another participant and see a piece of the Delta through that person’s eyes proved to be invaluable.

Campbell Ingram [director of the Delta Conservancy, and our client] expressed some embarrassment that the experience of this field trip was so new. “I was pretty amazed that I spent so many years at the BDCP table [the water policy discussion] without that gut level understanding of what it means to be a pear farmer in the Delta. I always thought pear farming was in decline, and then got to see and hear reality, and their issues with their inability to plan. To me, that had a huge impact. It made me feel really uncomfortable. I think a lot of us had the realization that the degree to which we had overlooked the Delta in these processes.”

…

Outside the meetings and field trips, the Dialogues were deepening and taking root in ways that the facilitators couldn’t see. The participants found they liked each other. And they began to talk and meet outside the Dialogues.

These personal relationships and conversations would be among the most treasured products of the Dialogues. Many of these connections were of the strange bedfellows variety.”

Assuming Trust

Most structures — from governance to physical structures — are designed with low-trust in mind. Consider the humble traffic light. The fundamental assumption underlying its design is that we cannot trust people to negotiate intersections with each other in a safe, efficient manner. But what if we could? What might intersections look like then?

Traffic engineer Hans Monderman’s answer to this question was a traffic circle. As it turns out, traffic circles are safer and more efficient than traffic lights. Giving control back to the drivers forces them to be more present and more diligent, which results in better outcomes.

Similarly, most websites have login credentials and access permissions. They assume that without gatekeepers, people will just go around breaking things. While these websites are decent at keeping bad guys out, they are also surprisingly bad at allowing good guys to get in. Most of us believe that this is an unfortunate, but necessary tradeoff.

Wikis flip this assumption around. They assume that most people are intelligent and want to do good, that if you trust people by default, good things will happen. Wikis not only allow anyone to edit them, they do not impose any kind of editorial workflow. They assume that good, smart people will figure out for themselves how to create the highest quality content. Wikipedia — the most prominent of all wikis — is a devastating example of this principle operating at massive scale.

Wikis still have structure, only their structures are designed to reinforce, rather than replace, trustworthy behaviors. For example, wikis maintain a copy of all prior revisions. This encourages people to try things, knowing that their mistakes can be easily reverted. People’s contribution histories also serve as a kind of currency that helps reinforce their trustworthiness.

When you design for trust, the results are often simpler and more elegant (and sometimes counter-intuitive). These designs give up control rather than assert it, resulting in greater agility and higher quality.

However, designing for trust doesn’t work so well if you don’t have trust in the first place. Organizational forms without explicit hierarchy have existed for decades, but recent instantiations like Holocracy have recently become popular, especially in the technology sector. What people are starting to realize is that trust is a critical ingredient to make this work, lack of trust is often a cultural problem, and eliminating structure does not solve anything if your problem is with culture.

Structure and trust have a tumultuous relationship, but if we start with some basic principles, we can harness both to create higher-quality collaboration. Invest in relationships, then design structures that reinforce, rather than replace, trust.

Special thanks goes to Jerry Michalski, who — when we first met 12 years ago — first provoked me with the question, “What if we trusted people?” I’ve been pondering that question ever since.

Navigating Complexity Through Collective Sensemaking

A core strategy for navigating wickedly complex problems is to try to make collective sense of the system. Like the blind men and the elephant, we all have a narrow and incomplete view of the system in which we’re operating. If we could somehow see and fit each other’s pictures together, new and powerful insights and actions could emerge.

That’s the theory, at least. But how do you do this in practice? What does the process feel like? And how do you reconcile this approach with my earlier assertion that collective intelligence is not about enabling individuals to grasp the whole system?

At last week’s Garfield Foundation Collaborative Networks initiative kickoff, Joe Hsueh walked us through his answer by drawing this graph. (Joe himself explains the graph in the above two-minute video.)

Navigating Complexity Model

We as individuals try our hardest to navigate complexity until we hit our mental capacity. Generally, that experience is so exhausting and dissatisfying, we find ourselves dropping back into simplistic, siloed thinking.

The goal of a collective sensemaking process is to help individuals endure greater complexity than we normally can handle. At some point, we still have to simplify the system in order to process it as individuals, but the hope is that, by raising the overall bar, you end up at a higher place than you were before.

With system mapping (which is the tool that Joe so skillfully employs), the map itself is of limited utility to individuals who have not participated in its creation, because they have not gone through that process of mental endurance. This is a critical point. The real value of system mapping isn’t the final artifact. It’s the process of developing shared understanding by collectively creating that map.

An Aside on Facilitation

You can’t design or facilitate these kinds of processes effectively unless you yourself have a strong framework around complexity and systems thinking. Good designers create the space for participants to live in this complexity.

Living in complexity is inherently disorienting, and people have different appetites for it. Part of the facilitator’s job is to help the group maintain their faith in the face of intense discomfort. One way you can do that is by walking the group through your framework.

Unfortunately, I often see facilitators make the mistake of spending too much time explaining frameworks up-front rather than giving the participants the space and time to experience the framework. It’s a tricky balance, and finding that balance is a sign of mastery.

At last week’s meeting, Joe offered the framework at exactly the right time. You could see the relief on the participants’ faces as he explained that the joint struggle and frustration that everybody was experiencing was all part of the process.

It reminded me of a similar moment with one of my mentors, Jeff Conklin, during the Delta Dialogues in 2012. The participants were getting frustrated by how much the conversation was jumping around (which was by design), and I felt like we were starting to lose them.

Jeff stepped in, and drew and explained a graph that described the different ways that people learn. It was beautiful to watch people’s faces light up with understanding. Jeff’s impromptu (and brief) lesson in theory not only helped orient our participants, it gave them language to describe what they were going through.

Tic-Tac-Toe and the Squirm Test: Building Trust and Shared Understanding

Elliott's Monster Face

Trust. Shared understanding. Shared language. I constantly mention these as critical elements of collaboration. But how do we develop these things, and how do we know if we’ve got them?

We can start by playing Tic-Tac-Toe, then by applying the Squirm Test.

Tic-Tac-Toe

Many years ago, one of my mentors, Jeff Conklin, taught me a simple exercise that gave me a visceral understanding of why trust, shared understanding, and shared language were so important, as well as some clues for how to develop these things.

First:

  1. Find a partner.
  2. Play Tic-Tac-Toe.

Try it now! What happened?

Hopefully, nobody won, but don’t stress too much if you lost. It happens!

Second: Play Tic-Tac-Toe again, except this time, don’t use pen or paper.

Try it now! What happened?

In order to play, you needed to come up with shared language to describe positions on the board. You probably managed, but it was almost certainly harder.

Third:

  1. Play Tic-Tac-Toe without pen or paper again, except, this time, play on a four-by-four board — four rows, four columns.
  2. Play until it’s too hard to play anymore, until someone has won, or until there’s a dispute about what the board looks like. When you’re done, both you and your partner should draw what you think the board looks like without looking at each other’s work. Now compare.

Try it now! What happened?

Research suggests that we can hold between five to nine thoughts in our head at a time before our short-term memory begins to degrade. This is why American phone numbers have seven digits. It’s also why three-by-three Tic-Tac-Toe (nine total squares) without pen and paper felt hard, but doable, whereas increasing the board by just one row and column (sixteen total squares) made the game feel impossible.

How many ideas do you think you’re holding in your head after just five minutes of moderately complex conversation? How often are you using some kind of shared display — a whiteboard, a napkin, the back of an envelope — to make sure that everyone is tracking the same conversation?

While you were playing, how much did you trust that the two of you were seeing the same board at all times? Were you right?

In cooperation theory, the most successful groups trust each other by default. You almost certainly assumed that your partner knew the rules of Tic-Tac-Toe and was playing it fairly to the best of his or her ability. If you already had a strong relationship with your partner, you probably trusted him or her even more.

But trust is fragile, and it’s not always relational. If it’s not constantly being reinforced, it weakens. A lack of shared understanding is one of the easiest ways to undermine trust.

With the Delta Dialogues, we were dealing with a uniquely wicked and divisive issue — water in California. As a facilitator, you always want to get the group out of scarcity thinking. But water is a zero-sum game, and no amount of kumbaya is going to change that. Moreover, we were dealing with a half-century legacy of mistrust and a group of participants who were constantly in litigation with each other.

We did a lot of unique, relational work that played an important role in the success of Phase 1 — rotating site visits, asking people to share their favorite places in the Delta, implementing a buddy system, leaving plenty of space for breaking bread. But we were not relying on these things alone to build trust.

Our focus was on building shared understanding through a mapping process that allowed the group to see their ideas and track their conversations in real-time. Prior to our process, the group had been attempting to play multi-dimensional Tic-Tac-Toe with thousands of rows and columns… and no pen and paper. We brought the pen and paper, along with the ability to wield it skillfully.

Like many of my colleagues, I believe strongly in building and modeling a culture where people are engaging in powerful, constructive, sometimes difficult conversation. Unfortunately, it’s not enough to get people into a circle and to have them hold hands and talk about their feelings. The more wicked the problem, the more inadequate our traditional conversational tools become, no matter how skillfully they are wielded.

This recognition is what separates the Garfield Foundation’s Collaborative Networks initiative from similar well-intentioned, but misguided initiatives in the nonprofit and philanthropic worlds, and it’s why I’m working with them right now. We happen to be employing system mapping (and the talents of Joe Hsueh) right now as our “pen and paper” for developing that shared understanding, but it’s how and why we’re mapping — not the specific tool itself — that separates our efforts from other processes.

The Squirm Test

How do you know how much shared understanding you have in the first place? And if you choose to employ some version of “pen and paper” to help develop that shared understanding, how do you know whether or not you’re intervention is effective?

Many years ago, I crafted a thought experiment for doing exactly that called the Squirm Test.

  1. Take all of the people in your group, and have them sit on their hands and in a circle.
  2. Have one person get up and spend a few minutes describing what the group is doing and thinking, and why.
  3. Repeat until everyone has spoken.

You can measure the amount of shared understanding in the group by observing the amount of squirming that happened during the presentations. More squirming means less shared understanding.

You can implement the Squirm Test in all sorts of ways, and it even appears in different high-performance communities in real-life. For example, the Wikipedia principle of Neutral Point of View is essentially the Squirm Test in action. If you read an article on Wikipedia, and it makes you squirm, edit it until the squirming goes away. If enough people do that, then that article will accurately reflect the shared understanding of that group of people and will thus achieve Neutral Point of View.

Toward the end of Phase 1 of the Delta Dialogues, we designed a whole day around the Squirm Test. We had participants capture on flipcharts what they thought the interests and concerns were of the other stakeholder groups. Then we had participants indicate whether these points represented themselves accurately and whether they found shared understanding on certain issues surprising. There was very little squirming and quite a bit of surprise about that fact. It was a turning point for the process, because the participants were able to see in a visceral way how much shared understanding had been built through all of their hard work together.

Last week, I was describing the Squirm Test to Rick Reed, the leader of Garfield Foundation’s Collaborative Networks initiative. He pointed out a discrepancy that I had not thought of before. “People might not be squirming because there’s no shared understanding. They might be squirming because, after seeing the collective understanding, they realize that they’re wrong!”

This is exactly what happened with the Garfield Foundation’s first Collaborative Network initiative, RE-AMP. When you are able to see the whole system, including your place in it, you may discover that your frame is wrong. The kind of squirming that Rick describes is the good kind. Understanding how to design for it is a topic for another day!

The Art of the Start

Triathlon Start

Two of my mentors, Gail and Matt Taylor, often stress the importance of “clean beginnings.” Whenever you take on any hard, collaborative project, you have to expect that it will get messy in the middle. If you take the time to set up conditions for success at the beginning of the project, you will greatly increase your chances of surviving — even thriving in — that mess. Folks in this business often refer to this as “creating a safe container.”

I’m in the process of doing this with two projects right now — an experiment with the Code for America Incubator Program and the kickoff of Garfield Foundation’s latest Collaborative Networks initiative — and I wanted to share some of my experiences in “the art of the start” from these and other projects.

Creating a safe container consists of three activities:

  1. Literally creating a delightful, inviting space (physical, virtual, or both) in which the group can interact
  2. Developing shared understanding among the group
  3. Making explicit working agreements.

When done effectively, these three things in combination lead to greater trust within the group, which enables it to work effectively moving forward.

1. Create Delightful, Inviting Space

The physical spaces in which we work have a huge impact on our ability to work effectively. Dark, tight spaces affect the mood of the group. The seating arrangement can physically reinforce certain power dynamics. If it’s hard to get to the whiteboard, people won’t use it.

These issues don’t just apply to physical space. If your group has a weekly two-hour phone call with poor audio quality and no shared display, people will dread (or simply tune out) those calls. If you’ve chosen to interact using an online tool that nobody knows how to use, then no one will use it.

Spatial issues may seem trivial, but I think they are just as important as facilitation. In 2012, I co-led a project called the Delta Dialogues, where we were facilitating a multistakeholder group around California water issues. Our participants had been fighting over these extremely contentious issues for decades, and many had standing lawsuits with each other.

One of the early decisions we made was to rotate our meeting locations among the participants rather than seek “neutral” space. We had six one-day meetings scheduled, and we decided to devote half that time to “learning journeys” — essentially tours of each others’ spaces. We did this because the Sacramento Delta is beautiful, and we wanted to spend as much time as possible in that beauty to remind ourselves what this was all about. We also did this wanted participants to experience each other’s environments first-hand to build greater empathy.

This was not a decision we made lightly. Given the complexity of the issues we were discussing, devoting half of our times to field trips felt hard to swallow, and we went back and forth on this decision a number of times. However, when the process was over, participants consistently cited these learning journeys as the most powerful part of the process for them.

Rick Reed, the leader of the Garfield Foundation’s Collaborative Networks initiative, feels as strongly about the importance of the physical experience as I do. He seeks out great meeting space with beautiful light, and he makes sure that the food is excellent and memorable. Some people do not think foundations should be spending money on things like great space and food in light of the economic hardships the nonprofit sector is currently facing. While I am a fan of fiscal discipline, if foundations want to contribute to great collaborative experiences, I think investing in great space and great food are two of the easiest and most impactful ways to do that.

Creating an inviting, delightful space is not just about physical or even virtual space. Language, for example, is a big part of this. I often use the term “ground rules” to describe working agreements (see below), but when I used the term at a Collaborative Networks design meeting, our teammate, Ruth Rominger, pushed back. She thought the implications of “rules” ran counter to the culture we were trying to build. On Curtis Ogden’s suggestion, we decided to adopt the term “working agreements” instead, which is more inviting, but still meaningful.

2. Develop Shared Understanding

The group norming process is about developing shared understanding, which leads to greater trust and stronger relationships. The default way to build shared understanding is to work together. There are great merits to this, but they are easily neutralized or worse if you don’t take the time to have explicit conversations about norms as well.

For example, when I worked as a consultant, I spent a significant amount of time helping stakeholders get aligned and clear around the goals of the project. It was a straightforward, but time-consuming step, one that most groups would skip if left to their own devices. And yet that step alone made a huge difference in the quality of the engagement once we got going. Often, individuals do not feel empowered or accountable to the rest of the group, simply because there is no shared understanding of what they’re supposed to be doing or what’s expected of them.

How do you develop this shared understanding? The simplest first step is to carve out time to have those conversations as a group. A huge part of my experiment with the Code for America Incubator is simply that — giving startups structured time to have explicit conversations about things such as what kind of organization they’d like to be and how they’d like to work together.

Beyond this, there are a few useful tricks. One is to tap into people’s personal experiences and values. Rather than start with the question, “How would you like to work together?”, ask each other, “What’s been your best experience working together?”, or better yet, “Why did you get into this work?” Have people share those stories with each other, then pull out key patterns and insights from the stories.

With the Delta Dialogues, we had participants answer the question, “What’s your favorite place in the Delta?” Many of the participants had known each other for decades, yet did not know each other’s answers to these questions. It reinforced the fact that everybody in the room (including the supposed “bad guys”) had deep connections to the Delta, and it reminded everybody about what was at stake.

Another trick is to design these experiences to be in-the-flow as much as possible. People who design collaborative engagements — consultants in particular — often make two mistakes: They focus too much on meetings, and they don’t pay enough attention to the work that participants are already doing. You’re almost never starting from scratch. People have pre-existing relationships, and they may already have done the work that you’re wanting to do.

I joined the Wikimedia strategic planning process in 2009. The Wikimedia Foundation had hired a traditional management consultancy four months earlier, and they were stuck. These consultants had no experience with participatory processes or with the Wikimedia community, and they had designed a process that was not viable. Their plan looked like most traditional strategic planning processes. They would spend four months doing research on their own and coming up with the “right” strategic questions, then they would unleash a polished presentation to the community at large and ask for feedback.

Not only did this approach not account for the spirit of the project (wiki-style strategic planning) or the culture of the community, it completely ignored the challenge of enrollment. The Wikimedia editing community consisted largely of men in their teens and twenties. They had no concept of what strategic planning was, much less why they should engage in it. Even if they did understand what strategic planning was, they had no reason to engage with us about it. Why should they trust our claimed intentions to facilitate an open, wiki-style process?

I wanted to develop a shared understanding of the work that had already been done, and I also wanted to develop a shared understanding around what we were trying to do with this process. Rather than wait four months to do research in isolation, within a week of starting the project, we were engaging with the community on a wiki. We explained what we hoped to do, and we listened. We didn’t make grand promises, and we didn’t claim any expertise. We basically invited people to tell everybody (not just us) what they thought the Wikimedia movement’s priorities should be and to point to work that was already happening.

In the spirit of creating an inviting container, our facilitator, Philippe Beaudette, stressed the importance of making our space multilingual, given how international the community was. We invited people to engage in any language with which they felt comfortable, and we did our best to translate our requests into as many languages as possible.

We had a clear ask, and that ask felt very familiar to the Wikimedia community. They were used to sharing and organizing their thoughts, and they were not shy about expressing their opinions. Within a few weeks, we had an incredible compendium of well-organized thinking that had already been done by the community, along with a set of thoughtful, strategic questions that people felt were important to explore.

More importantly, people started trusting us. They saw that we got it, that we weren’t going to try to impose something top down on a movement that was inherently bottoms-up. (We would have failed if we tried.) We didn’t try to have some grand kickoff meeting or to facilitate a bunch of private, insider conversations. Instead, we spent time in the spaces that already existed (such as the wiki and in real-time online chat channels), and we facilitated a many-to-many conversation, not just a one-on-one conversation. The community was taking ownership of the process, and we were contributing to it. Even if they didn’t fully understand what we were trying to do, they understood it well enough and they trusted us enough to give it a chance.

3. Make Explicit Working Agreements

I find making explicit agreements on how you’d like to work together to be one of the most valuable things a group can do, whether it’s a small team or a large network.

For example, some might think that “treating other people with respect” should be implicit in every working arrangement. Even if that’s the case, making it explicit can’t hurt, and it can even help. For one, it forces you to develop some shared understanding around what “treating other people with respect” actually means. To some, it might mean never raising your voice. To others, it might have nothing to do with how you express yourself, only that you do. Getting these things out into the open earlier rather than later, then coming to agreement on them will prevent trouble later on.

Establishing working agreements has two other important effects, especially with larger groups. First, it makes everyone accountable for holding him- or herself and each other to these agreements. Often, in large meetings, people depend on a facilitator to keep the conversation constructive and civil. That indeed is one of the facilitator’s responsibilities, but it’s a muscle that everyone in the group should be exercising. In healthy groups, everybody will help each other abide by these agreements.

Second, they set agreed-upon conditions for kicking people out of a group. A lot of people fear open processes, because they’re worried that others will hijack the conversation, and they mistakenly assume that you can’t kick people out of an open conversation. If you create clear working agreements up-front, and if you make sure people are aware of those agreements, then when people unapologetically cross the line, you have the right to expel them.

We had over a thousand people participate in the Wikimedia strategic planning process. Over the course of the year-long process, we kicked out two people from the process as a whole, and I kicked out one person from one meeting (who apologized afterward, and went on to be a very constructive participant in the process). None of those incidents were easy, but when we made those moves, everyone in the community understood and agreed with our actions, because of our previously established working agreements.

This blog post is also available in French. Many thanks to Lilian Ricaud for the translation!