The gap between who your organization says is accountable for a delivery outcome and who has the structural authority to produce it is where organizational failures accumulate. RACI charts document task ownership. They do not document decision authority. A person can be designated Accountable without having the authority to make the decisions that accountability requires. When a program fails or a compliance gap surfaces, the accountability inquiry reveals this mismatch — after the damage is already done, not before.
I have managed delivery programs across ten countries over nineteen years. The most consistent pattern in organizational failure — more consistent than capability gaps, resource constraints, or technical complexity — is this authority-accountability mismatch. It is a governance design problem, not a management quality problem. It cannot be solved by redesigning the RACI chart. The chart reflects the design. Fixing the design requires a different kind of analysis — one that maps decision authority, not just task ownership.
The Role / Responsibility Distinction
The distinction I am making is not between "role" in the sense of a job title and "responsibility" in the sense of a task list. It is more specific than that.
A responsibility is task ownership: this person is responsible for doing this work. Responsibilities describe what gets done and who does it.
A role is decision authority: this person has the authority to make this class of decisions, within these boundaries, under these conditions. Roles describe who decides — not what they do, but what calls they can make.
The organizational tendency is to conflate these. Job descriptions combine task lists with implicit authority assumptions. RACI charts map tasks to people without specifying the decision authority that executing those tasks requires. Org charts show reporting structures that imply decision authority without specifying it.
The conflation works when the work is routine, when the environment is stable, and when everybody involved has the same informal understanding of where decisions live. It fails when the work is novel, when the environment changes, or when a new person enters the system without the informal context that makes the implicit authority legible.
Consider a concrete example. A project manager is "responsible" for delivery of a major program. This responsibility is listed in the project charter, the RACI chart, and the manager''s performance objectives. The project encounters a vendor delivery failure. The project manager identifies two remediation options: one costs an additional $150,000 and recovers the timeline, the other accepts a two-month delay and stays within budget. Which option should the project manager choose?
If the answer to that question requires the project manager to consult a sponsor, an executive, a steering committee, and a contract manager before a decision can be made — the project manager is responsible for delivery but does not have the role (decision authority) that delivery actually requires. The accountability is formal and nominal. The authority is diffused across the governance structure in a way that makes fast, clear decisions impossible.
This is not a hypothetical. It is the standard operating condition of most enterprise programs.
Why RACI Fails
RACI (Responsible, Accountable, Consulted, Informed) is the most widely used framework for mapping accountability. It is also consistently ineffective at resolving the accountability gaps that emerge during delivery problems or organizational stress.
RACI fails for a structural reason: it maps tasks to people, not decisions to authority. The "A" in RACI — Accountable — is defined as the person who is ultimately responsible for ensuring the task is completed correctly. But "ensuring a task is completed correctly" is not the same as "having the authority to make the decisions that determine whether the task is completed correctly."
A person can be listed as Accountable on a RACI chart without the ability to:
- Direct the resources assigned to the task
- Make the tradeoff decisions that arise during execution
- Escalate when blockers emerge and expect a response
- Accept or reject the deliverable against defined quality criteria
If any of those decision authorities are held elsewhere, the RACI designation of Accountable is describing a responsibility, not a role. The person is accountable in the sense that their name will appear on the failure report. They are not accountable in the sense that they had the authority to prevent the failure.
The second RACI failure mode is that it captures a point-in-time snapshot of task ownership without acknowledging that decision authority is context-dependent. A project manager may have clear authority to make certain decisions when the project is running normally, but unclear authority when the project is in crisis. A department head may have clear authority over their own team''s activities but unclear authority when those activities intersect with another department. RACI does not distinguish between these contexts. It maps the nominal authority structure, not the authority structure that operates under stress.
I have seen RACI charts used as evidence in post-project accountability inquiries. The inquiry typically produces an uncomfortable result: the person listed as Accountable had the task ownership but lacked the decision authority, and the people with the decision authority were listed as Consulted or Informed. The RACI chart documented the form of accountability while diffusing the substance of it.
How Accountability Gaps Form
Three structural patterns produce the accountability gaps that RACI fails to resolve.
Overlapping Authority
The first pattern is overlapping authority: two people or functions both believe they have legitimate authority over the same class of decisions. This produces not conflict in the way that is typically visible — open disagreement between two parties — but a subtler dynamic: both parties act as though the decision is theirs, each making unilateral decisions that the other party then feels authorized to override or ignore.
In a large HPE program I managed, two functions — program delivery and product management — both had valid claims on a class of technical scope decisions. Product management owned the product roadmap; delivery owned the implementation timeline. When scope decisions intersected with timeline decisions, both functions were acting on what they believed was their legitimate authority. The result was a sequence of scope changes that were approved by product management and subsequently rejected by delivery, and timeline extensions that were approved by delivery and subsequently rejected by product management. The program lost four months to this loop before we explicitly drew the decision boundary.
The fix was not resolving the philosophical question of who "owned" scope versus timeline. It was specifying: for decisions of type X (scope changes with timeline implications above threshold Y), the authority is held jointly with a specified tie-breaking escalation. For decisions below that threshold, authority was specified separately. The overlap was not eliminated — the two functions were genuinely interdependent. The decision boundary was documented so that the overlap did not produce paralysis.
Delegated Responsibility Without Delegated Authority
The second pattern is the most common source of execution failure: someone is assigned responsibility for an outcome but not given the authority required to produce it.
This is particularly acute at the interface between organizational levels. A team lead is accountable for the team''s delivery performance but cannot make hiring, staffing, or performance management decisions without approval from a manager who is not close to the delivery context. A program manager is accountable for delivery but cannot make contract modifications, approve budget reallocations, or direct vendor resources without sign-off from an executive who is removed from the day-to-day situation.
The person at the delivery level has the responsibility and the visibility but not the authority. The person with the authority has the approval power but not the context. Decisions are slow, because each one requires the person with context to brief the person with authority. Risk information is degraded, because the briefing process compresses nuance. The accountability designation becomes a fiction: the person listed as accountable is managing a dependency on someone with actual authority, not exercising authority of their own.
At Full Potential Solutions, one of the early design decisions in the PMO I built was explicit authority delegation to account managers for a defined class of decisions. Account managers were accountable for client relationship quality. They were given explicit authority to make financial commitments within a specified threshold, approve operational adjustments to delivery processes, and initiate escalation to the executive level under defined conditions — without requiring approval at each step. The authority matched the accountability. Delivery speed improved and escalation frequency dropped because the people who owned the outcomes could make the decisions their ownership required.
Undocumented Escalation
The third pattern is undocumented escalation: situations arise that fall outside the normal authority of the person handling them, and there is no specified path for escalating to a higher authority.
Undocumented escalation produces two failure modes. The first is unilateral action: the person facing the situation makes a decision they do not have the authority to make, because the alternative is paralysis. The decision may be correct. But it was made without the authority of the role, which means the organization cannot rely on that decision being made consistently or hold the decision-maker accountable for outcomes that follow from it.
The second failure mode is escalation avoidance: the person facing the situation, knowing they lack the authority to decide but not knowing how to escalate, defers action until the situation resolves itself or becomes a crisis. This is the pattern that produces the "why didn''t anyone flag this earlier?" question in post-mortems. The answer is almost always that the person who saw the problem first did not know who to tell or did not believe that telling them would produce a response.
Both failure modes are prevented by a single design element: a documented escalation path that specifies who holds authority for which class of decisions above the normal operational level, under what conditions escalation is appropriate, and what the response protocol is. This does not need to be elaborate. It needs to exist.
Structural Accountability Design
Designing structural accountability means explicitly documenting decision authority alongside task ownership — treating them as separate artifacts that together define how work gets done and who bears responsibility for outcomes.
The documentation framework I use has four elements for each significant decision type.
Decision holder. The role (not the person) that holds authority for this decision type. Specifying a role rather than a person means the authority survives personnel changes. When the person changes, the role documentation tells the new person what authority they have inherited.
Decision scope. What constitutes a decision of this type, including explicit boundaries. Boundary specification is necessary because the most expensive conflicts arise not when authority is clearly allocated but when it is ambiguous which authority applies. "Budget decisions" is a category. "Budget decisions that change committed expenditure by more than $25,000 in a single transaction" is a decision type with a boundary.
Input requirements. What information the decision holder is expected to have considered before making the decision. This is not a checklist of approvals — it is a specification of what due diligence the decision requires. A staffing decision might require input from the team lead and a review of current capacity. A vendor commitment might require input from legal and finance. Specifying the inputs makes the decision process auditable without making it bureaucratic.
Escalation trigger. Under what conditions does this decision exceed the authority of the primary decision holder and require escalation? Escalation triggers should be specific, not qualitative. "When the decision is significant" is not a useful trigger. "When the financial commitment exceeds $100,000" or "when the decision affects delivery timelines by more than 30 days" is a trigger that can be consistently applied.
This framework does not require lengthy documents. For most decision types, the four elements fit on a quarter page. The value is not in the comprehensiveness of the documentation — it is in the existence of a reference that can be consulted when a situation arises that someone is uncertain how to handle.
The Behavioral Difference
Explicit decision authority changes behavior in observable ways.
Decision speed increases. When authority is clear, decisions are made by the person who holds the authority without waiting for consensus that is structurally unnecessary. In organizations with ambiguous authority, decisions that should take hours take days, and decisions that should take days take weeks. The delay is not because the organization lacks the information to decide — it is because nobody is certain they have the authority to make the call.
Conflict resolution accelerates. When two parties disagree about an approach, the question in an organization with documented decision authority is "who holds the authority here?" rather than "who is right?" The first question has a definitive answer. The second question can be argued indefinitely. Escalation to the authority holder produces a resolution. Continued argument about the right answer does not.
Escalation behavior improves. When people know what situations warrant escalation and who to escalate to, they escalate at the right moment rather than too early (producing noise) or too late (producing crises). The most damaging pattern in delivery programs is the late-surfacing problem — a risk that was visible for weeks before it was escalated, during which window it could have been managed. Late escalation is almost always a symptom of undocumented or unclear escalation authority, not of poor individual judgment.
Accountability becomes real. When a person holds explicit decision authority for an outcome, they cannot credibly claim that the outcome was outside their control. They may have made the right call with the information available, or they may have made the wrong call — but they owned the call. This is what genuine accountability looks like: not the assignment of blame after failure, but the prior commitment of authority that makes specific outcomes the genuine responsibility of specific roles.
Operational Evidence
The most direct evidence from my delivery work comes from a program I managed at HPE involving a multi-country systems integration with seven delivery partners. The program had a formal governance structure with clear lines of reporting but ambiguous decision authority at the working level. When delivery issues arose — vendor delays, technical conflicts, resource contention — the working-level teams escalated everything because they were uncertain where their authority ended.
The executive steering committee was receiving fifteen to twenty escalations per week. Most of them were operational decisions that should have been resolved at the delivery level. The executives were making calls they were not close enough to the work to make well, and the delivery teams were waiting for responses rather than managing the delivery.
We ran a decision authority workshop with the working-level leads and documented the decision types that arose most frequently, the authority level at which each type should be resolved, and the escalation trigger for each. The exercise took two days. Over the following six weeks, escalation volume to the steering committee dropped by 70 percent. The steering committee received fewer, more significant escalations and made better decisions on them because they had the context and the time. The delivery teams moved faster because they were making decisions they had previously deferred.
In the multi-venture portfolio I manage, the governance model for each venture includes a decision authority matrix as a founding document — established before the venture has a team of more than four. The early establishment is deliberate. Decision authority is much easier to document when the venture is small and when nobody has yet established informal authority patterns that conflict with the formal structure. Documenting authority in a mature organization requires navigating political resistance. Documenting it in an early-stage venture is straightforward.
The Political Dimension
The organizational politics of decision authority documentation are real and worth naming directly.
Explicit role definition threatens people who derive influence from authority ambiguity. When decision authority is undocumented, people who are well-positioned informally — who have strong relationships with executives, or who have been in the organization long enough to be the de facto authority on certain decisions — benefit from the opacity. The formal documentation of decision authority can expose that their informal influence was filling an authority vacuum, and that filling that vacuum was not actually their role to fill.
This resistance is not cynical. People who have developed genuine expertise in a domain and who have been making decisions effectively often believe — correctly — that they are better equipped to make those decisions than whoever might formally hold the authority. The governance design argument is not that their judgment is inferior. It is that organizational accountability requires authority to be documented and role-held rather than informally exercised. When the expert leaves, the authority must transfer to the role, not disappear with the person.
The most productive framing I have found for this conversation is forward-looking: the question is not "who should make this decision right now?" but "what should happen to this decision in five years when the current situation has changed?" Informal authority does not answer that question. Documented role authority does.
Where This Does Not Apply
Decision authority documentation is most valuable in organizations of sufficient complexity that informal coordination is no longer reliable. Small organizations — teams under fifteen, single-product companies in their early stages — often operate effectively with informal authority structures. The people in the organization know each other, share context, and can resolve authority ambiguity through direct conversation. The overhead of formal documentation exceeds the value it produces.
The calculus changes when the organization grows, when staff turnover increases, when the work becomes complex enough that not everyone can hold all the relevant context, or when external accountability requirements (regulatory, contractual, board-level) make documented governance a necessity rather than an option.
Decision authority documentation also does not substitute for organizational trust. In an environment of low trust, documented authority will be used to limit and constrain rather than to enable and clarify. The documentation is most valuable as a reference for people who are operating in good faith but uncertain about their authority, not as a tool for restricting people who would act outside their authority regardless of what the documentation says. The authority framework enables people who want to do the right thing. It does not prevent people who have decided not to.
The Principle
Accountability is not a designation on a chart. It is the condition of holding authority over an outcome — the genuine ability to produce it or fail to produce it, with clear consequences in either direction. When an organization assigns accountability without assigning the authority that accountability requires, it has created a fiction: someone to name in the failure inquiry, not someone who could have prevented the failure.
Structural accountability design does not require complex frameworks or lengthy documents. It requires treating decision authority as a first-class governance artifact — something that is explicitly specified, maintained as roles and responsibilities change, and consulted when situations arise. Organizations that do this find that decisions are faster, conflicts are resolved rather than accumulated, and accountability inquiries are shorter and more productive because the question of who had the authority to decide is answerable.
The work is straightforward. The discipline is in doing it before the failure, not after.
Continue in this series
This piece is part of What Is Organizational Governance? A Systems Practitioner's Complete Guide, my systematic guide to organizational governance and operating systems. Related reading:
- Organizational Mapping as a Governance Tool
- Leading Without Positional Authority in Complex Organizations
- What Is Systems Architecture for Organizations?
- What a Systems Architect Actually Does (And How to Become One)
Working through this in your own organization? I help technical leaders design it directly — advisory engagements.
