I have a simple question as a former-programmer, now business guy, between dev and QA.
Why not put pay performance targets on both sides as incentives per testing release?
In other words, each QA person gets $10 for each bug they find (up to 10, or whatever). Each development person gets $10 for the number of bugs not found under a certain target (10, or whatever).
Seems like an easy way to get people more motivated about the whole testing process.
Sounds almost common-sensical…but it’s a disastrous idea.
Be Careful What You Wish For
Incentives often work in perverse ways. Tell Tony Tester that you’ll pay him for every bug he logs, and he’ll clog your bug tracking system with niggling items, and go to pains to turn one bug into ten bug reports. Tell Connie Coder that you’ll pay her for not having bugs logged against her, and she’ll spend half her day arguing why these three issues are features, not bugs, and these four are really in Carry’s code, not hers, and…you get the idea.
Do I think that everyone is really this petty? No, but you are incentivizing pettiness here, and incentives can have a frightening power. Which leads to the next problem with this suggestion:
Replacing Intrinsic Motivation with Extrinsic Motivation Harms Your Team
This may not be true for everyone – I’ve met a few folks who swear that they work best when there is dollar goal they are shooting for. A good deal of research shows that:
- Intrinsic motivation is more valuable to an organization than extrinsic motivation, and that
- Extrinsic motivation tends to erode intrinsic motivation.
My experience as a worker, team member, and manager has been that the best folks work for some combination of:
- Personal pride in a job well done,
- Commitment to a vision,
- Commitment to the team (or to someone on the team),
- The enjoyment of the task itself, and
- A desire to learn and grow.
That’s not to say that salary is irrelevant…but I think it’s relevance is often misunderstood. If one believes in the project, likes the team, and understands that there’s just not much money in the company right now, many folks will happily give their all, knowing full well that they could make more money somewhere else. If you don’t believe me, look at how hard school teachers and non-profit workers tend to work.
On the other hand, if that same person finds out that the person next to them is making 20% more for roughly the same job, their intrinsic motivation may be completely destroyed. Why? It’s not the amount they are being paid per se, because that hasn’t changed. It is that the salary differential is a sign of disrespect for their work, for unfairness in the workplace, or for dishonesty in management.
I would also add that I suspect salary is a strong factor in employee retention, but I doubt that it plays much of a role in employee motivation…other than the negative impact of undercutting intrinsic motivation by making someone feel undervalued or taken advantage of.
Bug Databases Are Tools to Understand Projects, Not to Evaluate Workers
Lastly, I believe that bug tracking databases are at their best when they help to provide insight into the state of a software development project. I believe that if Bug DBs are used to evaluate employee performance, they will necessarily begin to be gamed…and before long the information that they should provide will be obscured and distorted by folks trying to protect their jobs, to save face with management, or to maximize that next bonus.
And one of the last incentives I want to create is for someone to manipulate the data I use to get a handle on how the project is doing.