Wikipedia – Faster Than 20

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

Everybody Is People

Many years ago, a colleague, Nick Papadopoulos, told me about a complex negotiation he was asked to facilitate between a large corporation and a community of angry activists. They had met several times without external facilitation and were not making progress. Nick practiced Dialogue Mapping, a visual facilitation technique for mapping complex issues in real-time, and he had other sophisticated skills in his toolbelt as well.

The first meeting he attended started at 8am on a Saturday morning in one of the company’s conference rooms. When he arrived, there was no food or coffee. The meeting began, and people were predictably grouchy. The issues they were discussing were political and personal, and they were also discussing them on an empty stomach.

As it turned out, Nick’s wife had just started a catering business. At the next meeting, he brought a tray of her muffins. The tenor of the discussion shifted noticeably, and he started doing this regularly. Several weeks later, after he had successfully brought the negotiation to a close, several of the participants came up to him and told him how much they enjoyed his wife’s muffins.

I wasn’t at any of those meetings. I have no idea what role the food actually played in Nick’s success. He is both modest and skilled, and that probably mattered more than the food in the end. However, for me, his insight about the food was part of what made him skilled. I’m sure it played a significant role in his success.

Why am I so sure?

Everybody is people.

It’s likely that most people have not yet eaten at an 8am meeting on a Saturday morning. People need food in their systems to be at their best. People like tasty food, especially the homemade kind, which reminds us of family, of people we love, of our humanity. When the topic of conversation is controversial and complex, people need to be at their best. Depriving them of food — consciously or not — is not a good idea. Reminding them of their and each other’s humanity is an excellent idea.

This may sound obvious, but it’s easy to forget. We get so caught up in complexity that we forget simple, important things. Things like everybody is people.

I led the Wikimedia open strategy process from 2009 through 2010. We had over a thousand people from all over the world participate, mostly virtually. It’s not the hardest project I’ve worked on, but a lot of people still marvel at it. They wonder how we were able to get so many people to volunteer their time and to work together so constructively, especially without seeing each other. The answer was simple.

Everybody is people.

The fact that we were working mostly virtually didn’t change the fact that we were dealing with people, and people have certain basic needs. We did three things that are often overlooked, because they were so simple and the project was so complex, people have a hard time believing they were that important.

First, we took the time to individually welcome every single person who showed up. Everyone.

This is the simplest thing that you can do in any online forum (and in any face-to-face meeting), regardless of the tool you’re using. There happens to be lots of data showing that welcoming people when they show up is one of the best ways to improve engagement. But really, do we need the data to justify this? Welcoming people is a simple way to establish a relationship, to show people that they are seen and appreciated.

Second, we held virtual office hours once a week for the entire year. We alternated the times to make them convenient for people in different timezones, which meant that every other week, we were up late at night talking to people. We happened to be using a tool called IRC, which is an ancient real-time chatting tool that Wikipedians like to use, but it would have worked with any tool.

These were not meetings, and there were no agendas. The sole purpose was to hang out with me and Philippe Beaudette, our facilitator. We wanted to meet people, to get to know them, and to listen to what they had to say. We also wanted to invite others to do the same with us.

People came. They were often surprised by the lack of formality. They expected us to be guarded or to have agendas. We answered questions, sometimes in great detail (I can get very philosophical), but we weren’t there to evangelize. We were there to listen and to get to know our participants.

Not only did we achieve that goal, it turned out that participation in office hours led to participation in the overall process. We had the data to prove this. But even if we didn’t, we still would have continued doing this or something similar. Relationships matter, and this was one of the best ways we had for developing them.

Third, we tried our best to get to know people as whole human beings. My colleagues, Renee Fazzari and Curtis Ogden, both like to say that we’re not just brains on sticks. Unfortunately, it’s amazing how often we treat each other that way, even in a face-to-face context. It’s even easier to make this mistake online when you can’t actually see the person.

Early in our process, we had one participant who was causing a lot of trouble over an obscure decision that we had made and with which everyone else had agreed. It had to do with whether or not Brazilian Portugese is a different language from Portugese. The issue is more complex than it sounds, and we chose to go in a different direction than other Wikimedia communities, which was within our rights but also required explanation. Our reasoning satisfied everybody except for this one participant, who was making it difficult for us to move forward.

We tried engaging with him in a number of different ways, but nothing worked, and I decided at some point that we just had to do our best to ignore him. As it so happened, Philippe, our facilitator, was going to Brazil to meet with community members there, and I asked him to look out for this one participant just in case.

While Philippe was in Brazil, the participant’s demeanor abruptly changed, and he became one of our most constructive contributors. I asked Philippe what happened. “I just talked to him for a bit,” Philippe said. “He was really great — whip smart and very nice. Oh, by the way, he’s 14.”

I got a good laugh out of that. I had envisioned him as a large, cantankerous man in his 50s, and I was probably communicating with him as such. Knowing his age wouldn’t have changed my respect for him, but it would have helped me engage with him more productively.

Everybody is people.

Earlier this year, I was helping a practitioner at a large company design a high-stakes offsite for the leaders of one of its divisions. They had been having intense friction, and they were hoping to work through it at this offsite. This practitioner’s instinct was to schedule a 30-minute working lunch, because… well, that’s what they always did, and they had a lot to cover.

I pushed back. I generally treat lunch and breaks at my meetings as sacred time — time to break bread, to reconnect with each other, to rest and reset. I doubted that the extra 30-minutes would result in substantial progress, but I was certain that not taking a break would detract from the rest of the day’s conversations.

To this practitioner’s credit, she not only embraced my feedback, she made some surprising suggestions. Instead of giving them an hour for lunch, why not give them 90 minutes? And instead of hosting a lunch, why not encourage them to go into the city and eat out together? All of these leaders were used to eating at their desks or in meetings during lunch. Going out would feel different.

We went with her idea, and we had our meeting. I facilitated the conversation using my mindset cards, and I felt like I was on top of my game. It was as intense as we expected, but it went well overall. At the end of the day and in our evaluations, our participants had many good things to say, including appreciations here and there about the mindset cards and about my facilitation.

However, the one thing everyone kept mentioning over and over again was the lunch. Everybody loved how spacious it was, the conversations they got to have with their peers that they never had otherwise. Everybody loved getting out of the meeting room and spending time in the city together. It led into a surprisingly deep conversation about why they didn’t always do this and how they might start.

Six weeks later, I checked in with the practitioner to see how things were going. The team was still having issues, but there were signs of progress here and there. The biggest takeaway from our meeting that had stuck? It wasn’t the mindset work that I had so expertly facilitated. It was the long, luxurious, so-unproductive-it-was-productive lunch. People were going out to lunch together more often. People were scheduling more lunches with their teams and protecting lunches in their meetings.

Everybody is people.

I’ve been helping groups collaborate more effectively for 16 years now. Many of these projects have been extremely complex, which has helped me develop lots of sophisticated skills. I’m proud of these abilities, I have no doubt that they make me a much more effective practitioner, and I work hard to continue to develop them.

But in reflecting on my work over the years, the skill that has undoubtedly had the most impact has been remembering that everybody is people. It’s simultaneously obvious and extraordinary and humbling to realize this. We all understand this at some level, because… well, everybody is people. However, we often forget to incorporate this into our work. We are dazzled by stories of perseverance through difficult circumstances, our ability to “suck it up” or “tough it out,” and rather than optimize our work to help us all be at our best, we create circumstances that require us to be superhuman to succeed and that punish us when we’re not.

This is lunacy. Sadly, it’s all too common.

I don’t think it has to be this way. I think all of us have the power to make changes that will impact our groups in positive, sometimes profound ways, if we just remembered that everybody is people. It starts by looking at ourselves, by asking what we need — as people — to help us be at our best. Maybe there’s something simple that we can do that doesn’t depend on anyone else, whether it’s remembering to eat breakfast or to welcome someone else on your team. It doesn’t have to be hard, but it will make a big difference.

After all, everybody is people.

Thanks to Amy Wu for reviewing an early draft of this post.

Investing in and Designing for Trust

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.

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

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:

Find a partner.
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:

Play Tic-Tac-Toe without pen or paper again, except, this time, play on a four-by-four board — four rows, four columns.
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.

Take all of the people in your group, and have them sit on their hands and in a circle.
Have one person get up and spend a few minutes describing what the group is doing and thinking, and why.
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!

Maximizing Collective Intelligence Means Giving Up Control

Today marks the 45th anniversary of the Mother of All Demos, where technologies such as the mouse and hypertext were unveiled for the first time. I wanted to mark this occasion by writing about collective intelligence, which was the driving motivation of the mouse’s inventor (and my mentor), Doug Engelbart, who passed away this past July.

Doug was an avid churchgoer, but he didn’t go because he believed in God. He went because he loved the music.

He had no problem discussing his beliefs with anyone. He once told me a story about a conversation he had struck up with a man at church, who kept mentioning “God’s will.” Doug asked him, “Would you say — when it comes to intelligence — that God is to man as man is to ants?”

“At least,” the man responded.

“Do you think that ants are capable of understanding man’s will?”

“No.”

“Then what makes you think that you’re capable of understanding God’s will?”

While Doug is best known for what he invented — the mouse, hypertext, outlining, windowing interfaces, and so on — the underlying motivation for his work was to figure out how to augment collective intelligence. I’m pleased that this idea has become a central theme in today’s conversations about collaboration, community, collective impact, and tackling wicked problems.

However, I’m also troubled that many seem not to grasp the point that Doug made in his theological discussion. If a group is behaving collectively smarter than any individual, then it — by definition — is behaving in a way that is beyond any individual’s capability. If that’s the case, then traditional notions of command-and-control do not apply. The paradigm of really smart people thinking really hard, coming up with the “right” solution, then exerting control over other individuals in order to implement that solution is faulty.

Maximizing collective intelligence means giving up individual control. It also often means giving up on trying to understand why things work.

Ants are a great example of this. Anthills are a result of collective behavior, not the machination of some hyperintelligent ant.

In the early 1980s, a political scientist named Robert Axelrod organized a tournament, where he invited people to submit computer programs to play the Iterated Prisoner’s Dilemma, a twist on the classic game theory experiment, where the game is repeated over and over again by the same two prisoners.

In the original game, the prisoners will never see each other again, and so there is no cost to screwing over the other person. This changes in the Iterated Prisoner’s Dilemma, which means there’s now an incentive to cooperate. Axelrod was using the game as a way to try to understand the nature of cooperation more deeply.

As it turned out, one algorithm completely destroyed the competition at Axelrod’s tournament: Tit for Tat. Tit for Tat followed three basic rules:

Trust by default
The Golden Rule of reciprocity: Do unto others what they do unto you.
Forgive easily

Axelrod was intrigued by the simplicity of Tit for Tat and by how easily it had trounced its competition. He decided to organize a followup tournament, figuring that someone would figure out a way to improve on Tit for Tat. Even though everyone was gunning for the previous tournament’s winner, Tit for Tat again won handily. It was a clear example of how a set of simple rules could result in collectively intelligent behavior, highly resistant to the best individual efforts to understand and outsmart it.

There are lots of other great examples of this. Prediction markets consistently outperform punditry when it comes to forecasting everything from elections to finance. Nate Silver’s perfect forecasting of the 2012 presidential elections (not a prediction market, but similar in spirit) was the most recent example of this. Similarly, there have been several attempts to build a service that outperforms Wikipedia by “correcting” its flaws. All have invoked the approaches people took to try to beat Tit for Tat. All have failed.

The desires to understand and to control are fundamentally human. It’s not easy to rein those instincts in. Unfortunately, if we’re to figure out ways to maximize our collective intelligence, we must find that balance between doing what we do best and letting go. It’s very hard, but it’s necessary.

Remembering Doug today, I’m struck — as I often am — by how the solution to this dilemma may be found in his stories. While he was agnostic, he was still spiritual. Spirituality and faith are about believing in things we can’t know. Spirituality is a big part of what it means to be human. Maybe we need to embrace spirituality a little bit more in how we do our work.

Miss you, Doug.

Artwork by Amy Wu.