mediumNewGoogleAnthropicCoreWeave

How do you run a postmortem that actually changes something?

Most postmortem documents are written, filed and never read again. The three parts that decide whether one changes anything, why action items without a named owner and a date are decoration, and the meeting rule that keeps blamelessness from becoming vagueness.

Updated Sep 2026 · Grounded in real AI infrastructure interview loops and written to a senior-engineer editorial bar, with every number worked and every diagram hand-built.

more free answers with an account · no card

The concepts behind this question

Ranked by how closely each one overlaps this question's topic, so the first card is the thing to read if the answer above moved too fast.

Foundational

🧭 Ownership & Judgment

Mentoring and Growing EngineersMentoring on an infrastructure team happens mostly under pressure, during incidents and reviews, where the instinct to take the keyboard resolves the problem faster and teaches nothing. The method that works is the mentee driving while the mentor asks questions, with a takeover condition agreed in advance so nobody negotiates it at two in the morning. It costs time, and choosing which situations can absorb that cost is the judgment being assessed.

Core

🧭 Ownership & JudgmentSign in

On-Call Narratives That LandEvery infrastructure loop has a round where you are asked to tell an incident story, and the interviewer is not listening for drama. They are listening for the signal you read, the decision you made under time pressure with incomplete information, the evidence you had for it, and what you changed afterward so the same page never fires again. This page gives the structure that makes an incident story land in four minutes, two worked narratives from GPU fleet and serving work, the follow-ups that test whether the story is real, the version that sounds heroic and fails, and what separates the senior telling from the staff telling.

Advanced

🩺 Fleet Reliability & Observability🔒 Premium

Incident Response for GPU FleetsAn incident on a GPU fleet is a training run that stopped, a serving endpoint burning its error budget, or a fleet-wide symptom nobody has explained yet. The response has a shape: detect, stabilize, diagnose, repair, return through the gate, write it up. The stabilizing move (drain the node, restart from checkpoint, or shift traffic) comes before the diagnosis, because a frontier run loses more per minute than any investigation is worth. This page gives the triage order, the 3am decision tree, the spare-capacity arithmetic behind drain-and-replace, and what a fleet postmortem has to contain.

Foundational

🧭 Ownership & Judgment

Talking About Cost and Capacity with LeadershipInfrastructure engineers are asked to justify large numbers to people who do not share their vocabulary, and the conversations go wrong in predictable ways: a technical objection with no alternative, a forecast with no assumptions, or a cost quoted in a unit the listener cannot act on. What works is a small number of costed options, a stated recommendation, the decision needed by a date, and every figure expressed in whatever the listener actually controls.

Explore the full curriculum →

UP NEXT ON YOUR JOURNEY

Next in this trackTell me about scaling a system by ten times. What broke, and in what order?Next in this trackLeadership wants to buy another 2,000 GPUs. You think it is the wrong call. What do you do?Next in this trackA vendor says your configuration is the problem. You think it is their firmware. How do you proceed?

FEDITOR'S NOTE

Scored on separating contributing factors from a single root cause, on action items having owners and dates and being tracked, and on blameless meaning specific about systems rather than vague about everything.

DISCUSSION · 0

No comments yet — be the first to share your approach.