Domain Conflicts in Holacracy: When Responsibilities Overlap

Domains in Holacracy create clarity – until they don’t. When two roles claim the same resource or it’s unclear who can decide what, a domain conflict emerges. These conflicts are normal and solvable if you understand the mechanisms.

At SI Labs, we’ve experienced domain conflicts that triggered productive discussions – and ones that blocked teams. This article explains both scenarios.

What Is a Domain Conflict?

A domain conflict arises when exclusive control over a resource or decision is unclear.

The Anatomy of a Conflict

Domains give roles exclusive control over something. Without explicit permission, nobody else may enter that domain.

A conflict arises when:

1. Two roles believe they have the same domain
2. It’s unclear whether a domain includes a certain resource
3. A domain is defined too broadly and hinders others

Example

Role A has the domain “Customer communication.” Role B has the domain “Social media.”

A customer asks something on LinkedIn. Who responds? Is that customer communication or social media?

Research Insight: Unclear domain boundaries are a common cause of conflicts in self-organized teams. The solution lies not in more detailed definitions but in clear escalation mechanisms. [1]

Recognizing: Symptoms of Overlap

Domain conflicts manifest in various ways.

Direct Symptoms

Disputes over responsibility: “That’s my decision!” – “No, mine!”

Duplicate work: Two roles do the same work because both feel responsible.

Blockage: Nobody acts because nobody is sure if they may.

Indirect Symptoms

Tensions without proposals: Someone complains about another role but brings no governance change.

Political maneuvering: People try to resolve conflicts informally instead of using the governance process.

Avoidance: Certain areas are avoided because the conflict is uncomfortable.

Early Detection

Questions for a structure review:

• Are there areas where it’s unclear who decides?
• Are there domains that are too broad?
• Does someone regularly complain about “interference”?

The Governance Path to Resolution

Domain conflicts are resolved through governance, not through discussion or hierarchy.

The Process

Step 1: Articulate tension

Whoever feels the conflict brings it as a tension. “As [Role X] I experience uncertainty about whether I may make [Decision Y].”

Step 2: Develop proposal

The person with the tension develops a proposal that resolves the conflict:

• Clarify domain
• Split domain
• Assign domain to one role
• Create policy

Step 3: Governance processes

In the governance meeting, the proposal goes through the IDM process. Objections are integrated.

Step 4: New clarity

After the decision, the new structure applies. The old ambiguity is (hopefully) eliminated.

Typical Solutions

Conflict Type	Typical Solution
Two roles claim same domain	Assign domain to one role, other gets accountability or policy
Domain is too broad	Specify or split domain
Domain unintentionally includes something	Reformulate domain, define exception
Domain missing entirely	Create new domain and assign

Clarifying Domain Hierarchy

Sometimes the question is: Which domain takes precedence?

The Principle

In Holacracy, domains inherit from circles to sub-circles – but not automatically to individual roles.

Example:

• The Anchor Circle has the domain “All contracts over €50,000”
• This domain applies to the entire organization
• A sub-circle cannot create a policy that violates this domain

Sub-Domain vs. Partial Domain

Sub-Domain: A part of the larger domain assigned to a specific role.

Example: Circle has domain “Website.” Role A gets sub-domain “Blog section of the website.”

Partial Domain: Unclearly defined overlap.

Example: Role A has “Website,” Role B has “Marketing materials.” The website footer with marketing messages – whose domain?

Making Hierarchy Explicit

When domain hierarchies are unclear, making them explicit helps:

“Role A has Domain X. Role B has Sub-Domain Y within X.”

Or: “Domain X of Role A explicitly excludes [area].”

Policies as Conflict Prevention

Policies can defuse domain conflicts before they arise.

Access Policies

Instead of denying everyone access to a domain, a policy can regulate access:

“Anyone with accountability for customer contact may use the customer database for read operations. Write operations require coordination with [Role].”

Escalation Policies

For predictable conflicts:

“When unclear about responsibility for customer communication, [Role X] decides which role responds.”

Coordination Policies

For regular touchpoints:

“Before a campaign that includes customer contacts is launched, [Role A] and [Role B] coordinate.”

When to Merge Domains

Sometimes the best solution is to combine two overlapping domains into one.

Indicators for Merging

• The roles have almost identical domains
• Coordination between the domains costs more than it delivers
• The domains have grown historically but aren’t logically separated

The Process

1. Identify both domains
2. Define common domain
3. Decide which role receives it (or create new role)
4. Conduct governance

Risks

• One role becomes too powerful
• Important distinctions are lost
• The person who “loses” the domain feels demoted

Domain Conflicts at SI Labs

Our experiences:

What We’ve Learned

Address early. Unresolved domain conflicts don’t get better. The earlier they come to governance, the easier.

Don’t take it personally. Domain conflicts are structural problems, not personal attacks.

Policies can help. Sometimes the solution isn’t “whose domain” but “how do we coordinate.”

Typical Challenges

• People confuse domain conflicts with personal conflicts
• The temptation to resolve conflicts informally instead of through governance
• Fear of addressing the conflict because it seems “political”

---

Research Methodology

This article is based on the Holacracy Constitution, research on coordination in self-organized systems, and over ten years of experience with domain structures at SI Labs.

Source selection:

• Holacracy Constitution and official materials
• Studies on resource conflicts in organizations
• Practitioner experiences from the Holacracy network

Limitations: Domain conflicts are context-dependent. What works for us doesn’t work everywhere.

---

Disclosure

SI Labs GmbH has practiced Holacracy for over ten years. We have experienced and resolved numerous domain conflicts.

---

Sources

[1] Bernstein, Ethan, et al. “Beyond the Holacracy Hype: The Overwrought Claims and Actual Promise of the Next Generation of Self-Managed Teams.” Harvard Business Review 94, no. 7/8 (2016): 38-49. [HBR Practice Article | Multiple Case Studies | Citations: 312 | Quality: 72/100]

[2] Robertson, Brian J. “Holacracy.” In The Management Shift, edited by Vlatka Hlupic, 145-168. Chichester: Wiley, 2012. DOI: 10.1002/9781119197683.ch9 [Book Chapter | N/A | Citations: N/A | Quality: 60/100]