4 ms·

You should be paid to do a fixed amount of work (generate a certain amount of value for your employer), not work a fixed number of hours. If you can get that wo

by thurn 15y ago

You should be paid to do a fixed amount of work (generate a certain amount of value for your employer), not work a fixed number of hours. If you can get that work done in 10 hours a week, everybody wins. If you need to work 70 hours a week to do that work, well, maybe you're not a good fit for the job.

okamiueru 15y ago
How do you consider the factor "good work"? You can finish a job quickly, but it'll bite you (or a coworker) in the ass later, or you can do the job well, but take you longer. As a programmer, I can't thing of a worse way of management than the former. You'd have to start defining criteria for "good work", and then spend tons of time reviewing. Nightmare.
RDDavies 15y ago
^I'm inclined to agree with you. There's definitely NOT an economy of scale when it comes to developer productivity. Sure, my company has some guys making $60K a year, but they certainly get a lot less than half or a third as much as the senior-level folks. I've got a lot more to say on this, perhaps a blog entry is in order.
robryan 15y ago
For a big company at least, I feel that this is an ideal world solution rather than a real world one. The amount of hours tasks take are going to be really hard to estimate, meaning that your work hours will on part depend on the luck of tasks allocated. Also you will have plenty of people out to game this by setting low expectations of what can be achieved in the week and making those in less hours.
fmx 15y ago
The problem with that is measuring the amount of value you generate. For some jobs that's easy, like sales - and those jobs typically do pay based on the value generated (ie. commission), at least in part. But for software development and other knowledge worker jobs it's just about impossible.
praptak 15y ago
I haven't heard of a company that lets you idle even if you produce an average employee's week output in a day. The 'fixed amount of work' only works one way. You need 70 h to do it? Stay long hours. You did it in 20 hours? Well great, we'll just pile more work on you.

by thurn 15y ago

okamiueru 15y ago

How do you consider the factor "good work"? You can finish a job quickly, but it'll bite you (or a coworker) in the ass later, or you can do the job well, but take you longer. As a programmer, I can't thing of a worse way of management than the former. You'd have to start defining criteria for "good work", and then spend tons of time reviewing. Nightmare.

RDDavies 15y ago

^I'm inclined to agree with you. There's definitely NOT an economy of scale when it comes to developer productivity. Sure, my company has some guys making $60K a year, but they certainly get a lot less than half or a third as much as the senior-level folks. I've got a lot more to say on this, perhaps a blog entry is in order.

robryan 15y ago

For a big company at least, I feel that this is an ideal world solution rather than a real world one. The amount of hours tasks take are going to be really hard to estimate, meaning that your work hours will on part depend on the luck of tasks allocated. Also you will have plenty of people out to game this by setting low expectations of what can be achieved in the week and making those in less hours.

fmx 15y ago

The problem with that is measuring the amount of value you generate. For some jobs that's easy, like sales - and those jobs typically do pay based on the value generated (ie. commission), at least in part. But for software development and other knowledge worker jobs it's just about impossible.

praptak 15y ago

I haven't heard of a company that lets you idle even if you produce an average employee's week output in a day. The 'fixed amount of work' only works one way. You need 70 h to do it? Stay long hours. You did it in 20 hours? Well great, we'll just pile more work on you.