I think it is telling that in this exceptionally long set of bullet points, almost nowhere does the author have a perspective of the end user or goals of the so

I think it is telling that in this exceptionally long set of bullet points, almost nowhere does the author have a perspective of the end user or goals of the software. Aside from the ambiguous "get stuff done" and the bullet point around learning from past failures, every piece of advice is internally-focused. "Here are the best way to get those TPS reports done." "How to leverage the experience of the best TPS report creators." "How to understand the TPS report process in your company." etc. Never once a comment on the analogous "should we be doing TPS reports?" Effective engineers, as per the title of the article, are those able to build software that does the right stuff. It fundamentally isn't about whether or not work was able to be accomplished within the constraints of a company. (What if the company's structure is dysfunctional and you adding yet another checkbox is killing the product?) Likewise, the insistence that ICs don't need to worry about these larger concerns because managers will is misplaced: every time an IC reinforces a dysfunctional structure, it makes it just that much harder for managers or more senior technical ICs to reform anything.