#metrics #productivity #management #control

idea

Measuring productivity of a team can be accomplished by many ways: the business outcome, the output, etc. This measurement is valuable contextually: when comparing a number from the month before, given the conditions of the tests, etc. It is very hard, given that usually there is no control group, which makes the exercise significant mostly for setting direction, or interpreting data collaboratively (with, as opposed to them), but not to set a target.

Measuring the productivity of an individual is significantly harder. Most of the metrics are biases one way or another. Outcome is biased by the card the individual got distributed (e.g. accounts they work on). Output is biased by the metric itself (e.g. number of lines of code don't mean anything: coding style can double things, and then more lines might mean poorer code). At best this can be used to signal a potential issue that will need some qualitative study. And then you're at risk of Goodhart's law.

Most of the time, better not use productivity metrics and instead rely on gemba.

Measure results instead of time spent^[2]. This also means negative results: when something has extra complexity or is not possible, it still generates valuable information^[1] and should not be discarded as incompetence.

links

• Goodhart's law is one reason why measuring productivity quantitatively is hard.

references

• Martin Fowler / Cannot measure productivity, on how measuring productivity is not a significant exercise. (copy in ref)

• Wikipedia / Gemba - Gemba can be used to understand the qualitative effectiveness of a process.

• -2000 Lines Of Code^ref, the story of Bill Atkinson, author of Quick Draw on the Lisa, who declared he wrote 2000 lines of code when asked for that metric as accountability for his productivity, while in fact writing just a few that saved apple several thousands of SLOC

• Chen Ping The Original Sin of Software Metrics^ref an imaged story about gaming defect metrics

• [1]: Reinertsen / Product flow:

  Fifty percent failure rate is usually optimum for generating information.

  ~ The Principles of Product Development Flow: Second Generation Lean Product Development, Donald G Reinertsen

• [2]: Gitlab / all remote has such a principle in their manifesto:

  The results of work over the hours put in