What does it mean that role-based authority?

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.

Example: A software company, Lattice, replaced its management hierarchy with a role-based authority system. Instead of having a 'VP of Engineering' who held authority over all engineering decisions, they created specific roles: 'Architecture Lead' (authority over technical architecture decisions), 'Release Manager' (authority over deployment decisions), 'Hiring Lead' (authority over engineering hiring), 'Incident Commander' (authority during production incidents), and 'Standards Lead' (authority over coding standards and practices). Different people held different roles — the most senior engineer held the Architecture Lead role but a mid-level engineer held the Release Manager role because she had the most operational expertise. One person could hold multiple roles (the Architecture Lead also held the Standards Lead role) and roles could rotate (the Incident Commander role rotated weekly among senior engineers). The impact was immediate. Decisions that had previously required the VP's attention — because all engineering authority was concentrated in one position — were now made by the person in the relevant role, without escalation. The Architecture Lead made architecture decisions. The Release Manager made deployment decisions. The VP's role became 'Engineering Strategy' — setting direction and removing obstacles rather than making operational decisions across all domains. Decision speed increased, decision quality improved (the person deciding had the most relevant expertise), and the VP's bottleneck was eliminated.

Try this: Map the authority structure of your team or department. For each type of decision (technical, hiring, resource allocation, process, quality, communication), identify: (1) Who currently has the authority to make this decision? (2) Is this authority attached to a person (because of their position) or to a function (because of their expertise)? (3) Could this authority be defined as a role that could be held by anyone with the relevant expertise? Draft role definitions for three authority domains in your team. For each role, specify: the role name, the decisions the role authorizes, the accountabilities the role carries, the information the role needs, and the criteria for who should hold the role. Share these drafts with your team and discuss: would this redistribution of authority improve decision speed and quality?