Skip to content

Support Line Postmortem

Retrospective audit — instantiates Sustainment-Reach Alignment

After a support line buckles or a front culminates badly, reconstructs why the reach outran the sustainment and files the failure as a reusable scenario.

Overextension teaches its clearest lessons only in hindsight — at the moment a line breaks everyone is busy surviving it, and by the next expansion the lesson has faded to folklore. Support Line Postmortem is the retrospective audit that captures it before it evaporates: after a line fails or a front culminates badly, it reconstructs where the front actually was, how far the sustainment truly reached, and the sequence by which the gap opened — then writes that up as a named scenario the next campaign can plan against. Its defining move is learning, not control: it touches no live decision and produces no gauge or gate, but converts one expensive failure into a reusable entry in the organization's scenario library, so the same overreach isn't rediscovered from scratch. It is backward-looking on purpose.

Example

A platform company expanded to eleven cloud regions in a year to chase latency wins; then a routine dependency upgrade cascaded into a multi-region outage the on-call rotation couldn't contain. The Support Line Postmortem convenes once service is restored. It reconstructs the real "front" — not the eleven regions on the roadmap, but the number the reliability team could actually sustain, which turns out to be about seven — and the "line": the shared control-plane and the on-call staffing that had to cover all of them.

It maps the sequence: region count outran runbook coverage, then outran on-call depth, until a single change had eleven blast radii and seven engineers to answer them. No individual is blamed; the output is a filed scenario — "region count outran reliability staffing by ~1.5×; culmination showed up first as alert fatigue" — with the leading indicators that were visible weeks earlier. The next expansion plan opens with that scenario on the table, so the culminating point is designed for instead of rediscovered at 3 a.m.

How it works

  • Reconstruct the real front, not the planned one. Pin down where the operating front actually was and how far sustainment actually reached at failure — usually both differ from the plan.
  • Trace the gap's opening. Sequence the steps by which reach outran support, and mark the leading indicators that were visible before the break.
  • Blame the line, not the people. Hold it blameless so the reconstruction stays honest and the causes stay structural.
  • File a reusable scenario. Distill it into a named entry — trigger, signature, leading indicators — added to the scenario library for future planning and stress tests.

What distinguishes it is retrospective reconstruction that authors library scenarios, rather than consuming or enforcing them.

Tuning parameters

  • Trigger threshold — how bad an event earns a full postmortem (only collapses, or near-misses too). Including near-misses harvests more lessons but costs time.
  • Reconstruction depth — a quick timeline vs. a full front-and-line forensic. Deeper finds root structure but delays the writeup and the lesson.
  • Blame stance — strictly blameless vs. accountability-seeking. Blameless surfaces more truth; accountability satisfies stakeholders but suppresses candor.
  • Scenario abstraction level — file the specific incident vs. the general pattern. Too specific won't transfer; too general won't warn.
  • Distribution and recall — who receives the scenario and when it is re-surfaced (e.g., at the next expansion gate). A filed-and-forgotten scenario teaches no one.

When it helps, and when it misleads

Its strength is that it is how an organization stops paying for the same overreach twice — the one mechanism here that improves the next campaign rather than the current one, by turning a failure into an anticipatable pattern. Done well it follows the blameless postmortem discipline: examine the systemic conditions rather than assign individual fault, so people tell the truth about what happened.[1]

Hindsight flatters the analyst — it is easy to write a postmortem that makes the break look obvious and a scapegoat look culpable, which yields a tidy story that transfers no real warning. A postmortem can also over-fit to the specific incident, filing a scenario so particular the next (differently-shaped) overreach walks right past it. The classic misuse is the blame-assigning postmortem, run to close the book on an incident rather than to learn from it. The discipline is to keep it blameless, reconstruct the front and line as they actually were rather than as the plan assumed, and abstract the lesson to the pattern that will recur.

How it implements the components

Support Line Postmortem realizes the learning side of the archetype — the components a retrospective audit can fill:

  • reach_scenario_library — its product: each postmortem authors a named, reusable failure scenario (trigger, signature, leading indicators) added to the library.
  • operating_front_definition — the reconstruction pins down where the front actually was and how far sustainment truly reached at the moment of failure, usually correcting the planned definition.

It does not monitor the live line whose history it reconstructs (net_delivery_metric, line_health_monitor) — that is Net Supply Ratio Dashboard; and the scenarios it files are run forward as stress tests by Lead-Time Stress Simulation, not here.

Notes

A postmortem's output is worthless unless it re-enters planning: file-and-forget is the dominant failure mode. Couple it to the scenario library that Lead-Time Stress Simulation and the next expansion's Reach Limit Gate actually read, so the lesson meets the decision it was meant to change.

References

[1] Blameless postmortem — an incident-review discipline, widely adopted in site-reliability engineering, that examines the systemic conditions behind a failure rather than assigning individual fault, on the premise that people report the full truth only when they are not on trial. ↩