How to Run Collaborative Projects That Don’t Fall Prey to Bureaucracy

This piece was published at Sharable on July 21st, 2017.

Today, when people call something “bureaucratic,” they usually mean that in a negative sense, but bureaucracy didn’t always have this negative connotation. About 100 years ago when many professional bureaucracies were being built, they were seen as a means of bringing quality control, predictability, and integrity to administrations. But bureaucracy has taken on a life of its own since its inception, and now is often viewed as self-perpetuating itself in thoroughly mediocre and banal ways. People today hear “bureaucracy” and think of the opposite of innovation. They think of something driving up the cost of healthcare and education, suppressing economic activity, and turning social change organizations into risk-averse, hierarchical, and uninspired mini-corporations.

In my work experience, I’ve seen prestigious nonprofit organizations and government agencies with tremendous resources at their disposal rendered useless in the face of overwhelmingly inefficient and convoluted bureaucratic processes. I’ve also seen activist groups with tremendous grassroots energy dominated, subdued, and balkanized by bureaucratic tendencies among their members.

I’ve met my fair share of people pursuing excellence within organizations — big and small — who have to quit (or are fired) because they’re too frustrated by the intractable dynamics they find themselves embedded within. They generally choose to go in one of three directions: pursue freelance work that allows them to serve clients directly, create a startup that they promise won’t fall prey to bureaucratic bloat, or join grassroots groups that never develop administrative capabilities. I’ve done all three and often tried to combine approaches to arrive at a scalable organizational format that doesn’t develop a mediocre bureaucracy but does have the ability to provide dependable, quality-controlled services. The best format I’ve encountered for doing this is a project-based “spokes council,” which the P2P Foundation describes as follows:

“The spokes council model allows for mediation between autonomous working/affinity groups, or nodes within the network, and the larger institutional body. … These collectives meet separately with varying degrees of regularity. Some groups are relatively inactive while new ad hoc groups may spring up spontaneously to face a particular challenge. Several groups maintain their own listservs and wiki pages.”

In my experience, there is one glaring problem with a conventional spokescouncil model — the “affinity groups.” Affinity is nice, but it’s a very broad reason for people to come together. At Occupy Wall Street, where I first encountered this organizing model, “groups” didn’t stay healthy for very long. They often lost their way, became unproductive, and hosted lots of  internal conflicts between members. Groups that formed around an area of interest (ex. visions and goals) became unproductive and collapsed much faster than groups based around an action (ex. kitchen). Interest-based groups attracted people who felt entitled to participate in decision-making processes both internal to the group and within the council as a whole, while action-based groups just wanted to get the meetings over with so they could do the actual work. Ultimately, a few dysfunctional groups ruined the entire council’s capacity to make good decisions.

Occupy Sandy, which took place about a year after Occupy Wall Street, worked a bit differently. We recognized the flaw in a council of affinity groups and instead organized a spokes council around projects. Project members, unlike group members, had to agree to maintain a membership list, vouch for their members, and articulate success metrics that the group had to meet to remain in good standing with the council. Those elements made a world of difference. The Occupy Sandy Project Council successfully managed hundreds of thousands of dollars through a consensus-based process that, while sometimes contentious and stressful, actually succeeded in allocating funds to impactful projects in transparent ways that won the respect of myriads of people — from city officials to direct action organizers. I’ve been trying to translate this “project spokescouncil” approach to other types of organizations ever since, with some success.

Here’s how I’ve been applying these principles:

  • Instead of creating an “organization,” create a charter that explains how to run a network.

  • Instead of figuring out all the things you want your organization to do, find people already doing these things and invite them to join your network.

  • Instead of creating a central administration to run the network, encourage projects to commit to performing the various functions needed to sustain the network, including administrative ones.

One of the great features of the project spokescouncil approach is that participating projects don’t have to agree on anything more than a charter. For-profits, nonprofits, cooperatives, coalitions, grassroots projects, and other groups can all coexist without forcing their processes on each other.

After Occupy Sandy, I became involved with the Sahana Software Foundation, a nonprofit organization that makes open source disaster management software. After serving on the board and advocating for the project spokescouncil organizational model, I was elected president to implement that vision. Before this model was employed, the CEO of the organization made the financial decisions. One of the goals of our organization was to develop a center that could be a powerful force for advocating for open source practices in the humanitarian sector. That type of center costs a lot of money, which meant we needed to bring in a lot of revenue to support its development. When funding fluctuates, as it tends to do when your business model is doing contract work for other NGOs, life can become very stressful and organizations undergo a lot of stress.

My approach was different. My first questions was: What is the minimum amount of expense we need to incur to keep the organization functional? That became the budget of the “Operations” project. Then we went to the main areas of activity within the organization, and encouraged the people doing that work to reframe it as an autonomous projects within the Sahana Software Foundation. That was easy for the open-source software project, which had a very clear output. It was a bit more complex for our other programs which combined research and implementation of technical systems to make change. After a few months of conversation around how the project could become more autonomous and defined, a new project was formed. Each project then created its own budget, and collaboratively determined who gets which portion of the funds to be spent.

Since we don’t have a CEO anymore, just a president who works part-time on the Operations Project, it freed up more money up to be collaboratively spent by other projects. So far so good. Our transparent, distributed, counter-bureaucratic process has become attractive to other open-source humanitarian projects that often find themselves either unincorporated or sponsored by a conventional, bureaucracy-driven organization. We can offer an organizational home that functions like an open-source project. We also offer a clear process that facilitates collaboration between member-projects while mitigating against the subtle power dynamics of conventional organizations and the bureaucracies that inevitably arise within them. Instead of having a bunch of folks with relatively ambiguous titles and hierarchies, we’re all equals representing projects in a council. That keeps things simple.

My dream is to add more open-source humanitarian aid projects, such as CrisisCleanup, to the Sahana Project Council, and to spread this organizational model to groups working in other sectors. If many project councils emerge, with similar charters and similar processes, then it will become much easier for projects to find the organizational homes they need, and it will also allow projects to move between organizations with ease. This last characteristic is key. Projects develop organically but organizations don’t. Organizations have inflexible budgets and staffing and have to worry about grant cycles and the politics of fundraising. Projects are different. They can be extremely responsive and flexible, and can pivot to meet immediate needs and transform to rapidly scale their best ideas. But as projects develop, they’re often pressured by their host organization to do so in ways that fit within the needs of the host organization. And moving a project from one organization to another is often practically impossible. But with a project council, projects have options and moving from one organization to another can be a breeze. Indeed, we might discover that, without the limitations and structures imposed by organizations, projects can become the core organizational unit of the production process of an increasingly networked world.

Imagine if there were a “project standard” that people could use to form and document their work, and then the project could seamlessly move between councils as conditions and collaborations change. Could this be an alternative to the bureaucratic organizational format that currently runs the world? We’re going to find out. Stay tuned.

Header photo of Occupy Sandy spokescouncil meeting by Devin Balkind

Occupy Sandy and the Rise of Open Aid at AIANY on 9/10/16

The AIANY invited me to present my perspective on Occupy Sandy at their event “Stand Up! How to be Part of the Solution after a Disaster.” My presentation argues that Occupy Sandy, and the mutual aid work of its predecessor Occupy Wall Street, were physical-world manifestations of the “Open Aid” trend taking place in the disaster relief and humanitarian aid sectors.

The presentation begins by pointing to the fact that “faith in institutions” is at an unprecedented low in the USA at the same time as our economy is being transformed by widespread access to networked communication technologies. These technologies enable autonomously organized, local grassroots disaster response efforts to network with each other to create a new type of entity that the Department of Defense is calling “Grassroots Disaster Relief Network” (GDRN). In the virtual world, networked communication technologies are also allowing people with specialized technical skills to organize themselves into groups that can provide information processing services through a wide variety of tools including social media, GIS and collaborative documents. These groups are called Volunteer Technical Communities  (VTCs).

I argue that GDRNs are a local/physical manifestation of the “Open Aid” concept, and VTCs are a global/digital one. Currently VTCs tend to serve formal response organizations such as UNOCHA, but in the not-too-distant future  they’ll be able to collaborate directly with GDRNs, giving disaster survivors and their communities unprecedented access to information.

The presentation ends with some suggestions for how we can set up simple, open source systems to streamline information flows related to disasters.

I gave a very similar presentation to disaster response personnel at the Disaster Preparedness Exchange in Indianapolis a week later.