I think the article assumes "all other things being equal" - so given an engineering (or sales, or marketing) capability equal to that of another business, thes

I think the article assumes "all other things being equal" - so given an engineering (or sales, or marketing) capability equal to that of another business, these factors are what the author believes differentiate the business enough to be able to perform better, and especially in execution. And I don't think this stuff is BS; "updating beliefs" is important, as many business decisions are made based on a belief - especially if your product has not gone to market yet. "Updating beliefs" is also reflective of an openness to change, and being able to cope with being wrong at times - people find it hard to find out (or be told) that they are wrong - their ego is hurt, they fight back. "Don't do BS," specifically the documentation side of things, strikes a particular chord with me, as it's something that I've had to do recently, it goes against everything I know about writing software, so I am 100% happy to see it being spouted here! All of the points made in the document are about execution, but they're about executing as a business, and not a "how to make your engineers perform better" guide. That said, these practices will _probably_ have your engineers performing better anyway, but you'd need to dig into how each change affects the psychology of those doing following these practices in order to understand how/why.