But isn't competition ultimately the only yardstick by which we can measure this?
Either we can A) evaluate/measure engineers' output (e.g. commits/tickets), and promote/hire/fire based on whether they do enough of it per/day ("meritocratic"?)
B) Just plop engineers in chairs, and peer over their shoulder to make sure they aren't on reddit all day, and then trust that however long it took them to build the thing was reasonable.
A is really hard, it was the false-promise of agile. But in a remote culture, you either have to do A or install screen-monitoring software on your engineers to do B (or just hope/pray).
Of course perhaps there's another option, like a technical manager who reviews the volume/quantity of PRs and assesses based on that, but seems rare.
It's pretty easy for me to listen to my team's daily updates at our standups and figure out how they're doing without A or B. If something's taker longer than our estimate and they explain why, it's not hard to tell if they're making this up (FWIW, no one who works on this team has ever done that).
And yeah, sometimes their productivity dips because they're tired, distracted by non-work stuff, or they just find this particular piece of work uninspiring. That's ok, no one operates at top productivity all the time.
But all of this just highlights the fact that if you want a manager of a development team to be able to evaluate team members' performance, that person needs to understand the job that those team members are doing.
Its important to take time out of the question, because time spent, after a very small minimum, isn't a strong indicator of performance.
It's sort of strange that we even take this point of view: that somehow human output is to be measured in the way a machine's output is measured or the efficiency of a light bulb.
But that opens up a whole can of worms....