Why I added a "Peson to Blame" field to our bug tracking system

Oh you also get a nice dose of tongue-lashing from the team if you write a time bomb into our unit test suite.

Could I have named it something more politically correct so feeling doesn't get hurt? Sure. But what's the fun in that? ... so why not throw in a small dose of public shaming for good measure?

Those statements are huge red flags to me.

As the boss, it's easy to forget that you're the boss. The people who work for you will perceive and experience your actions very differently than you. Something is "fun" to you may be hell for them because they don't have power. Your goal is a good one, but I get the impression that you don't have an intuition for power asymmetries.

As the boss, finding "fun" in "public shaming" is a really, really, bad idea. It may be fun to you, but to the person being shamed, it's not any fun when it's coming from a superior.

The day my management puts a "person to blame" field in the tracker because he thinks public shaming is amusing is the day I update my resume and GTFOD with great haste because that's the day my management stops caring about my ability to be anything other than a scapegoat.

I totally agree. It's adios time. At least in NYC there are hundreds of developer jobs unfilled with great pay and no "person to blame." Great developers are hard to find, apparently, so are great bosses.

So a few days ago I added a "Person to Blame" field to our bug tracking system... I thought I'd share how the "Person to Blame" field works for our team.

You added the "Person to Blame" field a few days ago. Therefore you're describing how you think the field will work.

To be clear, I don't have a horse in this race. I'm sole dev on the things I make, so the bugs always point back to me. But I do notice that you're arguing from intention, rather than from experience. Whereas the arguments others have raised against this field are largely based on observations about what similar decisions have done to other teams.

I also have to wonder about your idea that blaming people is going to change anything (even if it is friendly and family-like). You described how you changed your process for pushing your software out the door. And you state that the new process allows more bugs to go out the door. That sounds to me like a real, measurable, problem, that exists somewhere besides the people performing the process. So how is calling out individuals going to fix whatever actual, underlying problem was introduced by the new process?

You guys use Jira? I think the person to blame is you. The friendly "public shaming" might also be counterproductive as it will discourage developers from doing anything to rock your very carefully managed boat. As far as production bug preventing, that's what a dedicated QA team is for. You said it yourself, "We anticipated the increase in production bugs when we moved away from having a dedicated QA team."

Putting the QA job on the developers is fair enough, I guess, however it would seem like you neglect using proper staging environments to ensure that broken code never sees production.

At my place, we have a staging environment for every team, then we have a company staging environment then stuff goes to production. The product manager and team devs test at the team level staging, then it moves to the company staging server where QA (or another developer) tests and then it goes to production.

We do Continuous Integration as well but we sure as hell don't have a "Person to Blame" -- we are a fucking team. The person to blame is the boss that lets shitty code make it onto production.

So I guess it would be easy to fill out the "Person to Blame" box.. just type your own name in every time.

You're all about transparency and openness and accountability and public shaming, but you don't have the courage to post under your real name. Nice.

You sound like you are siloing your developers by having individuals in charge of stories and also being the gatekeeper to production. You should be baking TEAM review and TEAM approval into your development process especially if you want to start doing continuous deployment, and it sounds like you have jumped off a cliff without a parachute if you have eliminated dedicated QA...

If your team decides they want to involve some public shame in their processes that's one thing but it's extremely dangerous for any manager to introduce themselves and it should never relate to production.

The team owns the code.

Innovating practices are always about iteration and learning. The tragic point here is that the learning is being done in a public forum.

Team accountability is a best practice because trickle down hierarchies tend to do just that...trickle down. Depending on the size of the teams, share victory, share defeat should always be your mantra.

I don't know the size of your organization, but if you need to track these issues with automated metrics, you may have a larger communications problem in your workflow.

People are always better managers than spreadsheets. Use your metrics to support your initiatives, but use your people to come up with them.

Ahem.

I am somewhat disappointed that you have not presented one solid argument in favor of this new 'person to blame' field. The whole idea seems to hinge on the following quote: "so why not throw in a small dose of public shaming for good measure?"

And the answer is simple. It doesn't do any good, and can only hurt the performance of you and your team. Let me put this as simple as possible: shaming DECREASES performance. The fact that you apparently think this is 'fun' does not change this.

I will now return you to your regularly scheduled debate.

What's there to debate? You think shaming people is fun and helpful, you dismiss caring about your employees feelings as "political correctness".

If that works for your team, you're either very skilled at picking the right people for your management style, or you're lucky, or you can't read people and only think everyone's enjoying it as much as you are. I can't tell from outside.

"Respecting each other enough to be blunt and honest"? What about respecting each other enough to be kind to inherently imperfect humans? Who knows how to read your statements without seeing your interactions first hand.

You 1) failed to proof read the title of this post, 2) kill morale w/ this JIRA field, and 3) are an asshole.

http://en.wikipedia.org/wiki/The_No_Asshole_Rule

Hey come on, there's no need to nitpick. We all know he meant to write "Peon"!

So what do you think about the highest rated answer on http://programmers.stackexchange.com/questions/154733/my-bos... - namely that there should be a "Root Cause" field instead?

You are the management. It's always your fault. If you didn't actually write the bug. You could have trained the person who wrote the bug. You could have reviewed her code. You could have not let them check it in. You could have not let them work on the feature. You could have not hired them.

You could have fired them.

All this helps you do in a twisted way is figure out who you should fire. Chances are people will leave long before that.

Even though I'm not the boss of my team. Our policy is that it's always my fault. I find it liberating. Gives me an opportunity to learn from all our mistakes. And there is no finger pointing. Unless its at the management. As its always the managements fault.

Hey. There's a problem you want to solve, and you tried a way of solving it. Now everyone's waving their arms about and yelling at you. Right now, you're going to feel like you should stand by your decision.

That is a mistake.

That is a mistake, even if your solution is the best solution to the problem.

It's a mistake because if you dig in, fight hard, and refuse to surrender - if you entrench - then the solution becomes entrenched. And if all this backlash can't uproot it, well, what possible chance could a better solution have of replacing it?

If you need metrics on who to "blame", your hiring and management practices are faulty. These numbers will do nothing to increase "responsibility and accountability", but are more likely to add friction, perhaps where there was none previously.

You may end up losing the strong members of your team who have no desire to be subject to such shenanigans.

So your competent and accountable employees spend more time working for you than with their own families and you think shaming them is a smart thing to do for good measure?

Please do report back on what kind of novel management techniques you're using to refill these positions in few months.

As management, we should always be aware of the employee that needs that extra coaching (don't call me soft cause I'll fire them if 2 months of coaching doesn't work. It is a startup after all). However, this public shaming seems like one's inability to figure out who needs more guidance and/or one's lack of comfort-ability in having the difficult conversations that ensue once you've identified the individual who needs extra coaching. In either case, something tells me you're somewhat a wrong fit for this management role and I hope your managers have the ability to identify those that need extra coaching before you kill the spirit of your team/company.

Oh, I think this hasn't gone quite far enough. "Person to Blame" is verbose; I suggest "Blamee". To allow 3rd-party bug reports (gossip), please add "Blamer(s)"; separate multiple entries by commas. Also add a checkbox for anonymous bug reporting. Oh, and add a "Like" button and counter.

There - the descent into bugtabloid is complete.

"You're welcome." -- John Hodgman

Is it just me or is there anyone else too who has seen the spelling mistake in the title? "Peson"???

person_to_blame, you're preaching the wrong people. There are different ways to go about this. Have you looked into Root Cause Analysis[1]? The 5 Whys[2]?

I truly can't believe someone in a leadership position is putting this type of example out to their team. If I worked for you, I would have been out the door as soon as you decided to keep this bullshit field.

[1] http://en.wikipedia.org/wiki/Root_cause_analysis [2] http://en.wikipedia.org/wiki/5_Whys

If you were so proud of your idea, you would have used your real account.

...if you write a time bomb into our unit test suite

What does this mean, a slow test?

Guessing here: it might be a unit test which only works during the current year. I came back to work from holidays in January 2011 to exactly that. Someone had coded a test for "August 15th" being a certain day of the week. It worked great until the year changed.

That particular test hung out unnoticed for at least 4 months. Its failure was inevitable.

Well that's just weird.