Define voting roles

Goal: visibilize and widen the circle of people voting on decisions, focusing on people closest to the project, which includes those working the most hours on it and most affected by its actions.

In many organizational structures, power is implicit. For example, power consolidates in a pyramid, but it's not entirely clear why or how; influence happens behind closed doors, and how opinions are heard and weighed are shaped by bias.

Although imperfect, voting is the best invention we currently have for visibilizing power. We describe voting as the process through which members choose from specific options on what action should be taken, and their choices, in aggregate, directly affect the action ultimately taken. But invisible powers and all kinds of manipulations also show up in voting, such as in who gets to vote, access gaps, who proposes choices in the first place, or how we interpret results.

We're trying out a decision-making structure that defines types of power in order to more evenly distribute it, make it explicit, and show gradation. It is not meant to answer every question but to give us a transparent starting point. This draft framework will be improved through the Power Project and draws on existing models, such as sociocracies, co-ops, worker self-directed nonprofits, holocracies, participatory budgeting, participatory investing, and more.


Embodying Characteristics 


In the early stages of a project, it needs a “voting charter” documenting structural elements unique to the project. This charter should cover the following topics:

Who sets up voting

Someone must sit down and write the voting charter! And when voting charters are set up, there might be very few people working on the project. So how do you ensure inclusion before teams are in place? For now, we follow the responsibility framework, depending on the studio.

System studio

  • Architects propose voting rights.

  • At minimum, architects, developers, and collaborators must unanimously agree to the voting charter. Agreement from collaborators is preferred. Members can explicitly abstain from voting. 

Venture Studio

  • Creators of the venture propose voting rights.

  • Creators + architects must unanimously agree to the voting charter. All other roles must at minimum influence this strategic decision if they’re in place at project start.

Assign voting roles

Voting roles are intended to surface all the power structures a project may have — not necessarily all the roles it needs. Decision makers are guided by these goals:

  • Distribute power: increase the number of voters involved in a project.

  • Prioritize clarity/transparency: set clear expectations at the outset about what voting roles are.

  • Collaborate and listen: embrace feedback.

  Major Voter Core Voter Owner Team Influencer
Influence choices presented to voters x x x x x
Influence strategic decisions x x x x x
Vote on major strategic decisions presented x x x x  
Vote on all strategic decisions presented   x x x  
Provide info on strategic decisions for voters     x x  
Independently make day to day decisions     x x  
Decide on choices presented to voters     x    

Set targets & sparks

  • Participation: Are you always looking for 100% participation? Why not?

  • Action sparks: What percentage of votes are required to move forward with what type of action? For example, will you move forward without unanimous agreement? How will you communicate and approach disagreement? Are questions always multiple choice between actions that you would plan to take? What happens when compromises are possible?

Votable moments

We need to establish basic procedures for what constitutes a “votable moment,” and how to handle unknowns. Right now, we think about votable moments in 3 ways: content, connection, and context.

Content

  • Does this choice come with a financial expense?

  • Could this choice have a reputational impact that affects anyone in the company?

  • Could this choice be interpreted as a change to the work scope?

Connection

  • Do you think colleagues believe that they should be included in this decision? (Why?)

  • Do colleagues need a sense of ownership over a decision? (Why?)

Context

  • Is there a reason that the decision cannot or should not wait for a vote, such as time sensitivity? (Was that unavoidable? If it was instead due to insufficient planning, what will you do to make sure it doesn't happen again?)

  • Will this decision have an impact of any kind on others? (Whether they know it or not?)

Gathering votes

In our early stages, we are working to treat our charters as worksheets, rather than providing recommendations. Project leads are asked to consider these questions:

  • How often should voting cycles take place? Can it be routine, or does it need to be tied to strategic decisions that don't yet have timelines?

  • How will you communicate about or openly discuss voting issues? How will people know when votes are being taken? How will they receive information to make a decision?

  • How will you gather votes? Are you able to create and disseminate online surveys? If polls occur live, how will you make sure everyone people feels safe expressing their opinions? What happens if your voters turn out is lower than your target?

  • Carry out votes. How will you collate and analyze votes? How will you ensure that dissent is welcome in the choices you provide?

Revisit

In the early stages of a project, it should set milestones to revisit voting roles to verify whether we’re achieving goals of wider participation and incorporate any lessons learned. It may make sense align voting milestones with discussions around the value pool.

Tensions

  • Coupling voting rights with roles is easier: In many organizational systems, decision making frameworks are unstated or partially stated norms in which power is implicitly allocated to people further up in a hierarchy. 

  • Wider inclusion requires sophisticated infrastructure: Enabling more project participants to vote requires our team to effectively communicate choices and background information and have the capacity to gather and assess voting results. This isn't easy when your work isn't fully funded.

  • Not everyone has the time to vote: To vote requires time. This isn't easy when voters aren't fully funded.

  • Not everyone wants to vote!: In the spaces between time, funding, and relationship, some voters opt out because they trust us. We're learning where and how relationships and simple practices of radical transparency shift the voting context.

How We Handle Tensions

Innovations in decision making structures to serve justice are essential to our mission, and the goal of the Power Project. MJN must continue to evolve our voting philosophy according to what we learn and our budget. With funding, we hope to:

  • Develop consistent processes to receive votes or clearer recommendations on how to receive them: Improve our infrastructure to collect votes from larger numbers of people involved in or related to our work.

  • Define key decisions and voting cycles, including setting up clearer worksheets to help project creators build a strong foundation: What counts as a key decision? How often should voting occur — especially considering project participants evolve over time?

  • Improve communication: To make a decision, people need to understand what they're voting for. In order to further distribute power, we need to improve how we communicate goals, challenges, and choices.

  • Balance democracy and independence: Our working definition of justice balances democratic practice and the creative freedom honored by circular leadership. For example, when is personal creativity more important than democratic decision making, or vice versa?

  • Provide recommendations: We hope we are able to provide further guidance overtime to ensure that end goals are met.

  • Gather data on voting rights in relation to roles: Decoupling roles from voting rights allows us to visibilize power. However, we may eventually recommend consistent voting rights by role in the future and/or accordingly revise roles.

Previous
Previous

Define responsibility roles & hours

Next
Next

Set aside a value pool