2 ms·
> Employees always figure out how to abuse productivity metrics. Targets aren't the same things as measures. Measures of productivity are easy, but targets are
by Aunche 6y ago
> Employees always figure out how to abuse productivity metrics.
Targets aren't the same things as measures. Measures of productivity are easy, but targets are not.
For example, for a sufficiently large group of people (e.g. all young developers at JP Morgan), you can measure their productivity with how many lines of code they write on average. As long as you aren't using lines of code for performance evaluation, there is no reason any developer will perform needless large refactors or find other means for increasing their delta.
Edit: changed metric to target
- Thorentis 6y agoYes, but that proves OP's point. If the productivity metric was equal to the measure of lines of code, then they would figure out that they can abuse the metric by artificially adjusting the output of the measurement.
- Aunche 6y agoOops. I meant target rather than metric.
- andreilys 6y agoLines of code on average is a terrible measure of productivity. I’ve solved problems with 6 lines of code that took me a week to think of. Other days I write 600 lines of code. I would argue that the former 6 lines I wrote is much more productive than the 600 lines.
- Aunche 6y agoFor an individual, lines of code is a bad measure. Some problems are harder than other and some people do more design or leadership work. However, for the collective this all should average out.
- tsimionescu 6y agoNo, the problem is that, in general, the more lines of code you have, the worse your program is. Perhaps people working at home feel less pressure to just code, and are thinking more about the problem and writing less code to solve the same problems - a massive win in productivity, which would appear as a loss by your measure. On the other hand, perhaps people are indeed writing the same old code that they always were, just writing less of it. So lines of code are not a good metric. Average number of features/user stories/tasks delivered may be a decent metric (at the group level, not for individual developers), as long as it doesn't become a target. Delivery VS estimate could also be OK, in the same way.
- imtringued 6y agoThe top comment started off with the argument that you can't know the relative importance of the work. 6 lines of code can do a lot. 600 lines of code can do little. To measure productivity you have to measure how difficult the job is compare how valuable the job is. Most of the time both value and difficulty are unknown.
- Aunche 6y agoAcross JP Morgan as a whole, the "relative importance of the work" isn't going to change significantly over time. It definitely has nothing to do with WFH. It's far more likely that a drop in LOC is caused by an increased difficulty of mentorship, slower time to resolve blockers, etc.