3 ms·

What does "results" mean in knowledge work? It's impossible to know whether the results could have been achieved faster or better if you had indeed measured hou

What does "results" mean in knowledge work? It's impossible to know whether the results could have been achieved faster or better if you had indeed measured hours. I'm not saying measuring hours is the only thing to watch, but you can't simply track a undefined concept like "results".

kubrick 18y ago
If it's your company, you know what results are (you'd better!). No, you can't track that, but I'm not sure it's meanful to compare startup progress.
swombat 18y ago
You mentioned further down that you're a manager.. results are whatever you've agreed with your team is the "deliverable". So you might agree on having a set of bugs fixed, for instance, or agree on getting a piece of functionality implemented. I'm not an expert on ROWE, but as I understand it, the key is that you agree on results which you (as a manager) are satisfied with and which the team (who will produce those results) is satisfied with. Then, you don't care about how many hours they work. At the agreed time, you expect the result that you agreed on. If it's there, no problem, move on to the next bit of work that needs to happen. If it's not there, then you can sit down with your team and figure out why (but avoid the all-too-easy accusation that "they didn't spend enough time on it"). Apparently this technique (along with a set of workplace practices that actively discouraged managers from trying to figure out whether their teams were actually working or doing something else) worked really well for Best Buy.
- davidw 18y ago
  I guess the difficult bit is when "results" are something like "build me a new web site". Taking on clients like those on a fixed-bid basis is a recipe for disaster.
- lennysan 18y ago
  Since with engineers you rely on them estimate how long things will take, and the last thing you want to do is keep nagging them to decrease that time, it's easy for engineers in a non-startup company to lose the sense of "urgency" and get complacent with the estimates, adding buffers to make sure they are never late. How would you try to keep ever increasing estimates?
  - swombat 18y ago
    Ultimately, you have to work with people you can trust. If they trust that you won't suddenly spring some bad surprise on them, and if you trust that they won't artificially pad their estimates and slack off (which is very unlikely unless you're working with some really bad apples), there shouldn't be a problem of padded estimates.
- akeefer 18y ago
  That's one of the things that agile development should ideally give you (in practice, of course, it's never as easy as it sounds). You make short-term (i.e. per-iteration, often 1-2 weeks) commitments to get things done, and base the amount you commit to on the amount you got done in the past in that amount of time. Other than that, leave the developers alone and let them get their work done. That gives developers a reasonable target that they can be held accountable for, which tends to make everyone happier. Longer-term commitments (we'll release in 6 months with features X, Y, and Z) on software projects tend to be impossible to make accurately or to live up to, so as an engineer it's impossible to really take them seriously or to be held accountable to them. By making the commitments much smaller and near-term, they're much more reasonable and doable and much more likely to be taken seriously by all parties.

kubrick 18y ago

If it's your company, you know what results are (you'd better!). No, you can't track that, but I'm not sure it's meanful to compare startup progress.

swombat 18y ago

You mentioned further down that you're a manager.. results are whatever you've agreed with your team is the "deliverable". So you might agree on having a set of bugs fixed, for instance, or agree on getting a piece of functionality implemented. I'm not an expert on ROWE, but as I understand it, the key is that you agree on results which you (as a manager) are satisfied with and which the team (who will produce those results) is satisfied with. Then, you don't care about how many hours they work. At the agreed time, you expect the result that you agreed on. If it's there, no problem, move on to the next bit of work that needs to happen. If it's not there, then you can sit down with your team and figure out why (but avoid the all-too-easy accusation that "they didn't spend enough time on it"). Apparently this technique (along with a set of workplace practices that actively discouraged managers from trying to figure out whether their teams were actually working or doing something else) worked really well for Best Buy.

davidw 18y ago
I guess the difficult bit is when "results" are something like "build me a new web site". Taking on clients like those on a fixed-bid basis is a recipe for disaster.
lennysan 18y ago
Since with engineers you rely on them estimate how long things will take, and the last thing you want to do is keep nagging them to decrease that time, it's easy for engineers in a non-startup company to lose the sense of "urgency" and get complacent with the estimates, adding buffers to make sure they are never late. How would you try to keep ever increasing estimates?
- swombat 18y ago
  Ultimately, you have to work with people you can trust. If they trust that you won't suddenly spring some bad surprise on them, and if you trust that they won't artificially pad their estimates and slack off (which is very unlikely unless you're working with some really bad apples), there shouldn't be a problem of padded estimates.
akeefer 18y ago
That's one of the things that agile development should ideally give you (in practice, of course, it's never as easy as it sounds). You make short-term (i.e. per-iteration, often 1-2 weeks) commitments to get things done, and base the amount you commit to on the amount you got done in the past in that amount of time. Other than that, leave the developers alone and let them get their work done. That gives developers a reasonable target that they can be held accountable for, which tends to make everyone happier. Longer-term commitments (we'll release in 6 months with features X, Y, and Z) on software projects tend to be impossible to make accurately or to live up to, so as an engineer it's impossible to really take them seriously or to be held accountable to them. By making the commitments much smaller and near-term, they're much more reasonable and doable and much more likely to be taken seriously by all parties.