The cost of misplaced blame extends beyond the person receiving it. An organisation can spend time improving the wrong part of a process, leave an important risk unresolved, and make the next warning harder to obtain. The immediate response may look decisive while doing little to change the conditions behind the failure.
This can happen when responsibility for a result is assigned without a clear account of the decisions needed to produce it. A service owner may coordinate reliability while other people control release policy, staffing, and infrastructure investment. A project manager may maintain the delivery plan while a sponsor decides which scope changes to accept.
These roles can still have meaningful responsibilities. The problem is assessing them as though coordination provides unrestricted control. A useful examination asks what the person could decide, what they were expected to influence or escalate, and which decisions remained with someone else.
Locate the Decision That Could Have Changed the Outcome
Consider an on-call engineer responding to a service outage. The engineer follows the available instructions, contacts the appropriate specialists, and helps restore service. Investigation finds that a configuration accepted by the deployment process behaves differently under production traffic.
A review might ask whether the engineer could have restored service sooner. That is a legitimate question about the response. It is different from asking why the engineer failed to prevent a configuration from reaching production, particularly if they did not design the checks, approve the change, or control the release process.
Separating those questions helps identify the relevant responsibilities. The release team may need to examine validation. The service owner may need to review recovery instructions. The engineer may need additional practice with a diagnostic tool. The organisation may need to decide whether existing environments provide enough evidence before deployment.
A single event can therefore support several findings without assigning every failure to one person. The review should establish which action could reasonably have changed each part of the event and who was positioned to take it.
It also needs to avoid assuming that a person without final approval had no agency. The engineer may have been expected to report a known risk or use an available stop mechanism. Whether that expectation was reasonable depends on the information, access, time, and procedures actually available. Limited authority is relevant context, rather than an automatic answer to every performance question.
The distinction becomes especially important when the person blamed is simply the one most visible during recovery. Visibility identifies who was present, while prevention may depend on decisions taken much earlier and elsewhere.
Reporting Can Become Less Useful
If an employee repeatedly sees warnings treated as evidence of their own failure, they may become cautious about raising concerns. A tentative observation may be left unspoken until it can be proved. A risk report may be softened to avoid creating an issue the employee will then be expected to solve alone.
The organisation can lose time as a result. Early information is often incomplete, but it may still justify investigation. Waiting for certainty can leave fewer options for responding, especially where a release, customer commitment, or resource allocation is approaching.
Other staff may react by escalating almost every decision. That can be a reasonable attempt to clarify authority, but unnecessary escalation adds work and can obscure the issues that genuinely require attention. The question is whether the decision boundaries support appropriate local action.
Documentation can also change purpose. Instead of recording the information colleagues need, people may focus on establishing that responsibility belongs elsewhere. The records grow while becoming less helpful for deciding what to do next.
These are possible responses, not inevitable features of every organisation with a difficult review. Managers should look at actual evidence: delayed warnings, repeated requests for permission, unresolved escalations, and staff accounts of what happens when they raise a concern. The explanation may involve workload or unclear instructions as well as fear of blame.
Work Can Accumulate Around the Wrong Person
A named owner is often expected to resolve a problem even when the necessary change sits outside their remit. The on-call engineer might be assigned an action to prevent recurrence while lacking authority to alter the deployment system. The action remains open, and subsequent reviews treat its age as further evidence of poor follow-through.
The assignment needs to distinguish investigation from implementation and approval. The engineer might reasonably prepare a proposed validation check. A platform team may need to implement it, and a service owner may need to accept the resulting release constraint. Each participant needs an agreed commitment.
Without that distinction, the visible owner becomes a coordinator of repeated requests. They attend meetings, explain the risk again, and negotiate for capacity that nobody has committed. The organisation pays for this coordination while the underlying exposure remains unchanged.
Adding another approval can make matters worse if it does not address the actual uncertainty. A blanket requirement for senior sign-off might slow routine releases without detecting the configuration problem. The proposed control should be evaluated against the failure it is intended to prevent and the information the reviewer will have.
Google’s postmortem workbook emphasises concrete follow-up actions in the context of service incidents. That is useful discipline here: the action should describe an achievable change, identify the responsible work, and support verification. Assigning an ambitious outcome to one person is not enough to make the response executable.
The Risk Remains When the Explanation Stops Too Early
Blaming a person can provide an apparently complete story: the engineer did not diagnose quickly enough, the project manager did not control scope, or the account manager did not retain the customer. Each statement may contain a question worth examining. None explains the entire event by itself.
The service incident may still require better validation, monitoring, and recovery options even if the response was imperfect. A project may still need a sponsor to reconcile scope and dates even if its reporting was weak. A customer may still face an unresolved product limitation even if the account relationship could have been handled better.
Stopping at the individual explanation can therefore leave important corrective work unassigned. The next person inherits the same constraints and may encounter the same difficulty. Recurrence is a reason to revisit the explanation, though it does not by itself establish that all individuals acted appropriately.
The review should ask whether the proposed response reaches the relevant control point. If training is recommended, what missing knowledge would have changed the event? If a new sign-off is proposed, what will the approver be able to see and decide? If someone is replaced, which conditions will differ for their successor?
These questions help distinguish a response that changes the system’s behaviour from one that changes only the person occupying a role. They also make it easier to identify when individual development and wider process changes are both necessary.
Design Responsibility Around Workable Authority
Improvement begins by specifying the decisions a role can make. For a service owner, that might include setting operational priorities within an agreed budget, approving certain changes, and requesting decisions on larger investments. For an on-call engineer, it might include particular recovery actions and a defined route for obtaining additional authority.
Some responsibilities necessarily span several owners. A release may involve product, operations, security, and platform teams. The answer is not to give one coordinator unlimited power, but to establish how the relevant decisions connect and who resolves conflicts.
A dependency should include a commitment from the team supplying it. Naming a platform team in an action list does not allocate its time. If the preventive work competes with another approved initiative, the people controlling those commitments need to make the trade-off visible.
Delegation also requires information and capability. Permission to halt a release is difficult to use if the engineer cannot identify the relevant risk or does not know whom to contact afterwards. Training, access, instructions, and available support should be considered alongside the formal authority.
The organisation should retain a route for cases beyond the agreed boundary. An escalation needs enough context to support a decision: the observed problem, likely consequences, options considered, and the authority required. The recipient then needs to respond or explain what further information is necessary. Escalation should move the decision to a place where it can be made.
Evaluate Both the Response and the Conditions
An improved arrangement should be assessed through the work. Can staff raise a developing risk early enough to obtain a useful response? Are routine decisions made at the intended level? Do corrective actions have committed capacity? Can people explain what changed after the last incident?
Measures can help, but each needs interpretation. Faster escalation may be useful where decisions were delayed, while a lower escalation count may simply reflect clearer local authority. Action closure matters more when the completed work has been checked against the risk it was intended to address.
Performance discussions should reflect the same distinctions. A person can be assessed on how they fulfilled responsibilities within their role, used available information, and responded to changing conditions. The decisions of sponsors and process owners should also be examined where they shaped the result.
Selective accountability becomes harder to sustain when that decision chain remains visible. The organisation gains a more accurate explanation and a better basis for corrective action. The benefit is practical: less effort spent defending ambiguous responsibilities, more timely information, and changes directed towards the people and arrangements capable of improving the outcome.
