3 ms·
For most office roles, employers have almost no data on productivity. The limited data they do have is very noisy. Consider a developer: what data does an em
by LatteLazy 4y ago
For most office roles, employers have almost no data on productivity. The limited data they do have is very noisy.
Consider a developer: what data does an employer have? Number of lines of code committed? Number Commits? Maybe if they are very diligent in collecting data the bugs found son after those commits? You know nothing about quality of code, nothing about speed, nothing about complexity, nothing about bugs avoided, nothing about value added, nothing about mentoring others or managing tasks.
You can do the same analysis for almost any role, from Sales to SecOps.
And that's without getting into Goodhart's law...
https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law
- rm_-rf_slash 4y agoThis “data” aspect may be overthinking things. Developers get assigned tasks. A guesstimate is made by the dev over the time/effort required, which is approved as plausible by a senior dev/manager. Then the task is done or not done on time. If done, good, next task. If not, the explanation ought to be reasonable. That’s all you really need to know.
- LatteLazy 4y agoThat's great unless they were pulled off that task to work on something else. Plus now we know estimates will be used to punish all estimates just doubled. And what does Done mean? I can do a pretty terrible job but still commit "something"... People have this idea that modern jobs are like factory work: you can measure how many widgets I made and mine are the same as every other operator. But it wasn't even like that in factories, let alone now no two jobs are the same and output cannot be measured in any meaningful way...