The project manager sends out the stats about the work hours, bug fix rates every month, is it typical?

Question

We are developing a product that requires 3 teams to work together: my team works on web-development, team B works on embedded system and team C bridges us together (to put in a simple way). There is a product owner who is responsible for the overall product (business, technical) and a project manager who manages the project progress. We do monthly releases.

So I will say it is a typical cross functional product development teams. One thing that bothers me from the project management point of view is that the project manager will send out the stats about everyone's "productivity" at the end of each release, e.g. the work hours (according to his spreadsheet), the bug fix rates (how many bugs you fixed), how many bugs you introduced when implementing a new feature, etc.

For me, as the manager of team A I don't see the usefulness of that. I understand he is doing his job and in this case maybe he wants to keep the stakeholders, each one of us, informed the project progress. Maybe he wants to reminds everyone what we did well or poorly in this release. I know scrum has a burn down chart and in theory we should try to make our burn down chat look like a straight line. But from my own experience that rarely happens. But scrum is another topic I don't want to get involved in this question.

So is sending out stats like this typical? What are the pros and cons of it?

---- update ---

As I already said "I don't see the usefulness of that". But since he will keep doing that I need to see is there any "silver lining" of it. That is one of main reasons I asked this question. We did have some monthly releases that had mores bugs than other months. So would the stats reminds everyone we need to do better next time (although I highly doubt it)?

Answer 1

In some countries this could even be illegal without the approval of labor unions, so where you are matters a lot.

But leaving the legal aspect aside: this may lead to unwanted consequences:

• people working too much and burning out
• people afraid of committing mistakes to the degree that stops them from trying to do anything but the bare minimum
• ruining the atmosphere in the team.

Answer 2

Yes, bad management is typical.

The core philosophy apparent here is something called "theory X" management. Ie, the developers are lazy and will do no work if at all possible, so they must be monitored in a very precise and public way.

I'm not saying an authoritarian, low trust approach never works in any industry. But at least in software, one can't bully and shame ones way to good outcomes. It's a sufficiently complex field that one needs people to care at least a bit. So if the theory-x-ers are right and the developers are all lazy, it's already screwed. And if developers are in fact self-motivated people keen to help the business achieve its goals, treating them in an openly disrespectful manner is not a great way to keep them that way.

Theory X stuff aside, what if this manager is successful in coercing the developers into doing exactly what they're asked to do? That would still be a bad outcome. Metrics are just narrow measurements of the world and all of them have perverse outcomes. They can be gamed. Usually people have the good-will not to, in return for being judged on their work in way that takes more than just measurements into account. In this case, the price for poor numbers is a public shaming, so I don't think there's any reason for any good-will here.

You may have notice the thing that compels the gaming of stats also makes this the opposite of a psychologically safe or healthy place to work.

But in fact, in this case the metrics aren't just flawed. They're trash. Clearly the manager was too busy thinking of detailed ways to surveil developers that they forgot to give them any relation at all to actual business value. So it doesn't take a huge amount of thought to see where the two may differ. For instance, why would you fix an important bug when you could fix 10 pointless ones? Why would you fix an important one quickly when it might cause minor defects? Why would you mentor a teammate? Why would you even help a teammate if it damaged your personal productivity? Why would you do anything that made development better or faster in future if it slows you down now? Why would you do anything creative or risky if slows you down or risks defects? Other answers already add plenty more to this list.

Answer 3

These kind of stats are usually a warning sign of a software package stagnating and dying. The other 2 answers have covered a lot but I will add a few things:

Productive developers make mistakes, bad developers have never made any:

• "Move fast and break things" has a higher upper bound for productivity and research. You'll advance in your field faster, and be first to market in others. If you're afraid to break things, your products will stagnate.
• Experimental new features will not be "owned" by someone due to fear of being associated with the bugs that come from the exciting new field.
• Your devs learn by making mistakes faster than any other way. A dev who is so careful he doesn't make mistakes doesn't learn anywhere near as a fast as one who tries, fails, and gets up again.
• In my own experience, if your end goal is highly functional, very high (but not perfect) reliable software, you'll get there a lot slower writing perfect code carefully first time than you will writing mediocre code faster and getting it tested. (By "perfect" reliable I mean military or aerospace applications - can't use heap memory because allocator might fail kind of reliable)
• Developers who engage in code-base-wide refactors will be the last person to touch every peice of code that has a bug in it. These behaviours will be punished, discouraging overdue refactoring work.

Answer 4

Once you publish these numbers, even if management doesn't actively reward/punish developers based on these number, developers are going to compare themselves to others. They're going to try to establish themselves as someone who produces a low number of defects. While that's probably exactly what the PM is hoping for, it has a number of undesirable side effects, some of which were already raised in the other answers.

• Developers may argue why a bug was not caused by them but someone else who touched another piece of code or who gave them incomplete information. They may even be correct. This kind of "blame game" can quickly poison the atmosphere, not only within a given team, but also among different teams. Where cross-team collaboration might actually reduce the number of bugs, this initiative may have the opposite effect of siloing them even further.
• It can also be a waste of time discussing whether a reported ticket should be classed as a bug or a change request when all the client wants is for the app to work as they requested.
• "Not my code" syndrome. Rather than established a shared code ownership, this might lead to developers being unwilling to touch another developer's code (e.g. helping out when a colleague is sick), both because they could end up being blamed for pre-existing bugs and because they're more likely to introduce bugs than their absent colleague.
• Hiding defects. A lot of the time, a developer will be the first person who notices when something is wrong with their code. The usual process is to report it as a bug, fix it, and have QA verify the fix. If creating bug reports is penalized, a dev may prefer to stay quiet until they get around to fix it secretly. That may delay the bug fix. Worse, that means nobody's going to check for unintended side effects of the bug fix in question.
• Devs as overpriced testers. Developers are incentivised to doublecheck every commit. This may not be entirely bad, but for low-priority issues may be more costly than simply having QA report the bugs.

Answer 5

There's a saying that I learned many years ago:

If you work a lot, you make a lot of mistakes.
If you work less, you make fewer mistakes.
If you don't work at all, you make no mistakes. 
If you make no mistakes, you get promoted. 

Also known as the law of unintended consequences. As a software developer, when I develop a feature, there is a point where it's not considered finished, therefore very buggy. Then comes a point where everything is finished, but there are still plenty of bugs. Then I reduce the number of bugs, then I reduce them even further to zero.

While reducing the number of bugs, I basically do the work of QA - except handing them code that is full of bugs is inefficient. It becomes efficient when the number of bugs is so low that handing over to QA is better than searching for bugs myself. If I find and fix all the bugs before handing over, that's actually inefficient, because they are better at finding bugs. Now if I'm judged on number of bugs that I produce, the equation changes for me. Doing inefficient work gives a better outcome for me. So guess what I will do.

There are plenty of stories around where QA and developers were judged on "number of bugs found" and "number of bugs fixed". Obvious that a developer would add a bug intentional, tell QA where it is, and when QA find and reports the bug, fix it in two minutes. Win/win for two employees at the expense of the company.