As a Program Manager, it’s my job to assign work items to people and then track everything. When there’s a few bugs, it’s not that difficult. When there’s 30 or 40, it’s much tougher.
We have a couple of mechanisms for assigning work items, called bugs. We can assign them to Investigate, wherein the developer goes off, figures out what to do and then reports back. We can also Approve them, wherein the work is actually done. It then is subsequently assigned for testing and eventually rolled out.
This process worked okay, but not great. Bugs that are assigned to Investigate often stay that way for days, weeks, and even months (and that includes even myself). We may keep mental track of them but when somebody has to review all of the bugs (like myself, for example, in our weekly Bug Triage meetings), we don’t know what the status of them is. When a bug kind of sits there with no updates, I call these Orphans.
I decided that I had to fix the Orphans. So here’s what I came up with: if a bug is assigned to you and is marked Investigate, if you don’t have either an update or a date for when you will have an update, you pay a fine of $1. It is $1 per meeting, not $1 per bug (for now). The goal is keep bugs from getting Orphaned. If people start feeling the pain (with a huge $1 fine or simply the embarrassment of paying the fine) then there now exists social pressure to keep things on track. The motivation to keep things up to date is now felt very strongly. Who wants to be publically shamed?
It’s only been in force for a week, but it has worked well so far. I encourage other managers to consider borrowing the principle and tweaking it for their ends.
how do you enforce the payout :P
Peer pressure works pretty well. After a week of using it, it has succeeded very well in ensuring that bugs are up-to-date.
Only at Microsoft would this be allowed..
Hahahah :-D thats a very nice management tip. I like the idea that u make the devs pay a fine. But i think they should really feel it by paying considerably more like around $20.