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