I came across a story recently on hacker news:
Dear OP, Good luck with that.
Your boss isn’t (necessarily) a bad guy. Software development is a complex dynamic system so it’s hard to see what’s really going on. Intuitions about how to fix things are often wrong and many management interventions are unproductive.
What’s unfortunate about this particular fail, is not that it’s ineffective, but that it poisons the environment. Organizations can develop a pervasive culture of finger-pointing, fear and defensiveness. It becomes impossible to discuss issues because anything imperfect has to be someone’s ‘fault’. The result feels like the org-chart of fear from Joseph Heller’s novel “Something Happened”:
“In my department there are six people who are afraid of me, and one small secretary who is afraid of all of us. I have one other person working for me who is not afraid of anyone, not even me, and I would fire him quickly, but I’m afraid of him.”
All of this takes a toll on the people. If you take an activity that many people happily do for free, combine it with some of the highest salaries of any profession, and produce a work-life that sucks, that’s sub-optimal. It’s not, unfortunately, unusual: many software people are less than thrilled with their work.
Why should anyone care? Two reasons: First, there is considerable evidence that employee well-being has a positive, causal impact on performance. Second, if you can structure work so that it supports, rather than undermines your team’s well-being, then you should. It’s morally the right thing to do, and you’ll make your own work life more meaningful in the process.
Improved well-being is clearly both a motivator for, and desired outcome of, Agile development practices, but to my mind it doesn’t go far enough. I’m looking for connections between how we build software and the relatively new fields of positive psychology, and positive organizational scholarship. Positive psychology is concerned with taking healthy people and increasing their well-being. By analogy, we might take healthy development teams and help them really thrive. For lack of a better name, lets call this line of inquiry ‘Positive Software Engineering’.
FWIW, here’s my real answer to the OP: Instead of putting a “person to blame” field in every bug report, suggest he put all the hacker’s names (and maybe photos, too) in the product itself. Most products have an “About” link or dialog. Put it there.
No one wants their name on something they’re not proud of. Open source projects credit their hackers; game developers, too. If he needs a further precedent, show him how Steve Jobs put the original Mac developer’s signatures inside every Mac. Your boss can be positive, and be like Steve. What’s not to like?
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}