You can - but not on the level of a single developer and you cannot use those measures to manage productivity of a specific dev.
For teams you can measure meaningful outcomes and improve team metrics.
You shouldn’t really compare teams but it also is possible if you know what teams are doing.
If you are some disconnected manager that thinks he can make decisions or improvements reducing things to single numbers - yeah that’s not possible.
> For teams you can measure meaningful outcomes and improve team metrics.
How? Which metrics?
That is what we pay managers -to figure out- for. They should find out which and how by knowing the team, familiarity with domain knowledge, understanding company dynamics, understanding customer, understanding market dynamics.
That's basically a non-answer. Measuring "productivity" is a well known hard problem, and managers haven't really figured it out...
Economists are generally fine with defining productivity as the ratio of aggregate outputs to aggregate inputs.
Measuring it is not the hard part.
The hard part is doing anything about it. If you can't attribute specific outputs to specific inputs, you don't know how to change inputs to maximize outputs. That's what managers need to do, but of course they're often just guessing.
Measuring human productivity is hard since we can't quantify output beyond silly metrics like lines of code written or amount of time speaking during meetings. Maybe if we were hunter/gatherers we could measure it by amount of animals killed.
That's why upthread we have https://news.ycombinator.com/item?id=41992562
"You can [accurately and meaningfully measure software engineering productivity] - but not on the level of a single developer and you cannot use those measures to manage productivity of a specific dev."
At the level of a company like Google, it's easy: both inputs and outputs are measured in terms of money.
As you point back to my comment.
I am not Amazon person - but from my experience 2 pizza teams was what worked and I never implemented it myself just what I observed in wild.
Measuring Google in terms of money is also flawed, there is loads of BS hidden there and lots of people paying big companies more just because they are big companies.
Well I pretty much see which team members are slacking and which are working hard.
But I do code myself, I write requirements so I do know which ones are trivial and which ones are not. I also see when there are complex migrations.
If you work in a group of people you will also get feedback - doesn't have to be snitching but still you get the feel who is a slacker in the group.
It is hard to quantify the output if you want to be removed from the group "give me a number" manager. If you actually do the work of a manager so you get the feel of the group like who is "Hermione Granger" nagging that others are slacking and disregard their opinion, you see who is the "silent doer" or you see who is "we should do it properly" bullshitter you can make a lot of meaningful adjustments.
> Maybe if we were hunter/gatherers we could measure it by amount of animals killed.
So that's how animal husbandry came about!
> Maybe if we were hunter/gatherers we could measure it by amount of animals killed.
Even that would be hard since hunting is complex. If you are the one chasing the pray into the arms of someone else, you surely want it to be considered a team effort.
You need like 'blueberries picked'.
It's not a non-answer. Good managers need to figure out what metrics make sense for the team they are managing, and that will change depending on the company and team. It might be new features, bug fixes, new product launch milestones, customer satisfaction, ad revenue, or any of a hundred other things.
I heard lines of code is a hot one.
I would want a specific example in that case rather than "the good managers figure it out" because in my experience, the bad managers pretend to figure it out while the good managers admit that they can't figure it out. Worse still, if you tell your reports what those metrics are, they will optimize them to death, potentially tanking the product (I can increase my bug fix count if there are more bugs to fix...).
So for a specific example I would have to outline 1-2 years of history of a team and product as a starter.
Then I would have to go on outlining 6-12 months of trying stuff out.
Because if I just give "an example" I will get dozens of "smart ass" replies how this specific one did not work for them and I am stupid. Thanks but don't have time for that or for writing an essay that no one will read anyway and call me stupid or demand even more explanation. :)
I get it, you are a true believer. I just disagree with your belief, and the fact that you can't bring credible examples to the table just reinforces that disagreement in my mind.
The thing is even bad managers can thrive in a company with a large userbase like Google. There is a lot of momentum built into product and engineering.
So basically you have nothing useful to say?
I have to say that there is no solution that will work for "every team on every product".
This seems to be useful to understand and internalize that there are no simple answers like "use story points!".
There is also loads of people who don't understand that, so I stand by that is useful and important to repeat on every possible occasion.
That sounds like a micro manager. I would imagine good engineers can figure out something for themselves.
haha that is not what managers do. Managers follow their KPIs exactly. If their KPIs say they get payed a bonus if profit goes up, then manager does smart number stuff and sees "if we fire 15% of employees this year, my pay goes up 63%" and then that happens
My company uses the Dora metrics to measure the productivity of teams and those metrics are incredibly good.
These are awesome, but feel more applicable to DevOps than anything else. Development can certainly affect these metrics, but assuming your code doesn't introduce a huge bug that crashes the server, this is mostly for people deploying apps.
I think it's harder to measure things like developer productivity. The closest thing we have is making an estimate and seeing how far off you are, but that doesn't account for hedging estimates or requirements suddenly changing. Changing requirements doesn't matter for DORA as it's just another sample to test for deployment.
There's only one metric that matters at the end of the day, and that's $. Revenue.
Unfortunately there's a lot of lag
> Unfortunately there's a lot of lag
A great generalisation and understatement! Often looking like you are becoming more efficient is more important than actually being more efficient, e.g you need to impress investors. So you cut back on maintenance and other cost centres and the new management can blame you in 6 years time for it when you are far enough away from it to not hurt you.
s/Revenue/profit/g