[NoMoreNicksLeft]

> They're paying me for the results. Not for the hours.

True. But since "results" aren't exactly quantifiable, how can they get steady value for their money?

Is result A equal to result B or result Q? If results M, N, and O are all equal, how many M/N/O results does it take to earn one week's worth of paycheck?

What if they decide that they're paying too much for M/N/O results, and want at least 11 of those per week instead of the current 4?

What if you wait an entire week for the dumb assholes in the other department to deliver the specifications? Do you not get paid that week?

You're paid by the hour not because hours are the best way to measure accomplishments, but because it's easy to measure hours and difficult to measure anything else.

[seanstickle]

I feel for you. Apparently you don't have a boss who can define what they want from you. This is not uncommon, and we're struggling with that ourselves. We've all spent so many years with the belief that putting in hours is the work, that we don't really know what we've hired people to actually do.

All your questions are the same questions you have in an TIME + PRESENCE = RESULTS job. What if they decide they want 11 instead of the current 4. What if you wait an entire week for the other department? These are all still problems. Are you excusing yourself from dealing with them because you say "hey, 40 hours in and I'm done, bye!"?

It's not difficult to measure results of work that you hire people to do. It's hard to decide to start doing that though.

[Scalestein]

I'm all for the 'results based' work environment but I think measuring results of work that you hire people to do IS quite hard.

A great example is refactoring. Say you hired a dev and he delivered a product that worked but is written terribly (already a question there, how do you gauge that in terms of 'results'?). Now you hire a second dev to clean it up and make it maintainable. How do you evaluate when he has delivered the 'results'?

edit: I think the closest thing to a true results based workplace would be an early stage startup. Everyone is invested in the product and striving towards creating it, not just putting in hours. In those cases people usually end up working WAY more than 40 hours a week.

[NoMoreNicksLeft]

> A great example is refactoring. Say you hired a dev and he delivered a product that worked but is written terribly (already a question there, how do you gauge that in terms of 'results'?). Now you hire a second dev to clean it up and make it maintainable. How do you evaluate when he has delivered the 'results'?

Easy. Lines of code.

The first developer did an awesome jobs, many lines of code were written. The second one is a lousy hack, he earned about $50 (not $50k).

This is ridiculous of course, but it does show how even bad measurements are preferred over non-measurement.