Yes, any attempt at working "faster" is doomed to fail.
From a Scrum perspective, the purpose of instrumenting your process to collect throughput metrics is not to become faster. It is to have signals about when things go bad, so that you can take appropriate action. Think of it in terms of having a criteria to confirm that an impediment is really such (and not only perceived), and about when you should intervene.
If you systematically kill the causes of such impediments, then your throughput will increase. Rather than "working faster" (i.e. increasing velocity) you should focus on "delivering earlier". See the blog post Lean Business and the Value of Flow 2 I wrote for Kanbanzie recently (and it's Part 1 too) to understand what the difference is.
Yes, if you are looking at velocity like that, it becomes a push driver. You are concerned about the "worker" delivering more to the company (the system), because the worker is a "cost center" and you better utilize him/her efficiently. That is the resource efficiency mindset that comes into play, even though it is disguised under an agile approach like Scrum.
If instead you focus on "delivering earlier" you are concerned about the "system" (not the worker) increasing its throughput by improving the overall flow efficiency.
Hope this helps!