Policies in Holacracy: Wann und wie Sie Richtlinien erstellen

Policies sind eines der mächtigsten – und am häufigsten missbrauchten – Instrumente in Holacracy. Eine gut formulierte Policy schafft Klarheit und ermöglicht autonomes Handeln. Eine schlechte Policy erzeugt Bürokratie und erstickt Eigeninitiative.

Bei SI Labs haben wir Policies erstellt, überarbeitet und wieder gelöscht. Wir kennen die Versuchung, für jedes Problem eine neue Regel zu schaffen – und die Erleichterung, wenn man unnötige Policies wieder streicht. Diese Erfahrung ist Teil unserer Holacracy-Praxis. Dieser Artikel teilt unsere Learnings.

Was ist eine Policy?

Eine Policy in Holacracy ist eine Richtlinie, die entweder:

1. Eine Berechtigung erteilt: „Alle Circle-Mitglieder dürfen das Marketing-Budget bis 500€ eigenständig nutzen.”
2. Eine Einschränkung definiert: „Alle Ausgaben über 1.000€ erfordern die Zustimmung der Rolle Finance.”

Policies wirken auf Domains. Sie erweitern oder begrenzen den Zugang zu Ressourcen, die unter der Kontrolle einer Rolle oder eines Kreises stehen.

Wichtig: Policies können keine Accountabilities zuweisen. Sie können nicht sagen: „Rolle X muss Y tun.” Dafür sind Accountabilities bei der Rollendefinition da.

Was Policies NICHT sind

• Keine Arbeitsanweisungen: „Marketing soll drei Posts pro Woche veröffentlichen” ist keine Policy, sondern gehört in eine Accountability.
• Keine Strategien: „Wir fokussieren uns auf Enterprise-Kunden” ist keine Policy, sondern eine strategische Entscheidung.
• Keine Werte: „Wir sind transparent” ist keine Policy, sondern ein Kulturprinzip.

Policies vs. Domains vs. Accountabilities

Die drei Governance-Elemente werden oft verwechselt. Hier ist der Unterschied:

Element	Funktion	Beispiel
Domain	Definiert exklusive Kontrolle	„Website” → nur diese Rolle darf ändern
Accountability	Definiert erwartete Aktivitäten	„Veröffentlichen von Blog-Artikeln”
Policy	Regelt den Zugang zu Domains	„Alle dürfen Inhalte vorschlagen, aber nur mit Freigabe von Content”

Zusammenspiel:

• Eine Rolle hat die Domain „Website”
• Damit hat niemand anderes Zugriff ohne Erlaubnis
• Eine Policy kann diesen Zugriff regeln: „Jeder darf kleinere Textänderungen selbst vornehmen”

Research Insight: Studien zeigen, dass Organisationen mit klaren Domain-Definitionen 40% weniger Konflikte über Zuständigkeiten haben. Policies funktionieren am besten, wenn die Domains bereits klar sind. [1]

Wann eine Policy erstellen?

Policies sind sinnvoll, wenn:

1. Zugang zu einer Domain geregelt werden muss

Situation: Eine Rolle hat eine Domain (z.B. „Kundenverträge”), aber andere brauchen gelegentlich Zugriff.

Lösung: Policy, die den Zugang regelt.

Beispiel: „Sales-Rollen dürfen Standardverträge ohne Rücksprache versenden. Anpassungen erfordern Abstimmung mit Legal.”

2. Wiederkehrende Konflikte auftreten

Situation: Immer wieder entstehen ähnliche Konflikte über die Nutzung einer Ressource.

Lösung: Policy, die klare Regeln schafft.

Beispiel: Nach mehreren Konflikten über die Nutzung des Besprechungsraums: „Buchungen über 2 Stunden erfordern 24 Stunden Vorlauf.”

3. Koordination zwischen Rollen nötig ist

Situation: Mehrere Rollen müssen eine Ressource gemeinsam nutzen.

Lösung: Policy, die die Koordination regelt.

Beispiel: „Vor dem Release prüft QA die Änderungen. Development wartet auf Freigabe oder Feedback innerhalb von 4 Stunden.”

Wann KEINE Policy erstellen?

1. Wenn eine Accountability ausreicht

Situation: Sie wollen, dass jemand etwas tut.

Falsch: Policy „Marketing muss wöchentlich einen Newsletter versenden.”

Richtig: Accountability für die Marketing-Rolle: „Versenden des wöchentlichen Newsletters.”

2. Wenn das Problem einmalig ist

Situation: Ein einzelner Konflikt ist aufgetreten.

Falsch: Sofort eine Policy erstellen.

Richtig: Erst prüfen, ob sich das Problem wiederholt. Policies für Einzelfälle erzeugen unnötige Bürokratie.

3. Wenn Vertrauen die bessere Lösung ist

Situation: Sie misstrauen der Urteilskraft anderer.

Falsch: Policy, die jeden Schritt regelt.

Richtig: Klare Accountabilities und Vertrauen in die Kompetenz der Rolleninhaber.

Der Policy-Proposal-Prozess

Policies werden wie alle Governance-Änderungen durch den IDM-Prozess in Governance-Meetings erstellt.

Schritt 1: Die Spannung identifizieren

Frage: Was funktioniert nicht gut genug?

Beispiele für Policy-Spannungen:

• „Ich weiß nicht, ob ich das Marketing-Budget nutzen darf.”
• „Wir haben ständig Konflikte über die Nutzung des Firmenwagens.”
• „Externe werden manchmal ohne Abstimmung zu Kundengesprächen eingeladen.”

Schritt 2: Prüfen, ob eine Policy die richtige Lösung ist

Fragen:

• Geht es um Zugang zu einer Domain? → Policy kann helfen
• Geht es um erwartete Aktivitäten? → Accountability ist besser
• Ist das Problem wiederkehrend? → Policy sinnvoll
• Ist das Problem einmalig? → Keine Policy nötig

Schritt 3: Die Policy formulieren

Gute Policies sind:

• Spezifisch: Nicht „Alle sollen achtsam sein”, sondern „Ausgaben über 500€ erfordern Dokumentation.”
• Minimal: So wenig Einschränkung wie nötig.
• Klar: Keine Interpretationsspielräume bei den Regeln.

Template für Policies:

[Wer] darf/muss [was tun] [unter welchen Bedingungen].

Beispiele:

• „Alle Circle-Mitglieder dürfen das Firmenfahrzeug für Kundentermine nutzen, wenn sie mindestens 24 Stunden vorher buchen.”
• „Externe Berater dürfen nur nach Freigabe durch die Rolle Project Lead zu Kundengesprächen eingeladen werden.”
• „Ausgaben unter 200€ können von jeder Rolle eigenständig getätigt werden; darüber ist Abstimmung mit Finance erforderlich.”

Schritt 4: In Governance einbringen

Bringen Sie die Policy als Proposal in ein Governance-Meeting. Seien Sie offen für Einwände und Integration.

Typische valide Einwände:

• „Das schränkt meine Arbeit unnötig ein.” → Prüfen, ob die Policy zu restriktiv ist.
• „Das ist nicht klar genug formuliert.” → Präzisieren.
• „Das löst nicht das eigentliche Problem.” → Spannung neu analysieren.

Policy Anti-Patterns

Anti-Pattern 1: Die Regel-Explosion

Problem: Für jedes kleine Problem wird eine neue Policy erstellt.

Symptome:

• Hunderte von Policies
• Niemand kennt alle Regeln
• Ständig werden Policies gebrochen, weil sie niemand kennt

Lösung: Policies nur für wiederkehrende, bedeutsame Probleme. „Weniger ist mehr” als Prinzip.

Anti-Pattern 2: Die Pseudo-Policy

Problem: Die Policy klingt gut, ist aber nicht umsetzbar.

Beispiel: „Alle kommunizieren respektvoll miteinander.”

Warum schlecht: Nicht überprüfbar, keine klare Handlungsanweisung, gehört in die Kultur, nicht in Governance.

Lösung: Policies müssen konkret und überprüfbar sein.

Anti-Pattern 3: Die Kontroll-Policy

Problem: Policies werden genutzt, um Kontrolle auszuüben statt Klarheit zu schaffen.

Beispiel: „Alle Entscheidungen über 100€ müssen vom Lead Link genehmigt werden.”

Warum schlecht: Untergräbt die Autorität der Rollen, schafft Flaschenhälse, widerspricht dem Holacracy-Prinzip der verteilten Autorität.

Lösung: Policies sollten Autonomie ermöglichen, nicht einschränken.

Research Insight: Forschung zeigt, dass übermäßige Formalisierung in selbstorganisierten Teams zu „Bürokratie-Müdigkeit” führt. Erfolgreiche Holacracy-Organisationen haben durchschnittlich 60% weniger Policies als traditionelle Unternehmen vergleichbarer Größe. [2]

Anti-Pattern 4: Die unsterbliche Policy

Problem: Policies werden nie überprüft oder gelöscht.

Symptome:

• Policies, die seit Jahren niemand mehr braucht
• Widersprüchliche Policies aus verschiedenen Zeiten
• „Das haben wir schon immer so gemacht”

Lösung: Regelmäßige Policy-Reviews, Sunset-Klauseln.

Policies auslaufen lassen (Sunsetting)

Policies sollten nicht für die Ewigkeit gemacht sein. Es gibt mehrere Strategien:

1. Ablaufdatum einbauen

Technik: Policies mit einem Verfallsdatum versehen.

Beispiel: „Diese Policy gilt bis zum 30.06.2026 und wird dann automatisch aufgehoben, sofern nicht erneuert.”

Vorteil: Erzwingt regelmäßige Überprüfung.

2. Trigger-basiertes Review

Technik: Policy wird überprüft, wenn bestimmte Bedingungen eintreten.

Beispiel: „Diese Policy wird überprüft, sobald das Team mehr als 10 Mitglieder hat.”

3. Regelmäßiger Policy-Audit

Technik: Einmal im Jahr werden alle Policies auf Relevanz geprüft.

Vorgehen:

1. Liste aller aktiven Policies erstellen
2. Für jede Policy fragen: „War diese Policy in den letzten 6 Monaten relevant?”
3. Nicht mehr relevante Policies in Governance zur Löschung vorschlagen

Policies bei SI Labs

Unsere Erfahrung mit Policies:

Weniger ist mehr

Wir hatten Phasen, in denen wir für alles Policies erstellt haben. Das Ergebnis: Niemand kannte alle Regeln. Heute haben wir deutlich weniger Policies – und mehr Klarheit.

Die „Brauchen wir das wirklich?”-Frage

Vor jeder neuen Policy fragen wir: „Ist das ein wiederkehrendes Problem?” und „Würde eine Accountability oder eine bessere Domain-Definition das Problem auch lösen?”

Jährlicher Policy-Audit

Einmal im Jahr gehen wir alle Policies durch und fragen: „Brauchen wir das noch?” Typischerweise streichen wir dabei 20-30% der bestehenden Policies.

Policies als lebende Dokumente

Unsere Policies sind in GlassFrog dokumentiert und für alle einsehbar. Wenn eine Policy nicht funktioniert, wird sie in Governance angepasst – nicht ignoriert.

Checkliste für gute Policies

Vor dem Einbringen einer Policy:

Ist eine Policy das richtige Instrument?

• Geht es um Zugang zu einer Domain?
• Ist das Problem wiederkehrend?
• Wäre eine Accountability nicht besser?

Ist die Policy gut formuliert?

• Ist sie spezifisch und klar?
• Ist sie minimal (so wenig Einschränkung wie nötig)?
• Ist sie überprüfbar?

Hat die Policy ein Ablaufdatum?

• Gibt es einen Review-Trigger?
• Ist sie Teil des jährlichen Policy-Audits?

---

Forschungsmethodik

Dieser Artikel basiert auf der Analyse akademischer Arbeiten zu Governance-Mechanismen in selbstorganisierten Kontexten, ergänzt durch über zehn Jahre praktische Erfahrung mit Policy-Design bei SI Labs.

Quellenauswahl:

• Studien zu Formalisierung in agilen Organisationen
• Vergleichende Analysen von Governance-Instrumenten
• Praktiker-Literatur zur Holacracy-Implementierung

Einschränkungen: Als Holacracy-Praktiker haben wir Erfahrungen gesammelt, die unsere Perspektive auf effektives Policy-Design prägen.

---

Offenlegung

SI Labs GmbH praktiziert Holacracy seit über zehn Jahren. Unsere Policy-Struktur hat sich in dieser Zeit kontinuierlich weiterentwickelt – von zu vielen zu weniger, aber wirksameren Policies.

---

Quellen

[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 [Empirische Studie | N=339 Startups | Zitationen: 81 | Qualität: 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 Studie | 43 Interviews | Zitationen: 43 | Qualität: 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 [Praxisleitfaden | N/A | Zitationen: 523 | Qualität: 55/100]