When Two Teams Share a Failure — Accountability Without Blame

Most delivery teams know how to remove a person's name from a postmortem sentence. Far fewer have examined what should replace it when the order team marks a split shipment complete, the warehouse team still holds an unacknowledged parcel, and both dashboards are green. That is where accountability without blame becomes difficult: not when nobody owns the incident, but when ownership exists in several unlike forms.

The weak answer is to call the failure shared and move on. The harsher answer is to decide which team was more at fault. Both answers waste the evidence, because the first dissolves responsibility while the second compresses a system boundary into a moral score.

The boundary deserves a better account.

The Incident at the Seam

Picture an ecommerce platform handling a split order. The order service owns the customer state; a warehouse connector owns acknowledgements from two fulfilment sites. The customer should see complete only after both parcels are accepted into the warehouse flow.

On a Friday release, the order service emitted complete after receiving its final internal allocation event. Its tests passed because every allocation had reached a terminal state. The warehouse connector still held one parcel in awaiting_ack, but its own dashboard was green: the message had been sent, retries were active, and no connector error had fired.

The customer received a completion email while half the order was still sitting outside the warehouse process.

Neither team ignored a red alarm. Neither concealed a known defect. Each system reported success in its own dialect, and no shared contract defined which signal had the right to close the customer journey.

A conventional review can still make this personal. The order team “closed too early”; the integration team “failed to acknowledge”. Those statements describe events, but their grammar quietly appoints defendants. Google SRE's blameless-postmortem guidance makes the more useful assumption: people acted with good intentions and the information available to them, so the review should investigate why that information was incomplete or misleading.

That assumption opens the evidence. It does not settle the account.

Three Questions Hide Inside “Who Owns This?”

Cross-team reviews often ask one ownership question when they need three. The distinction matters because a team can contribute to the cause, have little control over the missing condition, and still own part of the repair.

Cause Is a Map, Not a Verdict

The causal account should remain joint. No single event explains the false email. The order service treated local completion as customer completion; the connector treated successful dispatch as sufficient progress; the interface carried no authoritative warehouse-acceptance signal. Release criteria tested each side separately.

Remove any one of those conditions and the incident may not occur. That makes the sequence a causal map: it shows how the decisions and signals connected. It does not require the review to decide that each connection deserves the same weight.

Joint diagnosis keeps both teams looking at the same system.

Accountability Names a Decision Within Control

Accountability is narrower. It asks which decision, safeguard, or escalation sat within a team's reasonable control at the time.

The order team controlled the rule that published complete. It could have refused to derive customer state from allocation state alone, although it could not consume a warehouse acknowledgement that did not yet exist. The integration team controlled the connector's acknowledgement model and alerting, although it did not control the customer's status transition.

Those are distinct accounts, not competing excuses.

This is what decision accountability means here: a named team can explain a choice it had the authority and information to make. If the term feels punitive, test it against the evidence. Can the review point to a real decision boundary, or is it attaching a broad outcome to whoever stood nearest?

Repair Ownership Follows the Ability to Change

Repair asks a forward-looking question: who can change the condition that would otherwise permit recurrence?

That owner may not be the largest causal contributor. The platform architecture lead, absent from the release, may need to fund a shared contract and settle which state is authoritative. The integration team may need to expose a new signal. The order team may need to change its transition rule.

The team best placed to prevent recurrence can own the largest repair without being declared the most guilty.

This distinction gets missed because action lists usually sit at the end of a review, after the causal language has already assigned emotional weight. Put repair ownership inside the reasoning. Causes stay connected, decisions stay bounded, and obligations follow the ability to change the system.

Equal Shares Are False Precision

The fair objection is that leaders need a clear answer. If two teams contributed, “shared” can become a polite way to leave every difficult action between backlogs. A percentage split seems to force clarity.

It forces the wrong kind.

A 50/50 allocation treats unlike facts as units of one thing. Yet the order team controlled a customer-state rule, the integration team controlled a missing signal, and leadership controlled whether the boundary had an owner. Adding those into a moral total produces arithmetic without measurement.

Equal shares can hide unequal opportunities to prevent recurrence.

The alternative is not softer language. It is sharper language attached to work: name the controlled decision, state the evidence available then, and assign the repair to the party able to complete it. Each statement can be challenged on facts. “Half responsible” cannot.

Psychological safety does not require low standards. Amy Edmondson describes safety and accountability as a false trade-off: learning needs openness, but it also needs structure, shared goals, and leadership that guides the process. A review that protects candour while leaving obligations vague has kept only half of that bargain.

Safety lets the account be told. Accountability makes the account useful.

The Boundary Account

For a shared failure, I use three lenses on the same boundary. This is not another postmortem template. It is a way to stop three different questions collapsing into “whose fault was it?”

• Control — the decision space: What could this team change, stop, validate, or escalate before the incident? Authority matters. Do not assign a control to a team that needed another group's permission to exercise it.
• Visibility — the evidence space: Start with the signal itself. Who could see it, and what did the documented contract say it meant? Hindsight must not upgrade an ambiguous signal into an obvious warning.
• Repair — the recurrence space: Now ask who can remove or contain the condition. Give the repair one decision owner, even when several teams contribute to delivery.

In the split-order case, control sits with the two local state rules, visibility breaks at the missing warehouse-acceptance signal, and repair spans both services plus the unowned interface. One incident produces three different answers because the lenses ask three different questions.

The three lenses are deliberately asymmetric. They do not add up to 100 per cent, and they should not. Their job is to preserve distinctions that a blame score erases.

The method fails when “control” is written with hindsight. A reviewer can always invent something a team could have done after seeing the incident. Keep the test narrower: did the team have the authority, a usable signal, and a reasonable moment to act? Without all three, the account has turned blame into cleaner grammar.

If control was absent, look upward before looking sideways.

A recurring boundary failure may be evidence that neither team was authorised to define the shared contract. In that case, asking the teams to “collaborate better” pushes a governance omission back onto delivery staff. The leadership obligation is not to mediate a quarrel; it is to create and fund the missing decision boundary.

Apply the Account to the Split Order

The order-platform team goes first. It controlled the complete transition and could stop using local allocation state as the final customer signal. It could see that warehouse acceptance was absent from its model, though it could not see the connector's live acknowledgement state. Its repair is to make complete depend on an authoritative fulfilment condition and to degrade safely when that condition is unknown.

The warehouse side is different. It controlled the acknowledgement model and could expose accepted, rejected, and timed_out as explicit contract states. It could see the parcel waiting for acknowledgement, but its green dashboard described connector health rather than customer-journey completion. Its repair is to publish the missing state and alert when an acknowledgement exceeds the agreed window.

One account sits between them. Both teams helped release two locally valid models with no end-to-end definition of completion. The repair needs one named owner for the interface contract, contract tests that exercise split orders, and a release criterion based on the customer-visible state.

Leadership carries the fourth obligation. Someone must give that interface owner authority across both backlogs and protect the work from being displaced by local feature priorities. Without that decision, “joint action” means two tickets waiting for each other.

A shared cause still needs separate commitments.

Notice what the account has not done. It has not declared both teams equally responsible. It has not absolved either team because the failure was systemic. It has attached specific decisions and repairs to the places where control, evidence, and the ability to change actually sit.

Specificity is doing the humane work.

Dignity Requires a Separate Path for Misconduct

Blameless analysis assumes good-faith work under real conditions. It should not be stretched to cover deliberate concealment, reckless disregard, or a repeated refusal to follow a known safety control.

Those cases need a separate managerial or disciplinary process with its own evidence and safeguards. Mixing that process into the learning review damages both: participants stop speaking candidly, while serious conduct concerns get handled through suggestive postmortem wording rather than due process.

Keep the boundary clear. The incident review explains how the system produced the outcome and assigns forward repair. A conduct process decides whether behaviour crossed an established line. One meeting should not pretend to do both.

That separation also protects people who made ordinary mistakes. They can give a full account without wondering whether every sentence is becoming a performance charge. In return, they accept named obligations to repair what sits within their reach.

When two teams share your next failure, can you name one causal map, each team's controlled decision, and the owner able to prevent recurrence?

If you have used a different split that survived contact with two real backlogs, that comparison would interest me.