Focus not on the time, or the perceived effort, but on the output. After all, it's ultimately the output that matters to the business, not the process of getting to that output. Make the charitable assumption that they are willing to do work for the money you're paying them (but don't forget to follow up if they aren't).
More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that.
The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating.
The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part).
This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).
This all sounds like very good advice and like you know what you're doing. So I take it all to heart. But when you say to not focus on time, I have to assume we mean time for a given person to complete a given task? Because time-to-project-completion can not be ignored completely.
I'm very sympathetic to this, because I've been on both sides. I've been a developer under pressure to estimate things that I don't yet understand, and I've been a lead dev responsible for overall project management who needs some sense of how long a task is likely to take, even if is just an educated guess. What you've said is true - time-to-project-completion simply can't be ignored.
So far, my strategy goes like this: rather than pressuring a developer to give me a more optimistic timeline, I instead do the opposite, I encourage them to really consider things that may go wrong. I'll sit down and try to talk about the potential overlooked risk. I try to understand the assumptions they're making, to help them become aware of the assumptions they're making. Are they assuming the data feeds they're counting on are available and easy to integrate? Are they assuming a certain amount of support from other departments will be available when they need it? Are they assuming they'll be able to understand and work with an existing code base before they fully immersed themselves in it?
This doesn't just improve your odds of getting a more accurate estimate of time-to-project-completion, I find it reassures the developers that you really do understand the difficulty of understanding and estimating a complex task.
> Focus not on the time, or the perceived effort, but on the output
THIS.
But I understand companies. When they won a cash cow, they want to milk it.
A good dev can either slow down, till he's as fast as the others and keep chilling the rest of the time, or, get more money for getting more things done than other devs.
More specifically, give them a list of things to work on. Have them give estimates, silently apply the "Scotty" factor, and base their performance against that.
The list means that they are never short of work to do, so our ideally motivated candidate will always be working towards the company's goals. This list should comprise of at least one easy thing "I can do that in an hour", one "less than a week" project, and one "greater than a week" project. This provides your developers with a bit of variety, so they don't get burned out on trying to grind through the tough problems. It also makes them feel like they're making progress by letting them knock out at least one project every week - this can be very motivating.
The Scotty factor (development estimate * 3) will give you a more realistic idea of how long something will take. I use it on my own estimates, and it's accurate more often than it's not. You can use this to gauge both their skill at estimating, and as a measuring stick for identifying when they are underperforming (getting a second opinion on an estimate can help identify the underperforming part).
This does mean that you won't be able to look at the output of a given day/week and gauge a worker's performance just on that. However, you will be able to look back on a month, six months, or more, and get real data with which to identify the exceptional performers and those who need help (and perhaps even those who need to be let go).