There’s this ongoing sense of frustration from the adaptive, iterative, inclusive informal side of disaster response with the formal side. While we often focus on how to get members of a population not accustomed to collaboration to feel empowered to speak and act, and that is a core component of any work I do, that’s not what this entry is about. In the same way that I think many people don’t engage in their environments when conflict is a possible component, I think the lack of collaborative and codesign approach in the formal sector is simply a lack of exposure and understanding.
Come with me / and we’ll be / in a land of pure collaboration – sung to the tune of Willy Wonka’s “Pure Imagination“
The thing to understand is that after Kindergarten, most people have been discouraged from being collaborative. While it comes easily in our youth, when we haven’t built up the skills (social and technical) to operate from that source, it can be difficult. When creating codesign space with members of a formal or traditional organization, they come with the mentality that experts are the best (and perhaps only) people equipped to know how to assess and respond to a challenge. In this mentality, only academics have time to think, only corporations have access to resources, and only people who have been in the field for decades can see patterns. Often, because of the constructs around being an expert or specialist, people considered as such have had difficulty finding cohorts. In fact, you’re often actively discouraged away from it – anyone who shares your field is a competitor for limited resources. Any remotely collaborative activity is done asynchronously and piecemeal, cobbled together later by yet another specialist. This backdrop should indicate the importance of providing safe and guiding space for learning collaborative methods to those coming from traditional sectors. Here’s how I’ve done collaborative space-making in the past.
First, we must understand the codesign methods we aim to use by making it safe and inviting to work collaboratively, and ways to ask questions and with the expectation of listening. We call this “holding space,” through facilitation methods of encouraging inclusivity like paying attention to equal speaking time and accessbility of language. Within this space, we set a North Star, the purpose of the group. Frame all conversations and problem solving trajectories by that North Star.
With the Field Innovation Team (FIT) for FEMA’s Hurricane Sandy response, our North Star was “helping members of the affected population.” This might seem obvious, but formal organizations have been set up to help the official response organizations – Office of Emergency Management, or Red Cross, or the local police department. This has happened in the past because of scaling issues of knowledge and delivery abilities. Any situational knowledge was based upon limited aerial imagery (difficult and expensive), people who were in the area but are now able to report by being in an office (stale information), and past experience (misaligned patterns).
With things like crowd mapping, a higher resolution of situational awareness is possible. People on the ground can tell you where they are and what they see. With this ability comes a new responsibility, to deliver response at a similar resolution. This setup also includes an ability to directly interact with members of the affected population, so it’s important to refocus our efforts on our end users.
Any time any question came up, or any difficulties got in our way, we reminded ourselves about our main objective. From this, we immediately saw many paths to achieving the objective such as education, housing, heat, and connectivity. Through skill and connection discovery, we determined what the best focuses were, based on the team members present. We were already collaborating – by focusing on a main objective, and outlining various ways of achieving that objective, people start to consider how they can offer ways of getting there. Too often, we delineate our jobs and then figure out what we can do – which would have limited our creativity by leaps and bounds.
This is when it’s important to have a slew of collaborative tools in your back pocket. What will kick up this new track of collaboration with productivity? Just as importantly, what will be so easy to use that your newly-fledged collaborators won’t trip over install processes or learning curves, losing this precious momentum towards beautiful new worlds? I really like etherpad, hackpad, or google docs as a starting point for this: nearly everyone uses a word processor, and it’s immediately evident as to what is going on. Suddenly, there is a shared view! The common problem of resolving differences across multiple word documents has disappeared in this setting! Reports begin to write themselves out of meeting notes! Butterflies and bluejays are frolicking in the sky. Be wary that during this part of the process, it is important to both make sure people understand what is going on, while also not becoming their administrator. Help people put their own information into the platform, don’t do it for them when they stumble. Other great platforms are trello, basecamp, and loomio for near-immediate recognition of usefulness. People will sometimes stumble in the transition – simply take their recent update on the old method (email, anyone?) and continue the discussion on the new collaborative platform.
Once that objective is set, everything else is just problem solving. Things which would have kept us waiting to act instead became new opportunities to try things out.
Back in New York, the Joint Forces Office wouldn’t allow the FIT team in, because not all of us were federal employees, a few of us were foreign, and some of us were *cough* activists */cough*. Instead of twiddling our thumbs, we instead worked from the apartment of a friend-of-mine. They had better (and more open) internet, far superior coffee, and great serendipity liklihood. While working from there, we linked the OccupySandy volunteering map into the Google Crisis Map and (unofficially) chatted with UNICEF about what options we hadn’t yet looked at for resources. The neutral space allowed us to accomplish far more than we would have in the official offices. It also meant that as we tried out collaborative tools, firewalls didn’t get in our way. When we were later welcomed into the official offices for their first-ever design jam (with Frog Design!), the indignation about Basecamp and hackpad not loading was so great that the FEMA firewalls are now on different settings!
Remember that people are delicate. What most people in the formal sector have been missing for a long time is the ability to SPEAK and to ACT, just on a different vector than those in historically marginalized populations. We are asking all parties in the codesign process to be active and engaged. In distributed and collaborative spaces, this is something we excel in. It is therefore our responsibility to show all newcomers how awesome it can be. Stand with them to make more space. Sometimes as manifest in blanket forts.
Brilliant piece, I’m glad Berkman email came today. We’d love to have you stop by Peeragogy in Action on Google+ sometime and chat – we have a +Hangout on Mondays at 1 pm and welcome new folks.
I like thinking about this in terms of the way a car works. You can model the steering and drive system with classical mechanics. But you ultimately need to model the engine with statistical mechanics and chemistry. You get in a new car and start driving and usually it works the way you’re used to. This is how it works with other “formal” systems. You queue here, sign there, pay your fee, and it’s all done. With informal systems, it’s messier. Yes, the car’s engine has a detailed diagram, and for a mechanic, it’s just another “formal” system. And, yes, the streets at rush hour can get messy. But the broader point is that however it appears, “formal” is something that people tend to be more comfortable with. “Informal” is bound to be messy. As a system designer or co-creator, you want to build something that will usually “just work” – like Etherpad, or like the coffee pot. But in order to design a collaborative system, you want to bring in enough messiness to let new and unexpected features emerge – like the serendipity likeliness that you mentioned.
(Note: some people find the description I’ve just given to be confusing, so I hope I’ve managed a reasonably clear description this time.)
And PS. I second Charlotte’s invitation to join us for one of our Peeragogy in Action meetings!