Core Primitive
Authority flows from roles, not from hierarchy — anyone in a role has the authority that role requires. In traditional organizations, authority is personal — it belongs to the individual who holds a position in the hierarchy. A manager has authority because they are a manager, and they carry that authority across all the domains their position encompasses. In role-based authority, authority is functional — it belongs to the role, not the person. A person exercises authority when they are acting within a role they hold, and they hold no authority outside that role. This separation of person from role enables distributed authority: one person can hold multiple roles (and exercise different authorities in each), and authority can be reassigned by reassigning the role rather than reorganizing the hierarchy.
The authority bottleneck
In traditional hierarchies, authority concentrates in positions. A VP of Engineering holds authority over technical decisions, hiring decisions, resource allocation, process design, vendor selection, and incident response — not because one person is best qualified to make all these decisions but because the organizational structure assigns all engineering authority to the VP position.
This concentration creates two problems. First, a bottleneck: every decision that requires engineering authority must pass through or be approved by the VP, regardless of whether the VP has the relevant expertise. The VP who is brilliant at technical architecture but has no operational experience still holds authority over deployment decisions. Second, fragility: when the VP is unavailable (traveling, sick, on vacation, in another meeting), engineering authority is unavailable — decisions wait until the person returns.
The root cause is the conflation of person and authority. In hierarchical organizations, authority is inseparable from the person who holds the position. Role-based authority separates them: authority belongs to the role, and the role can be held by whoever is best qualified to exercise it.
The role-based model
Role-based authority operates through four structural elements.
Role definition
A role is a defined domain of authority and accountability. Each role specifies: what decisions the role authorizes (the authority), what outcomes the role is accountable for (the accountability), what information the role needs to function (the information requirements), and what boundaries the role operates within (the constraints).
A well-defined role is specific enough to be unambiguous but broad enough to enable autonomous action within the domain. "Architecture Lead: authority over technical architecture decisions for the platform, including technology selection, system design patterns, and technical debt prioritization. Accountable for system reliability (99.9% uptime), performance (sub-200ms response time), and maintainability (new developer productive within two weeks). Constrained by: approved technology list, security policy, budget allocation."
Role assignment
Roles are assigned based on capability, not position. The person best qualified to exercise a role's authority holds the role, regardless of their title or seniority. A junior engineer with deep deployment expertise can hold the Release Manager role. A product manager with strong data skills can hold the Analytics Lead role. Role assignment is based on demonstrated competence, not organizational rank.
Role assignment can be done through several mechanisms: appointment (a governance body assigns roles), election (the team votes on who holds roles), or consent (a person proposes to take a role and it proceeds unless someone objects). The mechanism should match the organization's governance model (Adaptive governance).
Role multiplicity
One person can hold multiple roles simultaneously. This is a fundamental departure from hierarchical positions, where one person holds one position. A senior engineer might hold the Architecture Lead role, the Security Champion role, and the Onboarding Mentor role — exercising different authority in each domain. When acting as Architecture Lead, they make architecture decisions. When acting as Security Champion, they review security implications. When acting as Onboarding Mentor, they guide new team members. The authority is context-dependent, not universal.
Role evolution
Roles are not permanent — they evolve as the organization's needs change. Through the adaptive governance process (Adaptive governance), roles can be created, modified, merged, or eliminated based on the organization's evolving requirements. This evolutionary capacity prevents the role structure from becoming as rigid as the hierarchy it replaced.
Roles versus positions
The distinction between roles and positions illuminates why role-based authority works differently from hierarchy.
A position is a permanent organizational structure. It exists regardless of who fills it. It encompasses a broad, often vaguely defined domain. It carries a title that signals rank. It is modified through formal reorganization.
A role is a functional responsibility. It exists because a specific function needs to be performed. It encompasses a specific, clearly defined domain. It carries no inherent rank. It is modified through governance process as needs evolve.
The practical implication is flexibility. Positions create rigid structures: creating a new position requires organizational approval, filling it requires a hiring or promotion process, and eliminating it requires a restructuring. Roles create fluid structures: creating a new role requires a governance decision, filling it requires identifying the most capable person, and eliminating it requires acknowledging that the function is no longer needed.
Implementing role-based authority
The transition from position-based to role-based authority follows four steps.
Step 1: Authority mapping
Identify all the types of authority currently concentrated in hierarchical positions. For each type of authority, document: what decisions it encompasses, who currently exercises it, who has the most relevant expertise, and how frequently the authority is exercised.
Step 2: Role design
Group related authorities into coherent roles. Each role should have a clear, focused domain — not the broad, diffuse domain of a hierarchical position. The test is: can one person reasonably exercise all the authority in this role? If not, the role is too broad and should be split.
Step 3: Role assignment
Assign each role to the person best qualified to exercise it. This often means distributing authority that was previously concentrated in one position across multiple people — the former VP's authority distributed among Architecture Lead, Release Manager, Hiring Lead, and other roles. The former position-holder may retain some roles but not all.
Step 4: Governance integration
Integrate role-based authority into the organization's governance process. Define how roles are created, assigned, reviewed, and evolved. Establish protocols for handling decisions that span multiple roles (cross-role consultation) and for resolving conflicts between roles (governance escalation).
The accountability question
The most common objection to role-based authority is accountability: "If authority is distributed across roles, who is accountable for overall outcomes?" The answer is that accountability follows authority — the person in the role is accountable for the outcomes within that role's domain. Overall organizational outcomes are the collective accountability of all role-holders, coordinated through the purpose (Organizational purpose as a coordination mechanism), transparency (Transparency as organizational infrastructure), and feedback mechanisms (Organizational feedback systems) described in this phase.
This distributed accountability requires trust in the system rather than trust in a single leader. In hierarchical organizations, accountability concentrates at the top — the CEO is accountable for everything. In role-based organizations, accountability distributes across the role structure — each role-holder is accountable for their domain, and the governance system is accountable for coordination. This requires a different model of organizational trust — not "I trust the leader" but "I trust the system."
The Third Brain
Your AI system can serve as a role design tool. Describe the decisions your team or department makes and the expertise required for each, then ask: "Design a role-based authority structure for this team. Group related decisions into coherent roles, define each role (authority, accountability, information requirements, constraints), and suggest which team members might best fill each role based on the expertise profile I have described. Identify potential role boundary conflicts and propose protocols for handling decisions that span multiple roles."
From authority to knowledge
Role-based authority distributes decision-making power. But effective decisions require not just authority but knowledge — the accumulated understanding that enables good judgment. The next lesson, Organizational knowledge management, examines organizational knowledge management — how self-directing organizations capture, share, and build on collective knowledge.
Sources:
- Robertson, B. J. (2015). Holacracy: The New Management System for a Rapidly Changing World. Henry Holt and Company.
Frequently Asked Questions