You’ve been in that retro. The slide already says This is a blameless postmortem. Someone pastes a Slack timeline, a facilitator reminds the room to focus on systems not people, and a fresh Jira epic swallows the action items. You nod along, camera off, and you think the same thing you’ve been thinking for six months: I still feel like I’m being written up.

We got fluent in the vocabulary of psychological safety years ago. Nobody asks “who broke this?” anymore. We ask “what allowed this failure mode?” and we mean it. Yet for a lot of engineers — especially the ones quietly absorbing operational chaos — the postmortem has shape-shifted into something uglier. It’s become a surveillance document that wears a learning-opportunity mask.

Here’s how it actually works. The incident timeline lands in a shared folder, and an innocent question floats up in the thread: “Was the alert acknowledged before the escalation policy triggered?” Sounds factual. But it’s really a timestamp with your name on it, and it’s sitting there while your manager drafts quarterly feedback. The system doesn’t have to point a finger. It just has to record who touched what, and when, and let a well-trained imagination fill in the rest.

The kicker is that nobody set out to build it this way. Teams genuinely believe thorough postmortems prevent recurrence, and thorough means attribution. Who logged in. Who merged. Who approved the rollback. The document collects all of it without malice, then quietly hardens into a competency paper trail. Come calibration season, a pattern of “always being in the timeline” — even if you were the one who caught the bug, stayed up, wrote the fix — gets read as a pattern of being close to incidents. And that’s a pattern that costs you.

I’ve watched people game this in real time. They learn to never be the last person to touch a config change. They make sure the incident commander role rotates away before the retrospective. They write action items so vague no single human can be tied to their completion. This isn’t laziness; it’s survival. When “blameless” means we won’t say it out loud but we’ll sure remember, smart people stop volunteering for the pager shadow rotation. They stop saying “I’ll own the fix.” They stop caring about the system and start caring about their paper trail.

The real giveaway isn’t what happens in the meeting — it’s what happens three weeks later, when a senior engineer quietly asks to be moved off on-call and leadership treats it like a motivation problem instead of a trust problem. Or when the action items that emerged from the incident aren’t new runbooks or circuit breakers, but a private coaching note: “Improve response time under pressure. Communicate more clearly in Slack during degraded state.” That’s not a system improvement. That’s a performance review bullet wearing a postmortem hoodie.

Real blameless culture doesn’t live in a meeting template. It lives in an institutional refusal to let incident timelines become résumé lines. It means postmortems celebrate the person who showed up five times in the log, not flag them as “risk exposure.” It means the overwhelming majority of action items are about automation, not about coaching conversations. Until that’s true, the word “blameless” will just be the new “we’re a family” — something you hear right before the part that hurts.