Noah Thorp, Co-founder of Citizen Code shares his thoughts on organizing companies and teams using a constitution. He shares insights on the origins and use of the open source Self-Organization Constitution.
2. The Need
• Freelance work is expanding. 40-50% of US workforce
by 2020
• Hierarchies are optimized for predictability.
Freelancers are temporary teams assembled from a
network.
• Holacracy and sociocracy are heavy weight and slow
to scale. Hard to learn while starting a new venture.
• If only there were a lightweight open source solution.
3. Pioneers of Self-Org
• Cybernetics - Norbert Weiner
• Sociocracy - 60s and 70s governance by consent
• Visa - Chaordic Organization Principles
• Valve - the flat org that votes with its feet
• Morning Star - networks of CLOUs
• Github - asynchronous developer culture
• Enspiral - culturally driven self-management
• Holacracy - Zappos, Medium - formalized system of self-organization
4. Originating Thoughts
• “You need people who are adaptable because the thing that makes you the
best in the world in one generation of games is going to be totally useless in
the next. So specialization in gaming is sort of the enemy of the future. We
had to think about if we’re going to be in a business that’s changing that
quickly, how do we avoid institutionalizing one set of production methods in
such a way that we can’t adapt to what’s going to be coming next.” - Gabe
Newell, Valve Software
• “The business changes. The technology changes. The team changes. The
team members change. The problem isn't change, per se, because change
is going to happen; the problem, rather, is the inability to cope with change
when it comes.” - Kent Beck, Extreme Programming Explained
• “These people are leaving for home where they will manage their lives, why
not here at work?” - Chris Rufer, Founder & CEO of Morning Star
5. Ostrom’s Principles
• Clearly defined boundaries (effective exclusion of external un-entitled parties);
• Rules regarding the appropriation and provision of common resources that are
adapted to local conditions;
• Collective-choice arrangements that allow most resource appropriators to participate
in the decision-making process;
• Effective monitoring by monitors who are part of or accountable to the appropriators;
• A scale of graduated sanctions for resource appropriators who violate community
rules; Mechanisms of conflict resolution that are cheap and of easy access;
• Self-determination of the community recognized by higher-level authorities; and
• In the case of larger common-pool resources, organization in the form of multiple
layers of nested enterprises, with small local CPRs at the base level.
6. Exploring Adaptability
• What are the attributes of an organization that can
respond to internal and external change?
• What values would you want your adaptive
organization to reflect?
• How can an organization allow for spontaneous
leadership?
7. • Your group of 2-20 people needs a clear way to fulfill its
purpose, make decisions, get things done, and respond to
change.
To fit your values your constitution must be egalitarian.
In order to respond to change and adapt to your unique context
you must be able to evolve your constitution.
To learn from other groups you need to be able to share
innovations freely.
In order to build capacity rapidly with changing team members
your constitution must also be simple.
Why a Constitution?
8. Beta Constitution
• Egalitarian
• Respond to change with evolution
• Freely sharable to accelerate learning
(open source)
• Simple to allow capacity building
• Github workflow for devs
• In keeping with Ostrom’s principles
9. What goes into a successful
constitution?
• Agree on how the group will make decisions that apply to the whole group. This
essential agreement allows you to decide on the other agreements. It also
typically requires consensus for adoption.
• Agree on how people will enter into agreements with each other
• Agree on how a person is permitted to participate in group decision making
• Agree on how individuals are permitted to use common resources (e.g. money, a
car)
• Agree on how disputes between two people will be resolved
• Agree on how people prioritize what they spend their time on
• Agree on how sanctions are enforced for people who do not follow the
agreements
12. Freedom To Fulfill The
Purpose
• You are free to take any action that fulfills the
purpose of the organization and the roles that you
hold - as long as you do not break a Rule; and you
seek to uphold the values and principles of the
constitution.
13. In Person Proposals
• A Facilitator facilitates the process if it is an in person meeting. If no Facilitators are present, someone else can
step up to facilitate but that person should not merge pull requests at the end.
• For each un-merged proposal pull request, the facilitator takes these steps:
• The person experiencing the need for change (the author of the pull request) reads their proposal to the group
of affected people. They explain why the change is needed and what the proposal is, and why it is un-merged.
• The facilitator asks if anyone has clarifying questions and lets people ask their questions and get answers.
• The facilitator asks each group member for a reaction. A simple "no reaction" or a thumbs up is perfectly
acceptable and speeds the process up.
• The facilitator asks each group member whether they object or not. The group member responds with
“objection” or “no objection”. Only objections that are based on the belief that the proposal would cause
significant harm are valid. Valid objections are resolved between the proposer and the objector. The proposer
chooses how to amend their proposal based on suggestions. Modified proposals are then re-presented to the
group for objections.
• If there are no valid objections then the proposal is adopted.
• The Facilitator merges the pull request.
14. Github Proposals
• The proposer creates a new github pull request for the proposal.
• The tension that is to be addressed by the proposal is a) included in the commit message for Roles or
b) as part of the description of a Rule.
• The change is announced to all Members on the slack #governance channel.
• Members can respond with clarifications, reactions, and blocking objections. Any Member can abstain
from participating.
• Valid objections must include a reason that the proposal is believed to be harmful and not safe enough
to try; it must also include either 1) a thumbs down emoji 2) the words "objection" or 3) a "-1".
• Any facilitator can decree that the proposal is adopted if there is evidence that the final proposal has
been seen by those who are significantly affected and there are no valid objections to the final version
of the proposal for two days.
• Anyone can request that the pull request be discussed in-person in the next governance meeting.
• The proposer or facilitator can require that the pull request be discussed in-person in the next
governance meeting.
15. Weaknesses / Controversies
• Budgeting - who can spend budget? Fix: roles with budgets and ROI
expectations.
• Titles - people need career progression based on titles not roles. Fix:
just have a title that you use in the external world.
• Voting - voting can kill innovation. Favor distributing authority to
domain experts over flattening of opportunity through majority voting.
• Long governance meetings. Fix: use pull request or async tools.
Concerned people meet to resolve difficult proposals that they have a
stake in.
• Governance process is blockable - low risk in small groups, high risk in
DCOs.
16. Next
• Making proposals easy in slack
• Make all proposals decidable
• Integration with crypto equity, block chain voting,
and DCOs - see SwarmBot