When a complex project fails, there is rarely a shortage of explanations. Engineering may point to changing requirements, Product may argue that the work was underestimated, Security may have documented risks before launch, and Legal may say it was brought into the process too late.
All of those explanations can be reasonable at the same time. The problem appears when the organization can reconstruct what every team contributed but still cannot identify who had authority to make the decision that produced the outcome.
That is an accountability gap.
An accountability gap exists when responsibility for an outcome is distributed across several people or functions while authority over the consequential decisions becomes difficult to locate. Many people may influence the result, but nobody can clearly answer who accepted the final trade-off or who had the power to choose differently.
Some gaps are ordinary organizational mistakes. Responsibilities change, teams grow, dependencies accumulate, and ownership that was once obvious becomes unclear without anyone deliberately intending that result.
The more interesting gaps are the ones that survive after the organization notices them. Leadership introduces a RACI matrix, adds approval stages, establishes a steering committee, or assigns nominal owners, yet the next failure produces exactly the same question: who actually had the authority to decide?
Persistence changes the diagnosis. If an organization repeatedly recognizes an accountability gap but keeps rebuilding structures that diffuse the final decision, the ambiguity may be performing a useful function.
It distributes the risk of being wrong.
Responsibility and Accountability Are Not the Same Thing
Complex work requires shared responsibility because no single person can perform every part of it. A software launch may depend on Product defining the requirements, Engineering building the system, Security reviewing the risks, Legal assessing regulatory exposure, and Operations preparing to support it.
Each function can be responsible for its part without being accountable for the final decision. Responsibility describes work someone is expected to perform, while authority describes what that person is actually allowed to decide.
That distinction becomes important as soon as the teams disagree. Security might identify a serious risk, but can it stop the release or only recommend a delay? Product might own the launch, but can it proceed over Security’s objection? An executive sponsor might intervene, but does accountability move to the executive when that happens?
These questions reveal the actual decision structure more reliably than a list of project responsibilities.
Responsibility
Who contributes to the work?
↓
Authority
Who can make or stop the decision?
↓
Accountability
Who owns the decision that was made?An organization can distribute responsibility widely without creating an accountability problem. The gap appears when authority becomes distributed or hidden while responsibility for the eventual outcome remains vague.
This is why asking who worked on a failed project is usually less revealing than asking who could have chosen differently.
The First Gap May Be an Accident
Organizations are complicated enough that unclear ownership can arise without anyone wanting it.
A new product might launch and immediately create refund requests. Product assumes Finance owns the policy, Finance assumes Support handles refunds, and Support assumes Product decided how customers should be treated.
Once the problem becomes visible, leadership assigns an owner and the ambiguity disappears. Nothing particularly mysterious happened; the organization simply discovered a responsibility it had forgotten to allocate.
Other gaps emerge because the organization itself changes. A service that originally belonged to one team gradually acquires security requirements, data dependencies, vendor relationships, compliance reviews, and operational processes until no single person can alter it without involving half a dozen groups.
That kind of ambiguity is not necessarily designed either. It can accumulate as yesterday’s sensible decisions become today’s complicated operating model.
The more revealing question is what happens after the gap has been identified.
If the organization notices that nobody owns an important decision and then establishes clear authority, the gap was probably accidental or emergent. If the same ambiguity keeps returning after repeated attempts to fix it, something else may be happening.
Persistence tells us more than existence.
Persistent Ambiguity Has a Function
Suppose a product fails after a launch involving Engineering, Product, Security, Legal, Operations, Compliance, an executive sponsor, and a steering committee.
Afterward, each group can give a perfectly reasonable account of its role. Engineering implemented the approved requirements, Security documented its concerns, Legal reviewed the information it received, Operations followed the release plan, and the executive sponsor relied on specialist advice.
Nobody needs to lie for accountability to disappear.
The structure itself allows every participant to say that their judgment was only one input into a larger decision. Responsibility has been distributed so widely that accepting the final risk becomes difficult to attribute to anyone.
That property becomes valuable because clear accountability has consequences. If one executive explicitly decides to launch despite a known risk, the organization can later ask why that executive accepted it. Their judgment becomes visible in a way that collective approval often does not.
Ambiguity spreads that exposure.
This does not require executives to deliberately design an organization where nobody can be blamed. People only need incentives to avoid owning decisions whose consequences they cannot fully control, and organizations need to keep accommodating those incentives.
Over time, the result can look designed even though nobody designed it in a meeting.
Real Accountability Concentrates Decision Risk
The difficulty becomes clearer when an organization genuinely tries to assign an owner.
Suppose leadership says that the Product VP is accountable for whether a system launches. The Product VP then asks whether they can proceed when Security recommends against release.
If the answer is no, Security holds part of the decision authority.
Leadership could instead say that Security owns security risk. But Security may then ask whether it can actually block a launch or whether its job is merely to identify risks for someone else to accept.
If Security cannot stop the launch, it does not own the final risk decision. If it can stop the launch, then its authority needs to be reflected in the accountability structure.
Eventually the organization reaches a question that responsibility matrices often avoid:
Who has authority to hear the specialist advice, understand the remaining risk, and decide whether the organization proceeds anyway?
Answering that question concentrates exposure. Someone becomes identifiable as the person who accepted a trade-off.
That is precisely why organizations can find the language of accountability much easier to embrace than the structure required to create it.
RACI Can Describe Authority Without Creating It
A RACI matrix can be useful because it separates people who perform work from the person accountable for it. A release decision might name Engineering as Responsible, the Product VP as Accountable, Security and Legal as Consulted, and Support as Informed.
On paper, that looks clear.
The real test begins when the matrix meets disagreement. Can the Product VP release over Security’s objection? Can Legal prevent the launch? Can an executive sponsor override the Product VP? If Operations refuses to support the release, does it effectively have a veto even though the matrix calls it merely Responsible or Consulted?
The letters cannot answer those questions unless the authority underneath them is real.
A common form of accountability theater therefore keeps one person formally marked as accountable while requiring approvals from several other functions before that person can act. The document identifies an owner, but the operating model distributes the decision.
Another version simply assigns accountability to several groups. Everyone is responsible for the outcome, which sounds collaborative until the organization needs to identify who accepted a specific trade-off.
The problem is not RACI itself. The problem is expecting a responsibility document to resolve authority that the organization has chosen not to resolve.
Committees Can Coordinate a Decision Without Owning It
Committees create a similar ambiguity because they solve a genuine problem. Consequential decisions often require expertise that no individual possesses, so Product, Engineering, Security, Legal, Finance, and Operations may all need to contribute.
Bringing those perspectives together can improve the decision considerably. The difficulty begins when providing coordinated advice becomes indistinguishable from owning the final call.
Suppose a steering committee approves a launch despite a known security concern and the product is later breached. Saying that “the committee approved it” describes the process, but it may not explain who accepted the risk.
A clearer model separates expertise from final authority.
Engineering ─┐
Security ────┤
Legal ───────┼──► Advice and constraints
Operations ──┤
Finance ─────┘
│
▼
Decision owner
│
▼
Final decisionSome functions may legitimately have formal veto powers. Security, Legal, or Compliance may be able to stop particular actions when defined conditions are met, but those vetoes should be explicit because a veto is decision authority.
The committee can still coordinate the work. What it should not do accidentally is make authority impossible to trace.
Cross-Functional Work Makes Diffusion Easy
Modern organizations cannot solve the accountability problem by avoiding shared work. Products genuinely depend on several disciplines, and pretending otherwise would merely concentrate decisions in people who lack the necessary expertise.
The problem is subtler. Each function controls a different part of the outcome, which means each function can also identify something outside its control when the outcome is poor.
Engineering can explain that requirements changed. Product can explain that a technical constraint was communicated too late. Security can show that it documented the risk, while Operations can point out that it inherited a system it did not design.
Again, all of these explanations can be true.
Shared responsibility is therefore unavoidable, but shared responsibility does not require untraceable accountability. Ten groups can contribute to a launch while one identifiable person owns the decision to proceed after considering their input.
That does not mean everything that happens becomes that person’s fault. It means the organization knows whose authority included accepting the final trade-off.
This distinction matters because accountability is not supposed to erase the complexity of how an outcome was produced. It is supposed to keep consequential decisions visible inside that complexity.
The Most Revealing Moment Is an Override
Formal organizational charts tell us where authority is supposed to sit. Overrides often reveal where it actually sits.
Suppose Engineering recommends delaying a release because of a reliability problem, but Product decides to proceed. Product has now exercised authority over that trade-off.
If an executive then overrules Product and changes the decision again, authority has moved upward once more.
A coherent accountability system should move with it.
Engineering recommends delay
↓
Product overrides
↓
Product owns that trade-off
↓
Executive overrides Product
↓
Executive owns the new trade-offThe accountability gap appears when authority moves but accountability does not.
An executive can override the recommendation, the release fails, and the organization later asks why Engineering failed to prevent the problem. The people with the least final authority become responsible for the consequences of choices made above them.
Escalation can produce the same pattern. A project manager discovers that the project cannot meet both its deadline and scope, but lacks authority to change either. Leadership decides to preserve both and accept the delivery risk.
The project manager remains responsible for execution, but leadership now owns the trade-off it chose. If the original manager remains solely accountable after escalation, the organization has separated accountability from authority.
That separation is one of the clearest signs that a gap is structural rather than accidental.
Governance Can Either Expose Risk or Hide Who Accepted It
Adding review does not necessarily make accountability worse. Security, privacy, legal, compliance, and operational reviews can provide information that a decision owner could not reasonably produce alone.
The important question is what each review means.
A Security team usually cannot certify that no security risk exists. It can review defined controls, identify weaknesses, describe remaining risks, and perhaps exercise a formal veto where policy gives it one.
Someone still has to decide what happens to the risk that remains.
A useful governance process therefore creates a flow from specialist judgment to explicit risk acceptance:
Specialist review
↓
Risks and constraints identified
↓
Decision owner
↓
Mitigate, reject, or accept
↓
DecisionGovernance becomes an accountability shield when the organization replaces that final step with a collection of signatures.
Security signed. Legal signed. Privacy signed. Compliance signed. Engineering signed. Product signed.
The system launches and something goes wrong, after which everyone can truthfully say that the required process was followed.
What remains unanswered is who decided the combined residual risk was acceptable.
More process can therefore increase evidence that people participated without increasing clarity about who decided.
AI Systems Make the Gap Easier to See
AI systems make this problem particularly visible because many different decisions contribute to the final behaviour.
A data scientist may train the model, Engineering may deploy it, Product may define the objective, Risk may establish controls, and executives may approve its use. When the system produces a harmful outcome, each layer genuinely contributed.
That complexity can make phrases such as “the model decided” surprisingly attractive.
But the model did not decide which business objective mattered, which training data was acceptable, how errors should be balanced, where a decision threshold should sit, whether human review was necessary, or whether the system should be deployed at all.
Those were organizational decisions.
The useful accountability question is therefore not simply who built the model. It is who decided to let the model make that kind of decision under those conditions.
The same principle applies outside AI. Tools, vendors, algorithms, and consultants can influence a decision without becoming the organizational actor responsible for choosing to rely on them.
Advice informs authority. It does not make authority disappear.
Accountability Should Follow Authority
Once overrides, escalation, and specialist advice are separated, a simpler principle emerges:
Accountability should follow decision authority.
If Product decides whether to launch, Product owns that decision. If Security has a defined veto, Security is accountable for exercising or not exercising that authority within its remit.
If an executive overrides Product or Security, the executive has changed the decision and accountability for that trade-off should move with the override.
The same logic applies when an organization hires outside expertise. A consultant may recommend entering a market, a lawyer may advise on legal exposure, or an AI vendor may provide a risk assessment, but leadership still decides whether that advice justifies action.
Buying expertise does not outsource the decision.
This is where persistent accountability gaps often become visible. Authority moves upward when important choices are made, while accountability moves downward when those choices produce bad outcomes.
The people with control remain protected by ambiguity, while the people closest to execution remain exposed to consequences they could not fully determine.
Why Organizations Keep Recreating the Gap
If the solution is conceptually simple, why does the ambiguity keep returning?
Because clear accountability changes incentives.
Imagine leadership assigns one person as the owner of a major decision. That person quickly discovers that several other teams control important inputs, constraints, budgets, and approvals.
Accepting sole accountability without corresponding control is dangerous, so the owner rationally asks for additional sign-offs, co-owners, committee review, or executive approval.
Those requests make sense individually.
Together they recreate the original gap.
Accountability unclear
↓
Name an owner
↓
Owner lacks sufficient authority
↓
Add approvals and co-owners
↓
Decision authority diffuses
↓
Accountability unclear againThe organization could solve the problem by transferring enough authority to make the accountability meaningful. That is often politically and operationally harder than adding another stakeholder.
Responsibility matrices are cheap.
Changing who can actually decide is not.
This is the point at which an accountability gap becomes meaningfully designed. Nobody needs to have intentionally planned the ambiguity; the organization only needs to understand that it exists and repeatedly preserve the structures that reproduce it.
The ambiguity has become part of the operating model.
Accountability Cannot Mean Finding Someone to Blame
There is another reason people resist clear ownership.
If accountability means being punished whenever an uncertain decision produces a bad outcome, avoiding accountability is rational behaviour.
People will seek committee approval, request unnecessary sign-offs, escalate decisions they could make locally, and document every objection defensively. Each action gives them evidence that somebody else participated.
A blame culture therefore manufactures the accountability diffusion it later complains about.
Useful accountability has a different purpose. It identifies who owned the decision so the organization can examine what was known, which assumptions mattered, what risks were accepted, and whether the reasoning was sensible at the time.
A good decision can still produce a bad outcome.
A poor decision can get lucky.
Clear accountability makes it possible to distinguish those situations because the organization knows which decision it is reviewing.
The objective is not to find a person to absorb the failure. It is to give organizational learning somewhere to attach.
Trace the Decision, Not Everyone’s Activity
Organizations already collect enormous amounts of information about work. Project tickets, emails, meeting attendance, approvals, comments, and code changes can show who participated without showing who had authority.
Someone may write most of the code and have no control over whether it launches. Another person may attend every meeting without ever making the consequential decision.
Activity is not accountability.
For important decisions, a small decision record is often more useful than a larger trail of participation. It can capture what was decided, who owned the call, which specialists advised them, what objections existed, which risks were knowingly accepted, and what would cause the decision to be revisited.
For example:
Decision:
Launch despite known latency risk
Owner:
VP Product
Advice:
Engineering recommends delay
Operations considers mitigation workable
Accepted risk:
Performance degradation for some customers
Review:
48 hours after launchThe point is not surveillance or paperwork.
Six months later, the organization should be able to reconstruct the reasoning rather than discovering that everyone remembers raising concerns but nobody remembers who chose to proceed.
The Override Test Exposes the Real Structure
A practical way to diagnose an accountability gap is to ignore the organizational chart temporarily and follow authority through the decision.
Start by asking who can make the initial call. Then ask who can block it, who can override that block, and what happens when the decision is escalated.
If authority moves at any of those points, accountability should move with it.
This produces a useful test:
Who made the recommendation?
↓
Who could reject it?
↓
Who could override them?
↓
Who made the final call?
↓
Who accepted the remaining risk?If the last question cannot be answered, the organization has probably found its accountability gap.
The next question is even more revealing: what happened the last time the gap caused a problem?
If ownership became clearer, the gap may simply have been an oversight. If another approval layer, committee, or nominal co-owner was added while authority remained just as difficult to locate, the organization has preserved the ambiguity rather than resolving it.
That persistence is the evidence that matters.
Healthy Organizations Still Share Responsibility
None of this means every decision should be permanently attached to one individual.
Routine team execution, collaborative research, creative work, and incident response can all involve legitimate shared judgment. Forcing a named executive owner onto every low-consequence choice would create bureaucracy rather than accountability.
Clarity becomes more important as consequences increase.
A reversible internal decision with limited impact can often remain within a team’s ordinary operating model. A decision involving major financial exposure, customer harm, security, regulation, or irreversible change deserves a more identifiable owner.
This makes accountability proportional rather than absolute.
The aim is not to make one person responsible for everything that happens. It is to prevent consequential authority from disappearing into collaboration.
When an Accountability Gap Stops Being Accidental
An accountability gap can begin innocently.
The organization grows. Responsibilities overlap. More specialists become involved, and a decision that once belonged to one person gradually becomes dependent on several teams.
None of that proves anything was intentionally designed.
The diagnosis changes when the gap becomes visible and the organization repeatedly responds without changing the relationship between authority and accountability.
A new matrix assigns an owner who still cannot decide. A committee adds coordination but obscures the final call. Another approval stage spreads participation without identifying who accepts the residual risk, while an escalation changes the decision without changing who will later be held responsible for it.
At that point, asking for another accountability workshop misses the deeper problem.
The organization has discovered that ambiguity distributes exposure, and its incentives keep reproducing that protection.
The useful question is no longer simply:
Who should own this?
It is:
Who currently has the authority, who currently carries the risk, and what would have to change for those two things to sit in the same place?
That is where accountability design actually begins.
Clear accountability requires more than names on an organizational chart. Responsibility has to be understood, authority has to be real, vetoes and overrides have to be visible, escalation has to transfer the decision, and consequential choices need enough traceability that the organization can later understand what was accepted and why.
Complex work will always involve many contributors. That is not the problem.
The problem is an organization where everyone can explain their part, yet nobody can identify who had authority to make the final call.
When that happens once, it may be an accident.
When it keeps happening after the organization knows how the system works, the ambiguity is no longer merely a gap in the design. It is part of the design.
