> I would really love to read about a blameless postmortem that happened in a dying company where everyone was backstabbing each other. Now, that would be a good story!

It doesn't have to be a dying company. Many companies that try to transition from startup -> small company -> medium company -> megacorp tend to run into periods of change and insanity in every one of those transitions. I suspect its one of the reasons why most companies die out at some point: the failure to focus on product and focusing instead on politics. Teams turtle down, avoid responsibility (i.e. blame) at every opportunity, the product turns to shit as nobody wants to move a muscle in case anything breaks.

I have been recommended the book "Turning the Ship Around" for an account of how to grow a new good culture in a decisively bad one. It's probably not an exact recipe for being able to hold blameless postmortems, but I suspect it could contain some valuable information.

If anyone knows how well it applies to this situation, please do tell me!

TBH I’m not sure of its relevance to postmortems specifically but I’d highly recommend the book. Turn the Ship Around, Marquet. Great audiobook too.

TTSA is a great book and may help. But it is a leadership book. I still strongly advise it, at least to know nice things are possible.

I think you can go too far in that direction. I worked for a big European software company, there was a deep culture of never blaming people, so any postmortem inevitably ended with a new process or training or transversal synergy coordinators, when sometimes the root cause was just bad developers

Assuming that "bad developers" is indeed the root cause, that still sounds like a systemic issue to me:

a) are the developers bad because they were hired that way? maybe the hiring process is broken

b) are the developers bad because they are not managed/trained properly? maybe managers aren't doing their job, and maybe it's not even their fault because they did not get training in how to manage people in the first place

c) if you implement extra layers (or "synergy coordinators") it probably means that the company hasn't figured out how to communicate properly

Management is ultimately responsible for everything. Even if you have the worst developer in the world on your team, management decided to hire them, retain them, assign them responsibility, and failed to improve their performance. That said, plenty of people are just self-serving dickheads. Could they be reformed? Probably. Is that the company’s responsibility? Only up to a point.

I’ve worked with people that I was responsible for training in DevOps, from a starting point of having only ever done GUI-based Ops. Basically starting from complete technical incompetence, and plenty of them succeeded, because they were good people with good attitudes. I’d wager a small team of people like that would always be more productive than a team of any sized comprised of arrogant, combative, CYA assholes.

So this came from management. It is John Allspaw that pushed for them, at the time VP of Eng iirc.

For how to do it... there is a community at https://www.learningfromincidents.io/ trying to help.

The consensus so far is to test waters and do some "in parallel", if necessary rogue-ish. The output is so superior in term of learning that you may then use this result as a trojan horse.

You need to carry your water.