The blameless culture is about the benefits of not blaming the reports I think. If you manage a team you should see yourself at fault in a sense if something goes wrong just by implication. But you should try not to make it a big deal for respective team member and your higher-ups should try the same for you...
Making it clear who did it does not mean firing that person or making them feel like shit internally, it's a learning process, but the higher up you go the more you should feel bad (presumably you went through the learning process and earning big bucks as a result, so wtf)
> The blameless culture is about the benefits of not blaming the reports I think.
That may have been the case, but their are entire company values that insist on the blameless culture. This certainly sends a message organization wide to all levels that blame is not tolerated.
You are conflating "blameless culture" and blameless retrospectives culture.
You can 100% blame people for doing bad things. But in an engineering incident you want to find the RCA.
In SDE you may find the single git commit that took down everything, it has a author. Fine, there is blame. But why was there no review, no unit tests, no functional tests, QA, etc....
So you fire the engineer but make no other changes and it happens again, how is that helpful?
Making it clear who did it does not mean firing that person or making them feel like shit internally, it's a learning process, but the higher up you go the more you should feel bad (presumably you went through the learning process and earning big bucks as a result, so wtf)