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. :)

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.

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.

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'.

"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.

So that's how animal husbandry came about!