4 ms·
In one of my previous teams, we did away with individual metrics because they "punished" team players. If an engineer spent most of a week helping another with
by shados 9y ago
In one of my previous teams, we did away with individual metrics because they "punished" team players. If an engineer spent most of a week helping another with their issue, it made them look bad in whatever tracker we used by almost every metric. I prefered sticking to trying to optimize whole team velocity and using 1 on 1s and peer reviews to track individual performance where it was needed (eg: compensation review and promotions).
It's still not perfect: people could be spending them helping someone from another team and that would go under the radar (except the peer reviews), but it still worked a lot better.
- Isamu 9y agoYeah we don't do metrics, we gather short appraisals from a list of people that you provide, that you worked with throughout the year. You are encouraged to provide names of people that are outside of your group. So if you helped some other team, this is the way you cash in on that. Helping other teams succeed is a cultural thing and your organization has to encourage it with its practices and procedures.
- babesh 9y agoThat is gamed too. You just don't include the names of people you have wronged: the bugs you have left for others to fix, the undocumented code, the projects you were supposed to complete but got reassigned so that you could work on something with higher promotion possibilities, the delays you cause in other people's work, etc...
- longerthoughts 9y agoThis is exactly what I've seen happen in my experience and have often wondered about alternatives. Bridgewater, for example, uses a system that allows for feedback from anybody at any time [0], but I suspect that presents new issues like negative reviews from rival employees. Additionally, a lack of context could result in negative feedback for decisions that actually help the business (e.g. passing on requests to help colleagues with relatively low-value items in favor of focusing on higher priorities). [0] http://www.businessinsider.com/bridgewater-employees-rate-performance-dots-2017-2 http://www.businessinsider.com/bridgewater-employees-rate-pe...
- shados 9y agoThe issue then is the other side of the story: you end up with popularity contests. Someone with a silver tongue will always win in peer review-based processes. No solution's perfect.
- mgkimsal 9y agorelatedly, 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".
- city41 9y agoReminds me of this classic Dilbert: http://dilbert.com/strip/1995-11-13 http://dilbert.com/strip/1995-11-13
- gjvc 9y agoIn 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.
- diet_mtn_dew 9y agoIt's called Goodhart's law: https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- austinjp 9y agoIt'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".