Code for America – Faster Than 20

Do-It-Yourself Strategy and Culture

In 2009, I was asked by the Wikimedia Foundation to design and lead a movement-wide strategic planning process. The goal was to create a high-quality, five-year strategic plan the same way that Wikipedia was created — by creating a space where anyone in the world who cared could come and literally co-author the plan.

We had two fundamental challenges. First, it wasn’t enough to simply have a plan. It had to be a good plan that some significant percentage of the movement both understood and felt ownership over.

Second, we were asking people in the community to develop a strategy, but most people had no idea what strategy was. (This, frankly, is true of people in general, even in business.) It was different from Wikipedia in that most people already have a mental model of what an encyclopedia is. We had to be more concrete about what it was that we were asking people to do.

I explained that strategic planning, when done well, consists of collectively exploring four basic questions:

Where are we now?
Where do we want to go? Why?
How do we get there?

I further explained that we were going to create a website with these questions, we were going to get as many people as possible to explore these questions on that website, and by the end of the year, we would have our movement-wide, five-year strategic plan.

And that’s essentially what we did.

Get the right people to explore core questions together. Where are we now? Where do we want to go, and why? How do we get there? Provide the space and the support to help these people have the most effective conversation possible. Trust that something good will emerge and that those who created it will feel ownership over it.

This is how I’ve always done strategy, regardless of the size or shape of the group. It looks different every time, but the basic principles are always the same. People were intrigued by what we accomplished with Wikimedia, because it was global and primarily online, because we had gaudy results, and because Wikipedia is a sexy project. However, I was simply using the same basic approach that I use when working with small teams and even my own life.

The craft of developing strategy is figuring out how best to explore these core questions. It’s not hard to come up with answers. The challenge is coming up with good answers. To do that, you need to give the right people the opportunity and the space to struggle over these questions. That process doesn’t just result in better answers. It results in greater ownership over those answers.

Breakfast and Culture

What’s your strategy for eating breakfast in the morning?

Are you a grab-and-run person, either from your own kitchen or from a coffee shop near your office? Eating breakfast at home is cheaper than eating out, but eating out might be faster. Are you optimizing for time or money? Why?

Maybe you have kids, and you value the ritual of kicking off the day eating together? Maybe you’re a night owl, and you’d rather get an extra 30-minutes of sleep than worry about eating at all in the morning.

Where do you want to go? Why? How do you get there? These are key strategic questions, but you can’t answer them without also considering culture — your patterns of behavior, your values, your mindsets, your identity. Choosing to cook your own meals is as much a cultural decision as it is a strategic one.

In my past life as a collaboration consultant, groups would hire me to help with either strategy or culture, but never both. I realized fairly quickly that trying to separate those two processes was largely artificial, that you couldn’t explore one without inevitably colliding with the other.

Peter Drucker famously said, “Culture eats strategy for breakfast.” He did not intend to say that one was more important than the other, but that both were necessarily intertwined. Or, as my friend, Jeff Hwang, has more accurately put it, “Saying culture eats strategy for breakfast is like saying your left foot eats your right foot for breakfast. You need both.”

As with strategy, culture work is a process of collective inquiry, except instead of focusing on action (where do you want to go?), the questions are centered around identity:

Who are we now?
Who do we want to be, and why?
How do we get there?

The key to effective culture work is to explore these questions yourself, to struggle over them together as a group, and to constantly revisit them as you try things and learn.

DIY Strategy and Culture

Toward the end of 2013, Dharmishta Rood, who was then managing Code for America’s startups program, asked me if I would mentor one of its incubator companies, which was having some challenges around communication and decision-making. I had been toying with some ideas for a do-it-yourself toolkit that would help groups develop better collaborative habits on their own, and I suggested that we start there.

We immediately ran into problems. The toolkit assumed that the group was already aligned around a core strategy, but with this group, that wasn’t the case. They had been going, going, going without stopping to step back and ask themselves what they were trying to accomplish, how they wanted to accomplish those things, and why. (This is very typical with startups.)

This group needed space to do some core work around strategy and culture. I threw out my old toolkit and created a new one designed to help groups have strategy and culture conversations continuously and productively on their own. The revised toolkit was based on the key questions underlying strategy and culture depicted as two cyclical loops:

While most strategy or culture processes are progressively staged, in practice, inquiry is never linear, nor should it be. Spending time on one question surfaces new insights into the other questions, and vice-versa. Where you start and the order in which you go are not important. What matters is that you get to all of the questions eventually and that you revisit them constantly — hence the two cycles. My colleague, Kate Wing, recently noted the resemblance of the diagram to bicycle wheels, which is why we now call it the Strategy-Culture Bicycle.

Dharmishta and I saw the Bicycle pay immediate dividends with this group. People were able to wade through the complexity and overwhelm, notice and celebrate what they had already accomplished, and identify high-priority questions that needed further discussion. Furthermore, the process was simple enough that it did not require a third-party’s assistance. They were able to do it fine on their own, and they would get better at it as they practiced.

Pleased and a bit surprised by its effectiveness, I asked my long-time colleague, Amy Wu of Duende, to partner with me on these toolkits. We prototyped another version of the toolkit with four of last year’s Code for America accelerator companies, and once again, saw great success.

We’ve gone through eight iterations together, we’ve tested the kit with over a dozen groups and individuals (for personal and professional life planning), and we’ve added some complementary components. A number of practitioners have used the toolkit on their own to help other groups, including me, Dharmishta, Amy, Kate, and Rebecca Petzel.

I’m thrilled by the potential of toolkits like these to help build the capacity of practitioners to act more strategically and to design their aspired culture. As with all of my work, these toolkits are available here and are public domain, meaning that they are freely available and that you can do anything you want with them. You can also purchase pre-printed packages.

Please use them, share them, and share your experiences! Your feedback will help us continuously improve them.

Predicting Ferguson: Data, Visualization, and Systems Thinking

Last night, a St. Louis grand jury decided not to indict Ferguson police officer, Darren Wilson, for the shooting death of Michael Brown. If there is a silver lining to this decision, it’s that the discourse around these events has been predictably emotional, but perhaps unpredictably thoughtful. I’ve seen and been a part of a number of conversations that have asked hard, critical, systemic questions about why this happened and what needs to change.

Why is it that black men are 21 times more likely to get shot dead by police than white men?

Why did the Ferguson verdict feel predictable, despite the mountain of evidence against Wilson?

What can we do to improve the system?

Code for America is an amazing group that organizes a powerful network of technologists, designers, data scientists, and concerned citizens to help create a government that is truly for and by its people. Shortly after the shootings, its staff started asking what it could have done to prevent another Ferguson. As Jen Pahlka, Code for America’s Executive Director, shared at its annual summit this past September, there were clear, data-driven indicators that something was majorly amiss in Ferguson.

Simply sharing data in this form doesn’t solve any problems. The trust-building and structural changes that Jen described are the hard nuts that need to be cracked. But having the data so clearly and powerfully expressed in real-time would, at minimum, have jolted us. It would have been clear, indefatigable evidence that this is something to which we need to pay attention.

The low-hanging fruit of systems change is to provide better, faster feedback mechanisms. Technology in today’s networked world offers one way to do that. But what ultimately matters when it comes to feedback isn’t information. It’s good, old-fashioned, person-to-person connectivity. It’s our need to talk to each other, to see each other as humans, to really understand what it is to walk in each other’s shoes.

We don’t need technology to have that conversation. We don’t even need new people (although that would help a lot). Start with the people around you. Talk to them about Michael Brown, about Darren Wilson, about tragedy and injustice, but also about the world we want to live in. Talk to them about what it’s like to be rich or poor, black or white or Asian or Latino in this country. Most importantly, talk about love — what it looks like, what it means to you and them, and what the world would be like if there were more of it.

My friend, Lauren Crew, a brilliant photographer who documented the protests in Oakland last night, shared these wonderful words from Richard Rorty:

My sense of the holy… is bound up with the hope that someday, any millennium now, my remote descendants will live in a global civilization in which love is pretty much the only law.

The Secret to High-Performance Collaboration: Slowing Down

At my previous consultancy, we used to spend a considerable amount of time debriefing every engagement, big or small. We were meticulous in our analysis, nitpicking every detail.

Over time, I started noticing a few patterns. First, I realized that our debriefs were largely ineffective, because we weren’t taking the time to integrate what we learned. We needed to be reviewing past debriefs before new engagements in order to remind ourselves of what we had learned and in order to hold ourselves accountable to improvement. Without that additional space, our debriefs were essentially exercises in self-criticism and generating lists, two skills we didn’t need to be practicing.

Second, a few things began to jump out at me as I reviewed our long list of things we could have done better. Almost without fail, when we had “bad” engagements, someone had slept poorly the night before. Or someone had been working while sick. Or someone had forgotten to eat breakfast that morning. (Forgetting to eat was my personal bane.)

We had spent hours and hours and hours debriefing, and this is what we learned:

When we didn’t take care of ourselves, our performance suffered.
When we didn’t take time to remind ourselves of past lessons, we repeated the same mistakes.

One of my mentors, Gail Taylor, is always encouraging me to seek the simplicity embedded in complexity. What I’ve realized over the years is that, when I find it, I often dismiss it. It seems too obvious. There has to be something else.

Slowly, but surely, I’m breaking this habit, and I’m starting to see more clearly as a result. Which brings me to my biggest insight over the past several months.

The best thing we can do to improve collaborative effectiveness is to slow down.

This has been coming up for me over and over again with all of my recent projects and experiments.

I’m currently doing an experiment with the Code for America incubator in trying to help new companies establish good collaborative habits right from the start. PostCode (the company with which I’m working) is working at a startup pace, and they’ve had inevitable challenges as they move through their storming phase.

Fortunately, when problems crop up, they deal with them quickly. In those situations, they’ve often reached out to me about possible toolkits to help them navigate their challenges. My answer has been consistent: Slow down. They haven’t found the time (beyond the work we’ve done with them, which has been too constrained) for critical conversations about organizational strategy, culture, and group dynamics. It’s understandable. They’re under a tremendous amount of pressure, and in those situations, conversations about strategy and group dynamics can feel like a nice-to-have, not a need-to-have.

Last week, I facilitated a practitioners workshop for the Garfield Foundation on collaborative networks. For one of the Open Space sessions, I led a group through the power workout I developed for Changemaker Bootcamp. We had a wonderful, nuanced conversation about power dynamics, and several people asked, “How do we make sure we have more of these conversations with our constituencies?” My response: “The first step is making the time.”

Telling others (or even yourself) to slow down is easy. Actually doing it is hard. We move fast because of external pressures, mindsets, habits, cultural norms, and so forth. We have little control over most of these things, and what little we can control is incredibly hard to change. But there are tricks that I’ve found helpful over the years.

Experiments. Changing habits is hard, and you will likely fail many times. Approaching the challenge of slowing down as a series of experiments helps. As I wrote previously, one of the keys to a successful experiment is to hold yourself accountable to the results. Failure is okay as long as you’re committed to the intention and are actively incorporating what you learn into new experiments.

If you are truly committed to slowing down, write it down. Write, “Slow down,” on a piece of paper, and put it up where you will see it. Actively devise and track experiments that will help you do this, so that you can monitor your progress and see what’s working and what’s not.

For important conversations — whether it be organizational strategy or a project debrief — schedule those in advance as part of your project plan, and track whether or not they actually happen. If they don’t happen, take the time to examine why, and devise another experiment. The beauty of applying an experimental framework is that simply the process of devising and tracking an experiment is an act of slowing down.

Checkins. My former business partner, Kristin Cobble, recently wrote a wonderful piece on the power of checkins. She describes them mostly in the context of meetings as a way to invite participation and to garner a sense of the collective whole. What I’ve learned over the past several months is that they also serve a much simpler, deeper function. They force you to slow down and reflect — even if just for a moment.

Starting last year, I embarked on a simple experiment with my friend, Seb Paquet, who’s based in Montreal and who, like me, works for himself. We decided to check in with each other once a week for an hour over Skype. We didn’t have any agenda. We would simply use that time to have an extended checkin.

We ended up doing two phases, and it served to be tremendously valuable. Not only did it deepen our relationship, it served several practical purposes. We both had an opportunity to give each other feedback on our respective projects. We supported each other when we faced challenges and cheered each other when we succeeded. The most interesting thing to happen was that, even when things got tremendously busy for both of us, we both stayed very committed to these checkins. They were not just nice-to-have; they were helping us work more effectively.

Inspired by these results, I invited my colleagues Pete Forsyth, Rebecca Petzel, Odin Zackman, and Amy Wu — who all work independently — to participate in a similar experiment earlier this year. We wanted to experiment with ways that we — as an informal network — could achieve the same (or better) benefits that people get from working in great organizations. In particular, we wanted to be more intentional about learning from each other. We called our experiment, Colearning 2.0, a play on the coworking movement.

We explored several things that we could do together, but we settled on doing weekly pair checkins, as Seb and I had done beforehand. There was some reluctance at first. One thing we all had in common was a frequent feeling of overwhelm, and taking an hour out of our week to “just talk” seemed burdensome. Not only did everyone end up finding the experience valuable, there’s a desire to continue the practice and take it to the next level.

I recently spoke with Joe Hsueh about his recent trip to Istanbul. One of the things that struck him the most about his trip was the adhan — the Islamic call to prayer. Imagine being in a bustling city of 14 million people where every day, at prescribed times, a horn sounds and the entire city goes silent. Imagine what it feels like to have that regular moment of collective, silent reflection.

I believe that checkins could be a powerful keystone habit that helps us slow down overall, which ultimately helps us collaborate more effectively. This is a hypothesis I continue to explore.

What helps you to slow down? What’s been the impact of doing so?

The Key to Effective Learning? Soap Bubbles!

Part three of a three-part essay on facilitating group learning. See parts one, “Getting real about experiments and learning,” and two, “Documenting is not learning.”

Two months ago, I blogged about my experiment with Dharmishta Rood and the Code for America Incubator, which wraps up in another few months. The goal is to help startups — in this case, a company called PostCode — develop great collaborative habits in its formative stage. The theory is that it’s more effective to build good habits from the start than it is to try to change bad habits later.

About a third of the way into our experiment, Dharmishta and I started discussing whether or not we thought it was working. We thought that it was, but we weren’t sure whether or not the folks at PostCode would agree. “We’re missing soap bubbles,” Dharmishta asserted.

“Huh?!” I responded.

Soap, Dharmishta explained, does not naturally produce bubbles. Manufacturers add chemicals to make soap lather, even though the resulting bubbles have no impact on cleanliness. In fact, some chemicals have adverse effects, such as drying out skin.

Why do they do this? Because people associate bubbles with cleanliness. If we don’t see the bubbles, we assume it’s not working, regardless of whether or not that’s the case.

When assessing progress, how you feel matters.

If you’re learning, and you feel like you’re learning, then all is good.
If you’re learning, but you’re not feeling like you’re learning, then you have a problem. You may stop doing things that are working, because you don’t realize that they’re actually effective. This is where adding soap bubbles can be useful.
If you’re not learning, but you feel like you’re learning, then you also have a problem. There is where adding soap bubbles can be harmful.

Given this, how do you design soap bubbles into your learning processes that help, rather than harm you?

It starts by being real about what you can and can’t measure, and it quickly shifts to remembering what you’re trying to achieve in the first place. There is always an intention underlying our instinct to measure, but sometimes, the complexity around measurement causes us to forget that intention.

I’m generally trying to help groups learn how to collaborate more effectively. I want feedback mechanisms that reinforce good habits and discourage bad ones. In PostCode’s case, Dharmishta and I wanted to make sure that the team was communicating and making decisions effectively. We thought that we were seeing progress, but we weren’t sure that the team was seeing the same things we were. We were (and still are) worried that the team would discard the practices before they became habit.

We designed a monthly “assessment” to help PostCode track its progress, and when we started exploring ways to measure effectiveness around communication and decision-making, we decided to take a different approach. Rather than attempting to quantify those things (as we were doing with the other dimensions we were tracking), we decided to ask qualitative questions:

Please share up to three examples of great, effective communication over the past month.
Please share up to three examples where communication could have been better over the past month.

(We asked the same questions about decision-making.) These questions will not provide some “objective” measure of how well the company is communicating as a whole or whether or not it is improving over time. However, they will:

Encourage everybody to regularly pause and reflect
Surface people’s different perceptions of what is good and what is not
Identify problems that need fixing while they’re still fresh
Remind people to celebrate what’s going well

Most importantly, these questions will remind everybody that communication matters, and that they should be practicing consciously and with an eye to improve. The very act of pausing to answer these questions on a monthly basis means that they are. These questions act as soap bubbles, but they also help clean!

Measurement is important, but feedback is even moreso. Figuring out the right things to measure is hard, but creating feedback mechanisms is not. Soap bubbles may not give you objective indicators for tracking progress, but they will — at minimum — remind people of what they’re trying to accomplish and to be conscious of when it’s happening.

Photo by Umberto Salvagnin. CC BY 2.0.

Organizational Development as Product Design

I got my start in the tech industry. Even though that was a lifetime ago, I’ve carried over many lessons from that experience, and I like to keep one foot in that door. One lens I still carry with me is that of product design.

I’m currently embarking on an experiment with Dharmishta Rood, who runs the incubator at Code for America. The gist of the experiment is this: Changing organizational habits is hard. Starting new habits is easy. If you want to build a high-performance, collaborative organization, the best thing you can do is instill good habits right from the start. Incubators are in a great position to do just that.

Code for America is trying to help local government truly live up to its promise of for the people, by the people. Its central activity is a fellowship program that connects designers and developers with local governments for a year. Think Teach for America for geeks. On the surface, these fellows design innovative applications for local government. On a deeper level, these fellows help change the culture of local government. It’s an amazing organization, and I’ve been a proud supporter for many years now.

Sometimes, fellows want to continue working on their apps beyond the fellowship. Last year, Code for America started an incubator program to help their fellows do just that. One of the many things that Dharmishta does is find mentors and trainings to improve her startups’ chances at success. One of the services she wanted to provide for her current class — a great new startup called PostCode — was help with getting better at collaboration.

I’m looking for ways to scale collaborative literacy. Helping an incubator instill great collaborative habits with civic startups seemed like a wonderful opportunity to do exactly that. The twist was that I didn’t want to do the work. I know how to do that already, and I know that I’m not scalable. Instead, I wanted to see if I could create a toolkit that Dharmishta could implement on her own with some behind-the-scenes coaching on my part. Dharmishta and PostCode both graciously agreed to try this experiment with me.

This is essentially a product design challenge, and it’s been incredibly humbling. We whipped together a prototype in just a few weeks, but I based it on years of experience, and I thought it would be great. It’s been solid so far, but not great. Watching Dharmishta and PostCode work through the toolkit behind-the-scenes has been an exercise in frustration — not with them, but with my own work. It’s uncovered all sorts of flaws and faulty assumptions, and because I’m not the one implementing it, I can’t make adjustments on the fly, which I do regularly in my own practice. It’s providing value, but it’s not living up to my expectations.

Which is exactly the point. Unless you’re incredibly lucky, you’re not going to get it right on the first try. Good product design is about getting your best first guess out there as quickly as possible and learning as quickly as possible based on real world usage. You take your lumps early so that you have a better chance of getting to the right answer quickly (and cheaply).

I wrote in an earlier post:

In order to design an effective tool, [product designers] use powerful methods for understanding how their customers think and feel and for measuring the impact of their interventions. Most process designers would do well to learn the tools of product design.

Most process designers I know have a very limited toolkit. They are typically over-dependent on meetings to accomplish their goals. (The exception to this are folks I know in tech startups, who tend to have more of a — you guessed it — product mindset when developing their own organizations.)

The bigger problem is that most process designers do not spend enough time up-front thinking about how to measure success. This ends up being fine, because most don’t bother to assess their work afterward anyway, outside of a casual, gut-feel conversation with a very narrow set of people.

I can say all of these things without judgement, because I have been guilty of all of these things. Doing these things well requires a tremendous amount of discipline, practice, and boldness. Frankly, I don’t know many product designers who do all these things well either. But on average, I find that product designers have a very different mindset than process designers.

What exactly is this mindset? That you don’t know all the answers. That underneath your considerable experience lies a foundation of faulty assumptions. That the way to learn is to move forward constantly, but thoughtfully, to iterate rapidly, to assess obsessively, and to assume that you will fail many times before you succeed.

This is the approach that I’ve been taking with the “product” that Code for America and PostCode has been using. They are both tremendously busy, but they have been great about playing with the toolkit. PostCode is a company full of product designers, and that mindset is strongly engrained in Code for America’s culture as well. (Code for America is an ardent evangelist and practitioner of the Lean approach, whose chief evangelist, Eric Ries, serves on its board.) They understand the spirit of what I’m trying to do, which has helped me a lot in doing this experiment.

This shared understanding has also helped me explain some principles of organizational development with them. PostCode is grappling with the typical startup challenges — lots of opportunities, but also lots of uncertainty, the need to focus in light of this uncertainty, and the challenges of norming as a team in the midst of the thousands of other things they need to be doing. They need to go fast, but they also recognize the importance of slowing down.

We were discussing the challenges of deciding on decision-making processes, and I latched onto something very wise that one of them said: Sometimes, things will actually work themselves out if you just let them play out. You want to be thoughtful and reflective, but you can’t let that paralyze you. The value of actually trying something, then stopping to reflect, is that now you’re basing your decisions on real data rather than on a bunch of competing, subjective, abstract notions. That’s a product designer’s mindset, and organizational development practitioners would do well to adopt it.

The trick is finding the balance between doing the work and taking a step back, doing the work and taking a step back. That’s what I’m trying to help them do. It’s an incredibly hard balance to learn how to strike. Clients have been hiring me to help them with this for years, yet I found it extremely difficult to do myself when starting up my own company a few years ago. I continue to improve, but I’m still in that cycle of trying and learning.

The Art of the 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:

Literally creating a delightful, inviting space (physical, virtual, or both) in which the group can interact
Developing shared understanding among the group
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!