Comment by mgkimsal | Hacker News Reader

Comment by mgkimsal | Hacker News Reader

Parent Full thread

relatedly, a friend of mine worked at a place where everyone was on "20% time = bug time". You were expected to spend ~ 20% of your time taking bugs from the bug tracker and fixing them. Bugs closed were part of a metric towards bonuses.

People were taking one bug, breaking it in to 3 or 4, then closing all of those.

"Add button for X" became

* "add button on form" * "add CSS for button" * "update CSS for button" * "add CSS files to build process"

Friend of mine took a bug - it was a moderately big one, touched multiple systems, but was a bear to work on. No one else touched it. He spent a few weeks making it work. Eventually closed it. Was reprimanded because his bug-closing stats were bringing down the department's numbers. He was counseled that he should have broken it down in to a few dozen issues, so that he could have closed more and "kept up" with his team mates.

No one else would touch that bug. Most people hadn't been there long enough to decipher how complex it was. But.... they got bigger bonuses because ... bug closing numbers.

We all probably have similar stories to share, and I know the "what gets measured gets gamed" mantra.

It's still frustrating to know that this mentality infects so many professional "thought workers".

> It's still frustrating to know that this mentality infects so many professional "thought workers".

The article explains the process by which good, honest workers become corrupted into this mentality. Whether you want to do good work or not, most people don't have the confidence, security, nest egg, etc. to quit their day job, so they assimilate out of the necessity to keep their bills paid, and this becomes a cycle. The naive worker comes in determined to do a great job, soon learns that "great job" is not a straightforward evaluation and that people who have no real involvement, knowledge, or investment have control over their career trajectory, and then optimize to improve those numbers.

These people then get promoted and a) consider failure to game the system evidence of naivety, and expect this same political awakening in candidates as a "rite of passage"; and/or b) rise through the ranks without realizing that they've gradually internalized the system, and that they're inadvertently making the same loose determinations based on impersonal, macro-level metrics that are easily gamed, partially because as you get promoted, you can't possibly come to a deep intuitive or direct understanding of the work of everyone in the ranks. Rinse and repeat. The ABCs of employment are "Always Be Campaigning".

Strong, personal leadership from invested, intelligent people with conviction is the only antidote, and even when you get these people, it's a constant battle to keep their disinclination for political games from destroying things.

Ah yes, bug counting. There is an even worse variant: when the manager only looks at the number of open bugs/issues, rather than what has been closed, or code that was checked in, etc. I had the misfortunate to work under such circumstances.

I was supposed to complete an existing project. Only problem was, new bugs kept getting added by the tester, and were then assigned to me by the project manager, so the number of issues kept growing. I would fix them (or existing ones) during the week, but at the next conference call it would still look like I was not making progress, because the total number of open issues did not shrink much.

This led to weekly inquiries of "when will it be done", and pointing out that it was essentially a moving target, due to circumstances beyond my control, did not help much. Eventually I did catch up, but the damage was done. Apparently this manager now thought of me as somebody who wasn't very productive. They moved me to another, completely unfamiliar project, where I got essentially no help from others, then decided that I was not productive enough and let me go.

In retrospect, being asked continuously when the project would be done, was an indication that I was the only one being blamed for its delay. I was afraid to rock the boat though, and quietly assumed that surely this manager was taking all the factors into account (especially since I did point them out a few times). As it turned out, they were not, and I will not make this mistake again, should a similar situation come up in a future job.

> I was afraid to rock the boat though

This is really at the heart of why most people don't speak up (or speak up more loudly) - fear. Fear of losing the job, income, etc. There are no easy answers to this, short of having - if not FU money - a comfortable cushion to see you through a year or two between income streams.

In my naivety I've never heard nor thought about "what gets measured gets gamed". It's been my intuition for a while, but it explains much of what used to frustrate me -- I wish someone had told me this 15 years ago.

It's called Goodhart's law: https://en.wikipedia.org/wiki/Goodhart%27s_law

It's worth explicitly considering the two concomitant problems:

What does not get measured gets ignored. It's not necessarily a bad thing to measure stuff. But it's easy to overlook a metric that later turns out to be important.

If you're measuring the wrong stuff, or measuring it in the wrong way, your metrics are again erroneous and your decisions will be based on ghosts.

Lao Tzu was truly onto something when he said "the more I learn the less I understand".

Never thought about it that way but it is probably the reason I like to understajpnd the rules before breaking them.

Reminds me of this classic Dilbert: http://dilbert.com/strip/1995-11-13

This was one time where I appreciated living in the bay area. I found out 3 months into a new job that such metrics mattered. I was out before 6, and could've been before 4. Now I know to ask questions to prospective employers and look for signs of such crap.

It sounds like you need a 'reasonable person' clause - when considering bonuses, each metric gets looked at by a randomly selected group of peers and they can jointly decide if someone's gaming the system.

To take a narrower view, it sounds like that place needed to assign weights to the different bugs, so that the big scary bug was worth 20x (or whatever) of the trivial 'tweak the CSS' bugs.

The simple solution is that grooming is done as a team, so everyone agrees on "size" before tickets get assigned or picked up.

Reply on news.ycombinator.com