I agree with you, but there are a few things to keep in mind: 1. The engineer/manager impedance mismatch. We're used to having our "subordinates" (machines) gi

I agree with you, but there are a few things to keep in mind: 1. The engineer/manager impedance mismatch. We're used to having our "subordinates" (machines) give blunt negative feedback. "Your shit don't compile. Line 189; fix the fucking thing." Most managers are extremely thin-skinned and would rather fire people to silence dissent than have their decisions (as much as they affect other people) questioned. We're aware of our imperfect job performance because it's literally impossible to become good at software without bugs along the way. They have a child-like innocence of their own imperfection, because no one ever fucking tells them (for fearing of getting fired) when they make bad calls. 2. Most organizations use ambiguities in performance evaluation to hide things and like it that way. Fairer performance reviews diminish middle-management and executive power. The problem with healthy corporate cultures (e.g. Valve, pre-apocalyptic Google) is that it's hard to hire external executives. (That's why Google sold its culture off.) 3. Objective performance reviews for software are impossible. Automated code comprehension isn't even theoretically achievable over arbitrary code. As much as the "shoot me an email"/"let's synergize" apes have tried to drive out all creativity and R&D, the intrinsic convexity (see: http://michaelochurch.wordpress.com/2013/03/14/gervais-macleod-9-convexity/ http://michaelochurch.wordpress.com/2013/03/14/gervais-macle...) of what we gives it enough of an R&D nature to make objective performance assessments impossible.