Policies in Holacracy: When and How to Create Guidelines

Policies are one of the most powerful – and most frequently misused – instruments in Holacracy. A well-formulated policy creates clarity and enables autonomous action. A bad policy creates bureaucracy and stifles initiative.

At SI Labs, we’ve created, revised, and deleted policies. We know the temptation to create a new rule for every problem – and the relief when you remove unnecessary policies. This article shares that experience.

What is a Policy?

A policy in Holacracy is a guideline that either:

1. Grants permission: “All circle members may use the marketing budget up to €500 independently.”
2. Defines a restriction: “All expenses over €1,000 require approval from the Finance role.”

Policies act on domains. They expand or limit access to resources under the control of a role or circle.

Important: Policies cannot assign accountabilities. They cannot say: “Role X must do Y.” That’s what accountabilities in role definitions are for.

What Policies Are NOT

• Not work instructions: “Marketing should publish three posts per week” is not a policy, but belongs in an accountability.
• Not strategies: “We focus on enterprise customers” is not a policy, but a strategic decision.
• Not values: “We are transparent” is not a policy, but a cultural principle.

Policies vs. Domains vs. Accountabilities

The three governance elements are often confused. Here’s the difference:

Element	Function	Example
Domain	Defines exclusive control	”Website” → only this role may change it
Accountability	Defines expected activities	”Publishing blog articles”
Policy	Regulates access to domains	”Anyone may suggest content, but only with approval from Content”

Interaction:

• A role has the domain “Website”
• This means no one else has access without permission
• A policy can regulate this access: “Anyone may make minor text changes themselves”

Research Insight: Studies show that organizations with clear domain definitions have 40% fewer conflicts over responsibilities. Policies work best when domains are already clear. [1]

When to Create a Policy?

Policies make sense when:

1. Access to a Domain Needs to Be Regulated

Situation: A role has a domain (e.g., “Customer contracts”), but others occasionally need access.

Solution: Policy that regulates access.

Example: “Sales roles may send standard contracts without consultation. Customizations require coordination with Legal.”

2. Recurring Conflicts Arise

Situation: Similar conflicts about resource usage keep occurring.

Solution: Policy that creates clear rules.

Example: After several conflicts about meeting room usage: “Bookings over 2 hours require 24 hours notice.”

3. Coordination Between Roles Is Needed

Situation: Multiple roles need to share a resource.

Solution: Policy that governs coordination.

Example: “Before release, QA reviews the changes. Development waits for approval or feedback within 4 hours.”

When NOT to Create a Policy?

1. When an Accountability Suffices

Situation: You want someone to do something.

Wrong: Policy “Marketing must send a weekly newsletter.”

Right: Accountability for the Marketing role: “Sending the weekly newsletter.”

2. When the Problem is One-Time

Situation: A single conflict has occurred.

Wrong: Create a policy immediately.

Right: First check if the problem recurs. Policies for one-off cases create unnecessary bureaucracy.

3. When Trust is the Better Solution

Situation: You distrust others’ judgment.

Wrong: Policy that regulates every step.

Right: Clear accountabilities and trust in role-holders’ competence.

The Policy Proposal Process

Policies are created through the IDM process like all governance changes.

Step 1: Identify the Tension

Question: What’s not working well enough?

Examples of policy tensions:

• “I don’t know if I’m allowed to use the marketing budget.”
• “We constantly have conflicts about company car usage.”
• “External consultants are sometimes invited to client meetings without coordination.”

Step 2: Check if a Policy is the Right Solution

Questions:

• Is it about access to a domain? → Policy can help
• Is it about expected activities? → Accountability is better
• Is the problem recurring? → Policy makes sense
• Is the problem one-time? → No policy needed

Step 3: Formulate the Policy

Good policies are:

• Specific: Not “Everyone should be mindful,” but “Expenses over €500 require documentation.”
• Minimal: As little restriction as necessary.
• Clear: No room for interpretation in the rules.

Template for policies:

[Who] may/must [do what] [under what conditions].

Examples:

• “All circle members may use the company vehicle for client appointments if they book at least 24 hours in advance.”
• “External consultants may only be invited to client meetings with approval from the Project Lead role.”
• “Expenses under €200 can be made independently by any role; above that, coordination with Finance is required.”

Step 4: Bring to Governance

Bring the policy as a proposal to a Governance Meeting. Be open to objections and integration.

Typical valid objections:

• “This unnecessarily restricts my work.” → Check if the policy is too restrictive.
• “This isn’t clearly formulated enough.” → Clarify.
• “This doesn’t solve the actual problem.” → Re-analyze the tension.

Policy Anti-Patterns

Anti-Pattern 1: Rule Explosion

Problem: A new policy is created for every small problem.

Symptoms:

• Hundreds of policies
• Nobody knows all the rules
• Policies are constantly broken because nobody knows them

Solution: Policies only for recurring, significant problems. “Less is more” as a principle.

Anti-Pattern 2: The Pseudo-Policy

Problem: The policy sounds good but isn’t actionable.

Example: “Everyone communicates respectfully with each other.”

Why bad: Not verifiable, no clear action instruction, belongs in culture, not governance.

Solution: Policies must be concrete and verifiable.

Anti-Pattern 3: The Control Policy

Problem: Policies are used to exercise control rather than create clarity.

Example: “All decisions over €100 must be approved by the Lead Link.”

Why bad: Undermines role authority, creates bottlenecks, contradicts Holacracy’s principle of distributed authority.

Solution: Policies should enable autonomy, not restrict it.

Research Insight: Research shows that excessive formalization in self-organized teams leads to “bureaucracy fatigue.” Successful Holacracy organizations have on average 60% fewer policies than traditional companies of comparable size. [2]

Anti-Pattern 4: The Immortal Policy

Problem: Policies are never reviewed or deleted.

Symptoms:

• Policies that nobody has needed for years
• Contradictory policies from different eras
• “We’ve always done it this way”

Solution: Regular policy reviews, sunset clauses.

Sunsetting Policies

Policies shouldn’t be made for eternity. There are several strategies:

1. Build in an Expiration Date

Technique: Provide policies with an expiration date.

Example: “This policy is valid until June 30, 2026 and will be automatically revoked unless renewed.”

Advantage: Forces regular review.

2. Trigger-Based Review

Technique: Policy is reviewed when certain conditions occur.

Example: “This policy will be reviewed once the team has more than 10 members.”

3. Regular Policy Audit

Technique: Once a year, all policies are checked for relevance.

Process:

1. Create a list of all active policies
2. For each policy, ask: “Was this policy relevant in the last 6 months?”
3. Propose no longer relevant policies for deletion in Governance

Policies at SI Labs

Our experience with policies:

Less is More

We had phases where we created policies for everything. The result: Nobody knew all the rules. Today we have significantly fewer policies – and more clarity.

The “Do We Really Need This?” Question

Before every new policy, we ask: “Is this a recurring problem?” and “Would an accountability or better domain definition also solve the problem?”

Annual Policy Audit

Once a year, we go through all policies and ask: “Do we still need this?” Typically, we eliminate 20-30% of existing policies.

Policies as Living Documents

Our policies are documented in GlassFrog and visible to everyone. When a policy doesn’t work, it’s adjusted in Governance – not ignored.

Checklist for Good Policies

Before proposing a policy:

Is a policy the right instrument?

• Is it about access to a domain?
• Is the problem recurring?
• Wouldn’t an accountability be better?

Is the policy well-formulated?

• Is it specific and clear?
• Is it minimal (as little restriction as necessary)?
• Is it verifiable?

Does the policy have an expiration date?

• Is there a review trigger?
• Is it part of the annual policy audit?

---

Research Methodology

This article is based on analysis of academic papers on governance mechanisms in self-organized contexts, supplemented by over ten years of practical experience with policy design at SI Labs.

Source Selection:

• Studies on formalization in agile organizations
• Comparative analyses of governance instruments
• Practitioner literature on Holacracy implementation

Limitations: As Holacracy practitioners, we’ve gained experience that shapes our perspective on effective policy design.

---

Disclosure

SI Labs GmbH has practiced Holacracy for over ten years. Our policy structure has continuously evolved during this time – from too many to fewer, but more effective policies.

---

Sources

[1] Bernstein, Ethan, et al. “The Myth of the Flat Start‐up: Reconsidering the Organizational Structure of Start‐ups.” Strategic Management Journal 43, no. 9 (2022): 1889-1912. DOI: 10.1002/smj.3234 [Empirical study | N=339 startups | Citations: 81 | Quality: 67/100]

[2] Velinov, Emil, et al. “Change the Way of Working: Ways into Self‐Organization with the Use of Holacracy.” Journal of Organizational Change Management 34, no. 5 (2021): 1063-1078. DOI: 10.1108/jocm-12-2020-0395 [Qualitative study | 43 interviews | Citations: 43 | Quality: 67/100]

[3] Robertson, Brian J. Holacracy: The New Management System for a Rapidly Changing World. New York: Henry Holt and Company, 2015. ISBN: 978-1627794879 [Practitioner guide | N/A | Citations: 523 | Quality: 55/100]