Hacker News Reader

Comment by gheese | Hacker News Reader

Interesting how we drill in the idea that postmortems ought to be blame free. Not here.

That comes from (among others) Sidney Dekker, who recommends focusing on understanding the systemic reasons for failure: https://m.youtube.com/watch?v=8B5dChCifjA

For example, Jeff Harbers, who gets savaged on page 4, seems to have had some very perverse incentives imposed on him. What was it about the organisation that caused that? Considering that Microsoft was earning orders of magnitude more from each product than it was costing to build it, why did he treat the schedule as "a contract between the development team and himself"? So far, the answer to that is not in the document.

An interesting footnote: Jeff Harbers died in a plane crash 10+ years ago:

https://www.seattlepi.com/business/article/Jeffery-Harbers-1...

I kind of like how personalized the report is. A lot of modern methodologies seem to want to treat devs as interchangeable resources instead of real persons that may do good and bad things and learn from them. To me that makes work feel very dehumanizing.

Which isn't realistic in some cases. For example, if the postmortem determines that project management was lacking, that traces back to somebody, even if he or she isn't named.

Can't you stop past blaming the project manage by analysing the reason he/she did something wrong?

To expound, if you focus too much on “Jeff did X wrong”, the take home message of the postmortem is “don’t be Jeff”. If you focus on “trying to solve X by Y failed because Z”, you have the more generally applicable message, “don’t do Y to solve X unless you can deal with Z”.

Also keep in mind that Microsoft today is a robust corporation with many jealously defended fiefdoms; carefully picking the people to throw under the bus to protect your fiefdom and attack your internal competitors’ fiefdoms is an important skill set in such an environment. You could be seeing that in this postmortem, and that is exactly what people are trying to stop by keeping postmortems “blameless”.

But we have to look deeper. Project management doesn't exist in isolation. Any software development organization will typically have a project management office (PMO) with documented methodology, policies, procedures, templates, best practices, etc. If a particular project had poor project management then why did that happen? Did the PMO fail to provide the right resources? Is the hiring process for project managers faulty? Are we giving project managers the necessary training before assigning them to real projects?

Occasionally individuals really are to blame. But organizations get better results when everyone assumes positive intent by individual employees and focuses on finding process problems.

The Microsoft culture was one of fighting for your own resources. If you failed to receive them you were to blame.

Bill Gates formed a highly competitive internal environment. You were expected to stand up and fight for your cause - even against BillG himself. If you were right against Bill it was extremely good for your career. This was a time where the success of a BillG review was determined by how many F-bombs came out, and it was never zero.

For more information: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Also understand MSFT culture has changed dramatically since that time. Its no longer representative of the company today.

I think you limit them if you don't cast blame at all.

Obviously failures of process are interesting but sometimes it's because someone at the company fucked up.

It also depends on what the consequences of that fuck up are. I would love to be told exactly about all the things I am doing wrong. But I also need to get the chance to learn from them and improve.

> I think you limit them if you don't cast blame at all.

Yes. Then we get face-saving but at best pointless cop-outs like "we just didn't communicate enough".

"At best" pointless, because this easily leads to "hey we need to communicate more", which leads to an incessant meetings and things like 10 Slack channels to monitor...

The point is not to avoid pointing out mistakes. The point is to (a) allow mistakes and (b) learn from them.

Reply on news.ycombinator.com