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, tools, and knowledge the role requires in practice — not aspirational nice-to-haves. If the role requires administering a CRM and presenting to a board, 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, tools, and knowledge required in practice — not aspirational nice-to-haves. What will the person use in their first month?
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.
AI assistants are powerful — but they fail in the same three ways that employees do. They overstep when authority is unclear. They produce the wrong thing when responsibility is undefined. And they underperform when they lack the context that amounts to ability. The fix is the same: define all three before you start.
The ARA prompt template
Worked examples across roles
An AI without authority boundaries will make decisions you didn't intend to delegate. It will rewrite the CTA, change the product name, alter the tone entirely. Every decision the AI makes that you didn't explicitly grant is a decision made without authority.
Without a clear deliverable — format, length, recipient, purpose — the AI produces something technically responsive but practically useless. It answered the question you typed, not the question you needed answered. Responsibility pins the output.
An AI with no context about your organisation, your audience, your constraints, or your tools will produce output that could belong to any company in any industry. Ability is the difference between a useful first draft and something you have to rewrite entirely.
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