Open Enterprise Governance Model

1. Overview

An Open Enterprise is a meritocratic community-based organization. Every aspect of the Open Enterprise is governed by an opt-in engagement model: Anyone with an interest in its work can join the community, contribute to the enterprise and participate in the decision making process. Revenue, decisions, and control are shared based on contribution and peer-review. This document describes how that participation takes place and how to set about earning merit within the community.

2. Roles and responsibilities

2.1 Users

Anyone who is a stakeholder in an enterprise is a user. This includes (but is not limited to): customers, investors, neighbors, and anyone in the enterprise’s community. Anyone can be a user; there are no special requirements. Users are welcome to participate in an Open Enterprise as much as possible. User contributions help ensure that the enterprise succeeds in accomplishing its mission while remaining true to its values . Common user contributions include (but are not limited to):

* evangelizing about the enterprise (e.g. a link on a website and word-of-mouth awareness raising) * providing feedback : informing the organization of strengths and weaknesses from a new user perspective, and keeping the Open Enterprise accountable to its mission and values * providing moral support (a ‘thank you’ goes a long way) * providing financial support * supporting other users * adding new ideas to Work Streams * participating in the discussion: commenting on Work Items, and in the forums * starting or joining Work Items (via requests)

Users engage with the enterprise through the Work Stream dashboards. They can request to start (or join) any open Work Item. Their request will be considered for inclusion in the project by existing Members (see below).

In addition to starting and joining Work Items, users can use the dashboard to vote in the following ways: * prioritizing existing Work Items * voting on new ideas (agree/disagree) * estimating the effort for suggested Work Items * accepting completed Work Items (accept/reject)

All these votes are non-binding (see below) Users who continue to engage with the enterprise and its community will often become more and more involved. Such users may find themselves becoming Contributors. Once a user has worked on a Work Item that has been completed and accepted by the community, they are automatically considered a Contributor.

2.2 Contributors

Contributors are users who have earned credits (see below) in an enterprise. Any user can become a Contributor; there is no expectation of commitment to the enterprise, no specific skill requirements and no selection process. Contributors are eligible to be nominated for Membership: As Contributors gain experience and familiarity with the enterprise, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for Membership, as described in the next section.

2.3 Members

Members are Contributors who have shown that they are committed to the continued development of the enterprise through ongoing engagement with the enterprise and its community. Any Contributor can become a Member; there are no special requirements, other than to have shown a willingness and ability to participate in the enterprise as a team player. Typically, a potential Member will need to show that they have an understanding of the enterprise, its objectives and its strategy. Most importantly, they need to demonstrate that they are aligned with the enterprise’s core principles and values. They will also have provided valuable contributions to the enterprise over a period of time. New Members can be nominated in one of two ways: 1. By any existing Member 2. By completing a certain amount of accepted work as Contributors to the enterprise Once they have been nominated, there will be a vote by the Core Team (see below). Voting in a Member is one of the few activities that takes place in private. This is to allow Core Team Members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published on the public forum. The nominee is entitled to request an explanation of any ‘no’ votes against them, regardless of the outcome of the vote. This explanation will be anonymous and constructive in nature. Nominees may decline their appointment as a Member. However, this is unusual, as the enterprise does not expect any specific time or resource commitment from its Members. The intention behind the role of Member is to allow people to contribute to the enterprise more easily, not to tie them in to the enterprise in any formal way. Membership allows Contributors to more easily carry on with their enterprise related activities by giving them direct access to the enterprise’s resources. That is, they have the autonomy to participate directly to the enterprise outputs. This does not mean that a Member is free to do what they want. While Membership indicates a valued Member of the community who has demonstrated a healthy respect for the enterprise’s values and objectives, their work continues to be reviewed by the community before acceptance. The key difference between a Member and a Contributor is when this approval is sought from the community. A Member seeks approval after the contribution is made, rather than before. Another way to look at it is that Contributors ask for permission while Members ask for review. Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the enterprise. The Work Stream dashboards ensure that all contributions are reviewed by the community as a whole. By the time a Contributor is invited to become a Member, they will have been guided through the use of the enterprise’s various tools as a user and then as a Contributor. In addition to their actions as Contributors, Members will also find themselves doing one or more of the following: * enrolling and allowing users and Contributors to start/join Work Items * nominating Contributors for Membership * voting on Core Team Membership (see below) Also Members’ votes are binding, and they need not ask for permission to join/start Work Items. It is important to recognize that Membership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the Core Team (see next section) in extreme circumstances. However, under normal circumstances Membership exists for as long as the Member wishes to continue engaging with the enterprise. A Member who shows an above-average level of contribution to the enterprise, particularly with respect to its strategic direction and long-term health, may be nominated to become a Member of the Core Team. This role is described in the next section.

2.4 Core Team

The Core Team consists of those individuals identified as ‘enterprise representatives’. The Core Team has additional responsibilities over and above those of a Member. These responsibilities ensure the smooth running of the enterprise. Core Team Members are expected to participate in strategic planning, approve changes to the governance model, and formally represent the enterprise to the outside world. First and foremost, they are the guardians and keepers of the enterprise’s principles and values, and are accountable to all stakeholders. Core Team Members do not have significant authority over other Members of the community, although it is the Core Team that votes new Members in. In addition, the Core Team has access to the enterprise’s private Work Streams. These Work Streams are used sparingly for sensitive issues, such as votes for a new Member, and sensitive IP and legal matters that cannot be discussed in public. It is rarely –if ever– used for enterprise management or planning. In addition to their actions as Members, Core Team Members will also find themselves doing one or more of the following: * voting on nominated Members * voting on changes to the governance model * nominating Members to the Core Team Membership of the Core Team is by invitation from the existing Core Team Members. A nomination will result in discussion and then a vote by ALL existing Members of the enterprise. Core Team Membership votes are subject to consensus approval (see below) of enterprise Members.

2.5 Non-Profit Board of Directors

A board of directors is traditionally the governing body of a non-profit organization. in a Non-Profit Open Enterprise the Board retains many of their traditional rights, even though governance is more distributed. The Board can initiate a Board Vote on any issue, whether that be a work item or the induction of a new member. This vote is open for any user to contribute in a non-binding voice, and only Board Members’ votes will be binding, its results are binding for the Enterprise and override any decisions made by its Members. A Member can also be a Board Member, but this is limited to one, i.e. no more than one Member of an Open Enterprise should serve as a voting member of the board of directors and that member should not serve as chair or treasurer of the Board. To allow for significant deliberation and diversity, the majority of the board should be made up of at least seven persons unrelated to each other or Members. The organization’s bylaws should determine term limits that establish individual terms of no more than three years, allow individuals to serve no more than three consecutive terms, and require at least one year intervening before eligibility for re-election after serving the maximum number of consecutive terms. Board membership should reflect the diversity of the organization’s constituencies. Board Members (who are not Contributors to the Enterprise) should not receive compensation for their board service, other than reimbursement for expenses directly related to board duties. Open board positions are announced publicly, and any user can nominate themselves or any one else to become a Board Member. Voting in new Board Members is done by the existing Board Members only.

3. Decision making process

Decisions about the future of the enterprise are made through discussion by the entire community, from the newest user to the most experienced Core Team Member. All non-sensitive project management discussion takes place in public Work Stream dashboards and forum. Occasionally, sensitive discussion occurs on a private Work Stream. In order to ensure that the enterprise is not bogged down by endless discussion and continual voting, the enterprise operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote, and keeps the work agile and red-tape free.

3.1 Lazy consensus

Decision making typically involves the following steps: 1. Proposal 2. Discussion 3. Vote 4. Decision Anyone can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should add the idea to the appropriate Work Stream dashboard or forum (work-item ideas go in the dashboard, big-picture strategy is discussed in the forums). This will prompt a review and discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. In general, as long as nobody explicitly opposes a proposal, it is recognized as having the support of the community. This is called lazy consensus – that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal. Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with nothing to add to a proposal need not spend time stating their position, and others need not spend time reviewing it. For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

3.2 Lazy majority

Not all decisions are made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the enterprise must gain explicit approval in the form of a vote. This section describes how a vote is conducted. Section 3.4 discusses when a vote is needed. If a formal vote on a proposal is called, all users may express an opinion and vote. There are 4 types of votes: * ‘agree’: agrees that the action should move forward * ‘disagree’: disagree but will not oppose the action’s going forward * ‘block’: opposes the action’s going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue) * ‘neutral’: indicates that attention has been given to the action but abstaining from voting one way or another Another way to abstain from the vote is for participants to simply not participate. However, it is more helpful to cast a ‘neutral’ vote to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial. The entire community, from interested user to the most active Core Team Member, has a vote. The enterprise encourages everyone to express their opinions in all discussion and all votes. However, only Members of the enterprise (as defined above) and/or Core Team Members have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of the entire community are considered. While only Members and Core Team Members have a binding vote, a well-justified ‘block’ from a non-Member must be considered by the community, and if appropriate, supported by a binding ‘block’. A ‘block’, when cast by a Member or Core Team Member, essentially becomes a ‘veto’. When a vote receives a ‘block’, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding block) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the Core Team will decide the forward course of action. In summary: * Those who don’t agree with the proposal and feel it would be detrimental to the enterprise if pursued should vote ‘block’. However, they will be expected to submit and defend a counter-proposal. * Those who don’t agree, don’t find it detrimental, and don’t have a better idea should vote ‘disagree’. * Those who agree should vote ‘agree’. * Those who do not care either way or who find themselves on the fence should vote ‘neutral’.

3.3 Type of approval

Different actions require different types of approval, ranging from lazy consensus to a majority decision by the Core Team. These are summarized below. The next section describes which type of approval should be used in common situations.

1. Lazy consensus: Immediate

An action with lazy consensus is implicitly allowed, unless a binding ‘block’ vote is received. Depending on the type of action, a vote will then be called. Note that even though a binding ‘block’ is required to prevent the action, anyone is is free to cast a ‘block’ vote with supporting argument. Members are expected to evaluate the argument and, if necessary, support it with a binding ‘block’.

2. Lazy majority: 72 hours

A lazy majority vote requires more binding ‘agree’ votes than binding ‘disagree’ votes and no vetoes (binding ‘block’ votes). Once 72 hours have passed, the decision moves in the direction of the majority. Naturally if an actual majority of Members vote before the 72 hours are up, the decision moves in that direction immediately. Sometimes a lazy majority is tied with a vote threshold. This allows for decisions to be made quicker than 72 hours if enough Members vote. If the vote threshold is reached before the 72 hours are up, the decision moves in the direction of the majority.

3. Unanimous consensus: 120 hours

All of the binding votes that are cast are to be ‘agree’ and there can be no ‘disagree’ votes or vetoes (binding ‘block’ votes)

4. Credit majority

Some strategic actions are decided by giving each credit-holder 1 vote per credit; Such actions typically affect the foundation of the project (e.g. adopting a new governance model)

3.4 When is a vote required?

Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. Activities that require more control are taken through lazy majority, which is still informal enough for team to stay agile. However, some activities require a more formal approval process in order to ensure the health and cohesiveness of the enterprise. This section identifies which type of vote should be called when: * User/Contributor requests to join/start a Work Item: Lazy consensus of any Member * New Contributor: Lazy consensus of any Member * Work Item moving to open queue and Work Item acceptance is dependent on the estimated value of that item: *0-1 points: Lazy majority of all Members, vote threshold: 1 *2-4 points: Lazy majority of all Members, vote threshold: 2 *5-6 points: Lazy majority of all Members, vote threshold: 3 * New Work Stream: Lazy majority of all Members * New Member: Unanimous approval of Core Team * Member removal: Unanimous consensus of Core Team * New Core Team Member: Unanimous consensus of all Members * Core Team Member removal: Unanimous consensus of Core Team * Governance model change: Credit majority * Legal structure changes: Credit majority * Big picture strategy: Credit majority Anomaly: Estimation is done by lazy averaging: Any Member can estimate a Work Item that is new or open. Estimation is closed once the item is in progress.

4. Money matters for a for-profit Open Enterprise

4.1 Credits

Anyone who’s done work for an Open Enterprise is paid for that work in credits. Credits are a promise by the enterprise to pay their owner as soon as funds are made available, each credit is worth $1. The payment of credits owed is tracked in the payment pipeline, which shows exactly who is owed money, where they are in the placement in comparison to other creditors, and how periodically is the enterprise making payments to its creditors. When any Member in the enterprise commits cash to revenue sharing (see below), this cash is used first to pay out the payment pipeline, i.e. the enterprise cannot share any profits before all its money owed to contributors is paid out in full. Credits are not only money owed, they also give their owner profit-sharing, budgeting, and voting rights. Credits do not immediately expire once paid out. Once credits are paid out however, they have an expiration date, the expiration period begins from the time the creditor receives cash for their credits, and lasts as long as it took this creditor to cash out their credits. E.g. if a participant received $20,000 in credits, and 4 months later their $20,000 credits were paid out in cash, then 4 months after that (8 months from the original date of receipt) would be when their credits would expire. Creditors have the choice to commit some or all of their credits to equity, i.e. taking them out of the payment pipeline and ensuring that they never expire.

4.2 Estimation

Each Work Item in an Open Enterprise is estimated independently, in terms of how many credits will be awarded for its completion. Any member is free to give an estimate of how much should be given for any open Work Item, and their estimation will affect the average estimate of that item. And once work starts on a Work Item and it is being executed, its estimation can no longer be changed.

4.3 Retrospectives

In order to ensure that all Contributors to a Work Stream get adequately compensated for their work, and that compensation be as fair as possible, the compensation system in an Open Enterprise is based on several tenants: * There are no fixed salaries in an Open Enterprise * Participants are compensated based on Work Items completed, not time spent – This is to provide everyone the freedom to contribute as much or as little as they choose, and for the Enterprise to be billed fairly. * Contribution is assessed by one’s peers, seeing as coworkers and co-team members are the most likely to know how valuable someone’s contributions were – This is to provide the most fair assessment of one’s contribution, using the wisdom of the crowd in assessing work done. * Peer assessment is compared with self-assessment – This is to provide an opportunity for each participant to self-reflect and learn about their assessment of their own work, as well as an indicator to all users of each participant’s self-assessment abilities. This system of compensation is executed using the Retrospective, which occurs once a number of Work Items worth a certain amount of credits are completed and accepted in any given Work Stream. During the Retrospective, each person who has contributed any amount of work to any of the Work Items involved is asked to assess their own percentage contribution to the completion of these items, as well as every other participant’s. Once all participants have stated their opinion, each one receives the average of their team’s assessment of their work. That figure is also compared with their own assessment of themselves, which affects their self-assessment reputation. The percentage each participant receives is then applied to the total amount of credits associated with the retrospective and these credits are distributed accordingly.

4.4. Budgeting and Profit Sharing

Budgeting in an Open Enterprise is distributed, trusting that the emergent intelligence of the crowd will decide how best to spend the organization’s cash. As spending cash, either through funds raised, revenues, or loans, comes to the enterprise, its spending allowance is distributed to all members according to their relative credit ownership. Each Member has the autonomy to allocate their budget to whichever items they feel need it the most. A member can also decide to allocate some or all of their budget towards profit sharing. This cash will be used first to pay out the credits in the payment pipeline and then distributed to all credit owners, whether members or not, according to their relative credit ownership.

5. Money matters for a Non-profit Open Enterprise

5.1 Credits

Anyone who’s done work for an Non-Profit Open Enterprise is rewarded for that work in credits. There are two types of Credits: 1. Cash Credits: Cash Credits are a promise by the Enterprise to pay their owner as soon as funds are made available, each credit is worth $1. 2. Volunteer Credits: Volunteer Credits give the owner the recognition and decision-making ability of a credit, but have no monetary value. The payment of Cash Credits owed is tracked in the payment pipeline, which shows exactly who is owed money, where they are in the placement in comparison to other creditors, and how periodically is the Enterprise making payments to its creditors. When any Member in the Enterprise commits cash to the Credit Pipeline (see below), this cash is used to fulfill the debt owed to their owners. Credits are not only money owed, they also give their owner profit-sharing, budgeting, and voting rights. Credits do not immediately expire once paid out. Once credits are paid out however, they have an expiration date, the expiration period begins from the time the creditor receives cash for their credits, and lasts as long as it took this creditor to cash out their credits. E.g. if a participant received $20,000 in credits, and 4 months later their $20,000 credits were paid out in cash, then 4 months after that (8 months from the original date of receipt) would be when their credits would expire. Creditors have the choice to commit some or all of their credits as decision-making credits, i.e. taking them out of the payment pipeline and ensuring that they never expire.

5.2 Estimation

Each Work Item in an Non-Profit Open Enterprise is estimated independently, in terms of how many credits will be awarded for its completion. Any member is free to give an estimate of how much should be given for any open Work Item, and their estimation will affect the average estimate of that item. And once work starts on a Work Item and it is being executed, its estimation can no longer be changed.

5.3 Retrospectives

In order to ensure that all Contributors to a Work Stream get adequately compensated for their work, and that compensation be as fair as possible, the compensation system in an Non-Profit Open Enterprise is based on several tenants: * There are no fixed salaries in an Non-Profit Open Enterprise * Participants are compensated based on Work Items completed, not time spent – This is to provide everyone the freedom to contribute as much or as little as they choose, and for the Enterprise to be billed fairly. * Contribution is assessed by one’s peers, seeing as coworkers and co-team members are the most likely to know how valuable someone’s contributions were – This is to provide the most fair assessment of one’s contribution, using the wisdom of the crowd in assessing work done. * Peer assessment is compared with self-assessment – This is to provide an opportunity for each participant to self-reflect and learn about their assessment of their own work, as well as an indicator to all users of each participant’s self-assessment abilities. This system of compensation is executed using the Retrospective, which occurs once a number of Work Items worth a certain amount of credits are completed and accepted in any given Work Stream. During the Retrospective, each person who has contributed any amount of work to any of the Work Items involved is asked to assess their own percentage contribution to the completion of these items, as well as every other participant’s. Once all participants have stated their opinion, each one receives the average of their team’s assessment of their work. That figure is also compared with their own assessment of themselves, which affects their self-assessment reputation. The percentage each participant receives is then applied to the total amount of credits associated with the retrospective and these credits are distributed accordingly.

5.4. Spending Cash

Spending in an Non-Profit Open Enterprise is distributed, trusting that the emergent intelligence of the crowd will decide how best to spend the organization’s cash. As spending cash, either through funds raised, revenues, or loans, comes to the Enterprise, its spending allowance is distributed to all members according to their relative credit ownership. Each Member has the autonomy to allocate their budget to whichever items they feel need it the most. A Member can also decide to allocate some or all of their budget towards the Credit Pipeline.

6. Conclusion

The Open Enterprise governance model comes from the more democratic end of the spectrum of control. But it is not a democracy, it is a meritocracy. It is a model that passes control on to those who are most likely to wield it for the benefit of all, rather than a minority interest. Work organization is (generally) emergent. People emerge to do the work by simply doing it. If they are helpful, other people begin to trust them. In a healthy enterprise, this trust eventually results in explicit authority and responsibilities. This is called leadership. In traditional management structures, authority is granted from the top down regardless of any existing trust or respect. This is what most people would call a manager. Managers may also be leaders, but this is unfortunately more rare than it should be. Given the nature of open participation in Open Enterprises, they don’t have managers, but they do have leaders. There is a big difference between a leadership culture and a management culture. In most corporations, management = status = power. The people who have the most people working for them have the loudest voices in the direction of the organization. In a healthy Open Enterprise, the people who 1) have good ideas or 2) get things done, are the ones that have the status and power. These are the people who tend to have lots of folks start to willingly follow them. First you earn leadership, and then you are allowed to manage.