There's a fourth explanation: Engineers don't get paid more for producing features faster (or on time), they just get more work. A smart/rational engineer eventually realizes they don't get rewarded for finishing tasks quickly or on-time, they get the opposite: more work. And promotion happens laterally not vertically, they get it by changing jobs because it's not obtainable by delivering more things on time or faster.
As long as engineers are paid based on salary/wages this will always be the case, and has been the case in every company I've worked with.
>As long as engineers are paid based on salary/wages this will always be the case, and has been the case in every company I've worked with.
I don't think this is 100% true, and the problem you are describing doesn't necessarily follow the cause you put forth.
Problem: Engineers do not work through tasks quickly because they aren't rewarded for completing tasks.
Solution (hypothetical): Reward engineers for completing certain tasks.
Problem: How do you value how much a task or feature is worth?
Solution (hypothetical): A task's value is correlated with the impact on the business's bottom line.
Anyone who's worked at a large SV tech firm can see the problem coming - engineers will only want to work on valuable, front facing tasks, and maintenance and technical debt tasks never get cleaned up. For example, Google[1], ties their promotion system to the value of the tasks you have done at Google - which obviously leads to a lot of gaming the system to increase your worth. So while I agree there might be a motivation problem, I don't think it's clear cut that the compensation model is the solution.
Another related explanation is just simply that there are higher priority items, rather than just the priorities not aligning to working on any of Tasks A-Z efficiently.
Then the question is why are they saying things like "top of my list" when it's not? If they are saying that anyway. Maybe because they think they'll get punished for talking back to you about the priority list? Or just hope you'll go away.
Meanwhile if someone is aware of one of these canaries, it's asshole behavior to hide its existence from the person who is carrying out the related task, up to some limit of obviousness. There's something to this concept beyond just any tracking mechanism like "did they open that file in Perforce for edit?" (Ignoring they can work offline, or otherwise defeat the canary monitoring while still "collecting" it.) When it's something you know is needed to make progress, put it and all the other intermediate steps in the Tasks List for a work item if you know them; breaking things up into concrete realizable chunks is how we make progress and prevent floundering.
It sounds like you are suggesting objective based bonuses. I suspect that most engineers would completely balk at the notion of losing a bonus if they don't meet a deadline. Most engineers today feel entitled to all the bonuses for less work, not bonuses for meeting or beating deadlines.
As long as engineers are paid based on salary/wages this will always be the case, and has been the case in every company I've worked with.