Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This article is creating a straw man. You don't do a 5 Whys and fix what you think the root cause was, you fix the issues that were most serious. If there are problems too big to tackle immediately, put in short term mitigations and incorporate your new understanding of the system's reliability into your future plans.


Doubly so because you don't use the 5 whys during the emergency. You use it during the post mortem. After you've unplugged the burning computer. After you've gotten the ship out of the immediate existential threat. If the computers are burning due to faulty wiring no amount of triage is going to stop that from happening next week. If ships are getting holes because the currents have shifted and bergs are appearing in places where hobby sailors frequent then the maps and some public outreach are the right solution.

I dunno who taught these people about the 5 Whys, but someone (possibly themselves) has done them a tremendous disservice.


More importantly, it's about not starting to fix things until you understand the context. The fix might be at any of the levels, but it's pointless to speculate where the fix goes if you don't understand the whole system/network/causality chain to an adequate degree. An "adequate degree" might be shallow overview, a deep dive, or anywhere in between, but it's still necessary.


Couldn't have put it better myself - this article was clearly written by someone who's worked in an entirely disfunctional environment - or has read an article on "five why's" and missed the whole rest of the problem management framework.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: