All I am saying (and I think the author tries to make that point) is that it is questionable that you are going to create such an environment by pointing fingers and treating devs bad.
My very limited experience (I am the mobile lead in a company) has taught me, having done all of that myself in the beginning, that I wont achieve anything this way.
What I saw is that people got defensive by default, protective about their work (so no one can attack them for errors they made), the company started bleeding talent (what person is going to like working in such an environment?) and so called "code monkeys" never improved, because they didn't believe that they could achieve anything meaningful by themselves.
For some companies this might work in a way that I can't understand, but I changed, because frankly I didn't like to work in such an environment myself, and it did have to some degree positive effects.
People share more information, there's less pressure generally and there is more trust in general that everyone is doing their best, and if unable to complete some task, will ask for help.
By the way, here's a Google I/O talk from 2010 about engineering leadership that covers the problems mentioned in the article - I cannot recommend it enough: http://www.youtube.com/watch?v=skD1fjxSRog