A Framework for Organisational Health
Most workplace dysfunction comes down to three things: nobody knows who can decide what, nobody knows who is supposed to deliver what, and nobody knows what skills the job actually requires.
Read the framework ↓The pain points were always a consequence of misunderstanding or lack of communication. But telling people to "communicate more" or "get on the same page" wasn't enough — it never is.
The problem wasn't the will to communicate. It was the absence of a shared language for what each person was supposed to decide, deliver, and be capable of. ARA provides that language.
This site distils the framework: three pillars, how they interact, how to apply them to meetings, job specs — and how to put them to work with AI.
Authority, Responsibility, and Ability are distinct dimensions of every role. Conflating them — or leaving any one undefined — is the root cause of most organisational dysfunction.
Authority is the right to make a specific decision without seeking approval. It has explicit limits — financial thresholds, personnel scope, contractual commitments — and those limits should be documented and agreed in advance.
Responsibility is a deliverable, not an activity. "Attends weekly meetings" is an activity. "Delivers a pipeline report to the Sales Director by end of day Friday" is a responsibility. The difference matters enormously at review time.
Ability is the specific set of skills the role must be able to perform in practice — things a person can actually do, not knowledge they happen to hold. Name them concretely: if the role requires administering Salesforce and building board decks in PowerPoint, both are skills, and both belong in the Ability column.
Being authorised to do something and being responsible for its execution are different things. Without an explicit responsibility, information simply doesn't flow — and no one is at fault, because no one was ever told it was their job.
A well-defined responsibility names a deliverable, a recipient, and ideally a cadence. It answers: what must this role produce, who receives it, and how often?
When you map responsibilities across roles, you get a process map almost for free. Each handoff between roles — where one person's responsibility produces something that triggers another person's — is a step in your delivery process.
Defining the responsibility doesn't dictate how information moves. Whether a sale is communicated via email, CRM update, or shared dashboard is a format decision. The responsibility defines the content: what must flow, and in which direction.
Authority and Responsibility tell you what decisions a role makes and what it produces. Ability answers the question: does this person actually have the skills to do it?
IT Support's role is infrastructure: the network, the servers, the hardware. Think of them as engineers who maintain the roads. The roads are your network. The car parks are your servers. But it is not their job to teach you to drive your car.
When a manager needed to extract reporting data from the company CRM, she went to IT Support. Technically capable — yes. Their responsibility — no. Knowing how to use the tools your role requires is an Ability requirement of your own role, not a burden to pass to infrastructure teams.
When someone underperforms, the ARA framework tells you where to look. Are they making decisions without authority? Not producing what they're responsible for? Or do they simply lack the tools, training, or access to do the job? Three different problems. Three different solutions.
Every unnecessary meeting is a symptom of an ARA gap. Before scheduling a meeting, ask: which of the three pillars is missing?
"In a hierarchical organisation, every individual who is continuously promoted will eventually reach a role beyond their ability."
The Principle, formulated by Laurence J. Peter and Raymond Hull in 1969, describes how hierarchical organisations systematically produce incompetence. People are promoted on the basis of performance in their current role, until they reach one they cannot perform.
The ARA framework addresses this directly. Ditching Peter is not about dismissing the person — it is about dismantling the conditions that allow the mismatch to go undetected.
When authority is documented, you know exactly what decisions a person is making. When responsibility is documented, you know exactly what they are producing. When ability is documented, you know whether the person in the role has what the role requires.
A job specification built around ARA is an organisational contract. It sets expectations before anyone is hired — and becomes your tool for performance reviews, training plans, and succession planning.
List the decisions this role is empowered to make without escalation. Be specific about the limits: financial thresholds, personnel decisions, client commitments.
If the hiring manager can't fill in this section, that is a signal that the organisation hasn't finished its own ARA work. The vacancy is an opportunity to do it.
Vague authority language — "manages the sales process", "owns client relationships" — tells a candidate nothing and sets up a dispute later.
List what this role must deliver and to whom. Not activities — deliverables. Each responsibility should name a deliverable, a recipient, and ideally a cadence or trigger.
The distinction matters at review time. You cannot assess "attends client meetings" against a standard. You can assess "delivers a qualified pipeline report to the Sales Director by 17:00 every Friday".
List the specific skills the role must be able to perform — named concretely: the software, the framework, the method. Not knowledge, not aspirational nice-to-haves. "Salesforce administration", "Lean Six Sigma", "financial modelling in Excel" — not "good with systems".
This section serves two purposes: it tells a candidate what they will actually be doing, and it gives a manager a diagnostic when someone is underperforming. If the ability was never documented, you cannot legitimately hold someone to it.
A spec updated whenever authority changes, or a new responsibility is added, is a genuinely useful document. One last edited at hiring is a historical artefact.
It becomes the basis for performance reviews, succession planning, and the conversation nobody wants to have when someone is promoted beyond their level. The Peter Principle thrives in organisations without this document.
The framework becomes a tool the moment each role is written as a structured spec — the same three statements, in the same shape, every time. That structure is what makes ARA usable at scale.
Every spec has the same fields, so you can compare two roles side by side, spot an authority two people both claim, or a deliverable nobody owns.
Authority, responsibility and ability with typed fields is structured data. An AI can audit it for gaps and overlaps, or act as the role — the same spec, read by a person or a model.
One role's deliverable is the next role's input. Chain the recipients across specs and the delivery process falls out of the specs for free.
Pick any role in your organisation — your own, if you like — and try to write down three answers to each of the following questions.
If that exercise is straightforward, your organisation has done some of this work already. If it's difficult — if you find yourself writing "it depends" for the first two — you know where to start.
Ditch Peter not by removing the person, but by building the kind of organisation where the conditions for his rise never form in the first place.
The rest, as it turns out, is just communication.
— Christian Macedo