Practical guide

Choose Together, Build Together

Shared ownership only works if people also have a clear way to shape the work. Heirloom’s governance loop turns ideas into decisions, decisions into tasks, and tasks into rewarded contribution.

Brandon ReidBy Brandon Reid·8 min read
Flow diagram showing Proposal → Vote → Tasks → Rewards

If ownership is shared, decision-making cannot stay hidden.

That does not mean every decision needs a vote. It does not mean every team needs endless meetings, consensus rituals, or governance theater. But if people are contributing real work to a project, and if that work may eventually translate into ownership, then the path from idea to decision to execution needs to be visible.

Otherwise, shared ownership becomes incomplete. People may earn points, equity, or credit, but still have no real voice in the direction of the thing they are helping build.

Heirloom’s answer is a lightweight loop: Proposal → Vote → Tasks → Rewards.

Why shared ownership needs shared governance

Shared ownership is not just a financial arrangement. At its best, it changes how people relate to the work. People care more when they understand the direction, trust the rules, and believe their effort can shape the outcome.

Research on shared capitalism points in this direction. The strongest versions of shared ownership are usually paired with participation, information sharing, training, and real voice at work. Ownership without participation can become symbolic. Participation without ownership can become extractive. The two are strongest when they reinforce each other.

This is also one of the core lessons of human-centered organization design. Bureaucracy centralizes permission. It makes people wait, ask, escalate, and justify. A more human organization gives people clearer ways to act, propose, test, decide, and learn.

Heirloom’s governance loop is meant to support that kind of organization: enough structure to avoid chaos, but not so much structure that the system slows the team down.

Companion read: For the ownership side of this system, read Build Together, Own Together.

The loop: Proposal → Vote → Tasks → Rewards

The loop is simple on purpose.

A person sees an opportunity and writes a proposal. The team discusses and votes. If the proposal passes, it becomes a set of tasks. When those tasks are completed and accepted, contributors earn credit, ownership points, or other rewards based on the team’s rules.

The goal is not to make every action political. The goal is to make meaningful decisions traceable. When a team changes direction, spends money, distributes ownership, accepts a new member, launches something public, or commits to a major piece of work, people should be able to see how that decision became real.

The loop in one sentence

Good ideas become clear proposals, clear proposals become legitimate decisions, legitimate decisions become assigned work, and completed work becomes recognized contribution.

1) Proposal: frame the decision

A good proposal is not just an idea. It is a framed decision.

That distinction matters. “We should build a mobile app” is an idea. A proposal explains why the mobile app matters, what problem it solves, what tradeoffs it creates, what resources it needs, what success would look like, and what happens if the team says no.

The best proposals are small enough to act on and clear enough to disagree with. If nobody can disagree with the proposal, it probably is not specific enough.

A useful proposal should include:

  • Context: What problem, opportunity, or tension is this responding to?
  • Decision: What exactly is the team being asked to approve?
  • Tradeoffs: What are the costs, risks, and alternatives?
  • Resources: What time, money, people, or tools are needed?
  • Success criteria: How will the team know if this worked?
  • Next actions: What tasks should happen if this passes?

This mirrors a broader lesson from commons governance: rules work better when the people affected by them can understand, modify, and monitor them. In Heirloom terms, proposals are how the team turns vague preference into a decision everyone can inspect.

2) Vote: choose the right decision rule

Not every decision deserves the same voting method.

One of the fastest ways to make governance feel broken is to treat every choice as equally important. A small design tweak, a major budget decision, a new member policy, and a legal formation vote should not all move through the same process.

Heirloom supports different rules for different decisions:

  • Consent or quick approval for small, reversible decisions where speed matters more than precision.
  • One-person-one-vote for culture, membership, and community questions where voice should not depend on stake.
  • Contribution-weighted voting for decisions where the people carrying more of the work or risk should have more say.
  • Delegation when contributors trust someone else to vote on their behalf in areas where they do not have the time or context.
  • Quorum and cooling-off windows for major decisions so important changes are not rushed through while people are absent.

The key is matching the rule to the decision. Good governance is not maximum voting. It is appropriate participation.

Modern DAO tools like Snapshot and Aragon have explored flexible voting, delegation, proposal workflows, and modular governance. Heirloom borrows the useful parts of that design pattern without assuming every team wants crypto infrastructure.

3) Tasks: turn “yes” into work

A vote only matters if something happens afterward.

This is where many participatory systems break down. People spend time discussing and approving an idea, but the decision never becomes concrete work. Responsibility stays vague. The decision lives in a meeting note, chat thread, or someone’s memory. A month later, everyone vaguely agrees that “we should still do that.”

Heirloom closes that gap by turning passed proposals into tasks. Each task should have a clear owner, acceptance criteria, due date or review date, and connection back to the original proposal.

That traceability matters. It lets the team answer basic questions:

  • What did we decide?
  • Why did we decide it?
  • Who agreed to do the work?
  • What counts as done?
  • What changed because of it?

This is how governance stays practical. The point is not to produce decisions. The point is to produce aligned action.

4) Rewards: recognize contribution

The final step is recognition.

When a task is completed and accepted, the contribution should become visible. Depending on the project, that may mean earned ownership points, reputation, public proof of work, a share of a contributor pool, payment, revenue participation, or simply a clear record that someone carried the work forward.

This is where governance connects back to ownership. A person should not have to argue later that their work mattered. The system should already show it.

Recognition also changes culture. It tells contributors that doing the work matters more than performing commitment. It makes follow-through visible. It creates a record the team can use when deciding ownership, leadership, stewardship, or future formal agreements.

Why this can speed teams up

Governance has a bad reputation because people associate it with slow committees, endless meetings, and procedural drag. That is real, bad governance can absolutely slow a team down.

But no governance is not the same as speed. It often just means decisions happen privately, confusion appears later, and people waste time reconstructing what was supposedly agreed.

A lightweight cycle can make teams faster because it reduces the hidden coordination tax. People know where ideas go. They know how decisions happen. They know what work came out of the decision. They know how contribution is recognized.

The speed comes from clarity.

The rule of thumb

If a decision is small and reversible, keep it lightweight. If it changes ownership, money, membership, direction, or public commitments, slow down enough to make the decision visible.

The human-centered reason this matters

The deeper purpose of this system is not voting for its own sake. It is agency.

Human-centered organizations are built on the belief that people are not just resources to be allocated. They are capable of judgment, creativity, responsibility, and initiative. But those qualities only show up when the organization gives people room to use them.

Bureaucracy works by concentrating permission. Human-centered systems work by distributing responsibility with enough transparency and trust to keep people aligned.

That is why Heirloom’s governance model is intentionally tied to work. Proposals are not meant to create abstract debate. Votes are not meant to create political factions. Tasks are not meant to turn people into ticket machines. Rewards are not meant to gamify contribution.

The purpose is to help teams practice a better habit: people who see what needs to change should have a real path to propose it, gather support, do the work, and share in the value created.

What should actually go to a vote?

Early teams should be careful not to over-govern. If everything requires a vote, nobody will want to participate.

A useful test is this: does the decision affect trust?

If the answer is yes, make the decision visible.

Usually worth voting on:

  • Adding or removing major contributors.
  • Changing the project’s direction or scope.
  • Spending shared money or committing to meaningful costs.
  • Changing contribution weights or ownership rules.
  • Accepting outside funding or forming a legal entity.
  • Launching publicly under the team’s name.
  • Changing the governance rules themselves.

Usually not worth voting on:

  • Small design choices that can be reversed.
  • Routine task assignments.
  • Minor copy changes.
  • Low-risk experiments with a clear owner.
  • Decisions already delegated to a specific role.

The best teams are explicit about this. They do not vote because they are afraid to act. They vote when legitimacy matters.

A simple proposal template

If you are starting from scratch, use this:

Title: What are we deciding?

Context: Why is this coming up now?

Proposal: What should we do?

Options considered: What else could we do, including doing nothing?

Tradeoffs: What are the costs, risks, and downsides?

Success criteria: What would make this decision successful?

Tasks if approved: What work should be created?

Voting rule: What threshold, quorum, or decision method applies?

Review date: When should we check whether it worked?

This is enough structure to make a decision clear without turning every proposal into a legal memo.

Common failure modes

Shared governance fails when the process becomes detached from reality. Here are the traps to avoid:

  • Governance theater: people vote, but the real decision was already made elsewhere.
  • Endless discussion: the team debates direction but never converts decisions into tasks.
  • Vague proposals: people approve ideas without understanding costs, tradeoffs, or next actions.
  • Participation fatigue: too many small decisions require formal input.
  • Unclear authority: nobody knows what is delegated, what requires approval, and what someone can simply do.
  • Reward drift: the team says contribution matters, but completed work is not actually recognized.

The solution is not more process. It is better process: clear enough to create trust, light enough to preserve momentum.

How this works inside a Loom

Inside Heirloom, the governance cycle should feel connected to the rest of the work, not bolted on separately.

  1. A contributor creates a proposal with context, tradeoffs, success criteria, and proposed tasks.
  2. The team discusses and votes using the decision rule that fits the proposal.
  3. If approved, tasks are created and assigned to contributors.
  4. Contributors complete the work with visible artifacts and acceptance criteria.
  5. Completed work earns recognition through ownership points, reputation, public proof, payment, or another project-defined reward.
  6. The team reviews the outcome and learns whether the decision actually worked.

The loop turns participation into execution. That is what keeps governance from becoming a side quest.

What this is not

This is not a claim that voting solves every team problem. Some decisions need leadership. Some need expertise. Some need speed. Some need trust built through conversation before a formal vote makes sense.

It is also not a claim that every team should be fully flat. Structure still matters. Roles still matter. Accountability still matters. The question is whether that structure helps people contribute, or whether it simply concentrates power and hides decisions.

Heirloom is trying to support the first version: clear roles, visible decisions, contribution-based ownership, and enough voice for people to feel like they are building something with others, not merely helping someone else execute their private plan.

Better governance should make building feel more possible

At its worst, governance is a drag on action. At its best, it is how a group of people turns trust into momentum.

That is the version Heirloom is built for. A system where ideas do not vanish into chat threads. Where decisions create work. Where work creates visible contribution. Where contribution can shape ownership. And where the people building the project have a real path to shape what it becomes.

Shared ownership asks people to care. Shared governance gives them a reason to believe that caring matters.

Turn decisions into shipped work

Create a Loom, invite contributors, propose the next step, and connect decisions directly to tasks and earned contribution.

Explore Heirloom

Heirloom provides collaborative tools and templates to help teams organize work, decisions, and contribution history. Nothing on this page is legal, tax, or investment advice. If your team formalizes ownership, governance rights, or a legal entity, consult appropriate counsel.

Sources and further reading

Brandon Reid

Written by Brandon Reid

Building Heirloom for people who want to create meaningful things together.

More to explore

Go deeper on shared ownership, dynamic equity, and collaborative building.

Collaborate with brilliant builders.
Own what you ship.

Add your project to Heirloom or join an existing team. Share what you're building, find collaborators, and keep ownership fair with dynamic equity.

Free to start • No cohort required • Keep your idea alive in public