3 ms·

Saying that you can’t measure productivity is a pseudo-truism and a cop out of doing your job. How do you measure productivity = how do you decide whom to prom

Saying that you can’t measure productivity is a pseudo-truism and a cop out of doing your job. How do you measure productivity = how do you decide whom to promote; how do you decide whom to fire; how do you decide how to distribute bonuses; etc. If you can’t measure productivity, you can’t do your job as an engineering manager. It’s not a question that should have been asked 3 months into a job. It’s a question that should have been asked during the hiring interview.

skeeter2020 2y ago
I think I agree with you - definitely about the cop-out part. It's kind of the wrong question; it's not "how do you measure productivity?" but you have some hypothesis, "what do you optimize?" If you're right, it might help you win (maybe you win or lose regardless) and you get credit. If you keep experimenting, you might get better or worse, adjust and repeat. I'm sick of these (implicitly) absolute measurement questions. I pretty much refuse to look at anything other than the delta.
n4r9 2y ago
So... how do you measure productivity? The engineering managers you refer to probably attempt to measure productivity, but may well fail to correctly identify high and low performers.
- LudwigNagasena 2y ago
  There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should be used with caution. There are qualitative measures like code maintainability, satisfaction of stakeholders, communication skills, system design skills, etc. Those have to be assessed using peer feedback, stakeholder feedback, 1-on-1's, activity during calls and meetings and so on. Those are harder to measure, but also harder to game.
  - n4r9 2y ago
    In my experience, not only are quantitative metrics gameable, but they depend greatly on accurate estimates (which just shuts the problem along) and tend to bias towards rushed implementations. You also have to be very careful to consider what duties the person has beyond pure coding, which can become time-consuming as they grow in seniority, such as mentoring juniors, engaging with product teams, or supporting product enquiries. The qualitative measures you mention describe "quality" rather than "productivity" (rate of good output). Both are aspects of performance, but are definitely distinct. I suspect that the best you can do for productivity is kind of a halfway house, where - as part of their feedback - a more senior developer indicates whether the rate of implementation met/exceeded/fell below expectations.
9rx 2y ago
> If you can’t measure productivity, you can’t do your job as an engineering manager. Why not? You could feel productivity instead, which is also arguably the better approach as it more emotionally appealing to those paying the bills than measurement is. That is how people do it in the real world. Nobody is measuring productivity in this business, even if they want to pretend to themselves that they are.

skeeter2020 2y ago

I think I agree with you - definitely about the cop-out part. It's kind of the wrong question; it's not "how do you measure productivity?" but you have some hypothesis, "what do you optimize?" If you're right, it might help you win (maybe you win or lose regardless) and you get credit. If you keep experimenting, you might get better or worse, adjust and repeat. I'm sick of these (implicitly) absolute measurement questions. I pretty much refuse to look at anything other than the delta.

n4r9 2y ago

So... how do you measure productivity? The engineering managers you refer to probably attempt to measure productivity, but may well fail to correctly identify high and low performers.

LudwigNagasena 2y ago
There are quantitative measures like story points velocity, time to merge, code churn, etc. Those can be simply measured but also simply gamed, so they should be used with caution. There are qualitative measures like code maintainability, satisfaction of stakeholders, communication skills, system design skills, etc. Those have to be assessed using peer feedback, stakeholder feedback, 1-on-1's, activity during calls and meetings and so on. Those are harder to measure, but also harder to game.
- n4r9 2y ago
  In my experience, not only are quantitative metrics gameable, but they depend greatly on accurate estimates (which just shuts the problem along) and tend to bias towards rushed implementations. You also have to be very careful to consider what duties the person has beyond pure coding, which can become time-consuming as they grow in seniority, such as mentoring juniors, engaging with product teams, or supporting product enquiries. The qualitative measures you mention describe "quality" rather than "productivity" (rate of good output). Both are aspects of performance, but are definitely distinct. I suspect that the best you can do for productivity is kind of a halfway house, where - as part of their feedback - a more senior developer indicates whether the rate of implementation met/exceeded/fell below expectations.

9rx 2y ago

> If you can’t measure productivity, you can’t do your job as an engineering manager. Why not? You could feel productivity instead, which is also arguably the better approach as it more emotionally appealing to those paying the bills than measurement is. That is how people do it in the real world. Nobody is measuring productivity in this business, even if they want to pretend to themselves that they are.