Spokes Council Model

From P2P Foundation
Jump to: navigation, search


Devin Balkind:

"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." (http://www.shareable.net/blog/how-to-run-collaborative-projects-that-dont-fall-prey-to-bureaucracy)


Victor Pickard:

"The Seattle IMC follows a spokes council model that was first perfected during the 1999 WTO protests by the Direct Action Network (DAN), a loose coalition of hundreds of activist groups. The spokes council model has its roots in the anarchic affinity model, an institutional structure initiated by anarcho-syndicalists during the Spanish Civil War, and is characterized by small groups loosely coordinated via temporary representatives chosen by group consensus. The spokes council model allows for mediation between autonomous working/affinity groups, or nodes within the network, and the larger institutional body. This model is seen at work both at the local IMC collective and the global network*/the latter based on the notion that sustainability for large networks like Indymedia depends on this less bureaucratic and more collectivist system. Accordingly, Seattle’s IMC institutional structure is based on a non-hierarchical collective comprising nearly a dozen smaller volunteer collectives, or working groups, including editorial, finance, liaison, spokes council, media, space, and tech. 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 theory, representatives from each working group are empowered by the general Seattle IMC collective to become ‘‘spokes’’ within the ‘‘spokes council,’’ which acts as an organizing and coordinating body authorized to take action when decisions need to be made more rapidly. The Seattle IMC collective as a whole may also delegate additional projects or responsibilities to the spokes council. A core group is appointed by the general collective to serve limited terms. This raises potential problems with hierarchy formation, so there is a frequent turnover of positions. Although consensus for spokes nominations is usually a smooth process, Polletta (2002) identifies the potential challenge for a token leadership position as a common pressure point where the consensus process may falter, especially since often no default voting procedure is in place." (http://www.victorpickard.com/upload/rcsm157052.pdf)