Unfortunately, there are folks who jump right to the RCA, with often devastating impact upon their ability to deliver functional products reliably and on time.

Unfortunately, there are folks who jump right to the RCA, with often devastating impact upon their ability to deliver functional products reliably and on time. Moreover, when doing an RCA, you need to be able to objectively examine every aspect of the decision making, implementation, and execution tree. Not allowing every decision to be questioned and reviewed means you enable a route for poor decisions driven by other than business/technical needs to enter in. The irony in this, is that these non-questionable, sacred-cow like requirements, which cannot be investigated without causing sturm und drang as well as profound political problems, are often themselves, the root cause of multiple/many problems that one encounters. That you cannot investigate the entire space of issues means that there will be regions of terra incognita for your analysis. I've seen this at every single company I've ever worked at. Including my own startup. Much of what I learned about this came from my time at SGI/Cray, where specific holy grails could not be questioned. It is very ... very ... hard, to admit that your systems could somehow be problematic. It is tremendously humbling to see conclusive proof. It changes your engineering mind set when you do accept this, from being defensive to something better. Your architectures improve, your assumptions are less WAG-ish.