The Blameless Postmortem With a Name in It

Between the postmortem and the cover sit 6 quiet assumptions, and the incident is the story of one of them failing.

This is the thesis: a postmortem that names a person and describes their error is a blame document whatever the header says, and the mismatch between the label and the content is worse than honest blame, because it removes the language for talking about the real cause.

This is an opinion, and accountability is genuinely necessary, and the rule of thumb at the end is where I land.

Why the label is not the practice

The blameless is the systems focus, and the systems focus is the how rather than the who, and the how is the design, and the design is the fixable, and the fixable is the improvement, and the improvement is the point, and the point is the not the person, and the not person is the label, and the label is the paragraph's contradiction.

The paragraph said the engineer deployed without the review, and the said was the fact, and the fact was the not the analysis, and the analysis is the why the review was skippable, and the skippable was the process, and the process was the fixable, and the fixable was the absent, and the absent was the person's naming, and the naming was the blame, and the blame was the label's lie.

The lie is the cost, and the cost is the next incident's honesty, and the honesty is the absent, because the engineer who reads the named postmortem learns that the label is the cover, and the cover is the protection's absence, and the absence is the silence, and the silence is the unreported near miss, and the near miss is the lost learning, and the learning is the safety's substance.

Why accountability still matters

The accountability is the not the blame, and the not blame is the distinction, and the distinction is the response, and the response is the pattern's consequence, and the consequence is the role's change, and the change is the accountability, and the accountability is the necessary, and the necessary is the not the document's content.

The single mistake is the system's product, and the system is the training and the tooling and the review and the pressure, and the four are the organisation's, and the organisation's is the fixable, and the fixable is the postmortem's subject, and the subject is the not the person, and the not person is the discipline.

The repeated pattern is the different, and the different is the conversation, and the conversation is the private, and the private is the not the document, and the not document is the fix, and the fix is the separation, because the postmortem is the system's record and the performance conversation is the person's, and the two should never be the same artefact.

What the honest version looks like

The honest version describes the sequence, and the sequence is the events, and the events are the roles rather than the names, and the names are the unnecessary, because the reader does not need to know who, and the who is the blame's entry, and the entry is the closed by the role.

The honest version asks what made the action reasonable, and the reasonable is the context, and the context is the pressure and the tooling and the information, and the three are the system's, and the system's is the fixable, and the fixable is the action item, and the action item is the point.

The honest version names the contributors, and the contributors are the missing check and the absent alert and the unclear runbook, and the three are the nobody's, and the nobody's is the fix's assignment, and the assignment is the improvement, and the improvement is the document's value.

This is the same distinction as the on-call rotation that needs a second human, and the common root is the property, not the platform.

The rule of thumb

The postmortem should describe the sequence in roles, ask what made each action reasonable at the time, and produce action items about the system. The performance conversation belongs elsewhere, and putting a name in the document is the blame whatever the header says.

Use roles, not names. The role is the deployer, and the deployer is the anybody, and the anybody is the system's product, and the product is the fixable, and the fixable is the point, and the point is the discipline.

Ask what made the action reasonable. The reasonable is the context, and the context is the system's, and the system's is the action item, and the action item is the fix, and the fix is the question, and the question is the discipline, because the unreasonable action is the person's failing and the reasonable action is the system's.

Write the action items about the tooling and the process. The tooling is the check that should have existed, and the process is the review that should have been mandatory, and the two are the fixable, and the fixable is the point, and the point is the discipline.

Keep the performance conversation separate and private. The separate is the person's, and the person's is the manager's, and the manager's is the not the document, and the not document is the fix, and the fix is the separation, and the separation is the discipline.

Test the document by asking who would feel safe reporting the next one. The safe is the culture's measure, and the measure is the test, and the test is the honest, and the honest is the fix, and the fix is the read-through, and the read-through is the discipline, because the document is the signal and the signal is the behaviour.

Where I land

Blameless is a practice and not a header, and the practice is describing the system rather than the person. A postmortem that names somebody and explains their mistake is a blame document with a disclaimer on it, and the disclaimer makes it worse, because it takes away the vocabulary for talking about the cause.

The postmortem said blameless at the top and named an engineer in the third paragraph, and every engineer who read it learned the same thing. Name that one property in review and this class of bug gets hard to ship.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud