Yeah, I can’t really speak to the emotions that bring about a post like this, maybe it’s the places I’ve worked but a few thoughts:<p>The person who “caused” the incident always feels worse than anyone else around them, and this can be a real problem. Often times I don’t want you to change your processes or slow things down or add huge approval gates for changes. Add the test or make whatever small improvement there is and move on.<p>2. Literally so often the “problem” is that feature development is prioritized over stability. And this is fine, but are you really going to invite the VP of eng and VP of product to every retro and be like “it’s on you!” And maybe it’s not specifically the VP maybe the director misunderstood the directive, maybe the manager got it in their craw to pushed getting a projected through, or maybe it’s a confluence of all of these issues.<p>If one team makes a tool with bad UX and an uncareful engineer on another team causes an incident because of that UX, whose fault is it?<p>Again, obviously you work in an environment where the opposite is true, but assuming an incident must have one person to hold accountable sounds nightmarish to me, not as the person who might get blamed. But as the person might watch the chaos of said system.<p>That all being said, what you said about balance is right. But I don’t think it’s about being blameful, i think being a culture of blame and being a culture of accountability are two different things. One must be able to talk openly and pointedly is correct.<p>And there are a few exceptions. If you lie or blatantly ignore processes, or otherwise act callously, then yes it is your fault.