The queues of things to do is always extremely long.

There are 1000 tickets in your JIRA queue. They then ask you, what can you do in the 2 week (or 1 week) sprint?

What do you say? Is it the 10 hour or 40 hour timeframe? That happens all the time in development, and people do a few things. They underestimate a lot or they write code that is 90%, where when bad things happen, it's ugly to clean up.

So the results are what you say you can do in your week of work. And of course, they will put the pressure of "but that's easy." Yada yada.

As a results oriented place, some companies pack in what you think is 80 in your 40 hour work week (a lot of companies will try to do this). So what happens then? You switch jobs?

As for improving the process, most engineers don't know exactly how. They speculate and guess, hoping to hit it right. It's really up to the people driving it to affect the company culture. Doing it as an individual within an organization is quite difficult.

That's what I've experienced at certain companies anyways, generally with management with less experience, tbh.

Let's be honest. Both a Results-Only Work Environment or a "9-5 in the office" environment try to pack as much into an employee's schedule as possible. That's not unique to ROWE.

Some of the answers to your questions are: well, what do you do now, and how can that be made better? ROWE isn't magic. It's just a recognition that pretending that you're paying for hours spent in an office is nonsense, and that we should talk about the work itself rather than the things that don't have to do with the work.

The old equation (fetishistically held to, even in the face of its absurdity) of TIME + PRESENCE = RESULTS typically takes the focus of the conversation, and we end up in conversations about who can work remotely, and how many hours people should put in, etc. Instead of talking about the stuff we're actually paid to deliver.

As for not knowing how to improve processes, I don't mean that we should just say to them "hey, go improve things." It's a crucial management responsibility to make sure that people know how to do this sort of thing, to teach them how, and to provide ongoing coaching in doing it.

> 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.

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.

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.

> 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.