4 ms·

Agreed, and I think we all know this, but none of the substitute questions he proposes approach anything resembling an objective measure.

Retric 18y ago
I have literally gotten as much done in 4 hours as anther teammate did in 2 weeks. (Fixed the same bug.) However, usually we don't have direct comparisons. I wonder if breaking a team down into 2 sub teams that compete over 2 week periods to fix the same bugs might be an interesting solution. I suspect most people would be more productive, but less than twice as productive. However, you would then be able to directly pick the "best" output which could be vary valuable. Add in the ability to discover and drop unproductive people and you might have a net win. Edit: Ok, you might also create a hostile, environment that is so stressful you force the most productive people to leave.
- djahng 18y ago
  Your experiment of creating 2 teams would be an interesting one. But I think one team should be given 2 weeks and the other team should be given 1 (or less), and they cannot know of the other team or that they're trying to solve the same problem. If teams are in direct competition with each other, you get that sibling rivalry effect that almost tore Apple apart (Machintosh vs II).
- anthonyrubin 18y ago
  This type of experiment was done by the Peopleware authors. They are the source of many of the productivity numbers you see quoted for software developers.
  - rayvega 18y ago
    Yes. The concept of the "10x developer" is one of those examples that describe the variance in productivity among software developers http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx http://forums.construx.com/blogs/stevemcc/archive/2008/03/27...
swombat 18y ago
I would say, the only valid objective measure is results. That, interestingly, is what a couple of psychologists tried and succeeded in implementing at Best Buy, of all places. See: http://en.wikipedia.org/wiki/ROWE http://en.wikipedia.org/wiki/ROWE They seem to have been very happy with the results they got from that. If you want to evaluate results, why measure hours?
- lennysan 18y ago
  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.
    - 18y ago
shimon 18y ago
I think this is partly the point of the article: when you're forced to rely on objective metrics, you will avoid some of the questions that distinguish good performance from great performance. That's one advantage of tiny companies, which don't have to rely on such metrics because everyone takes the company's overall performance as their personal responsibility.
kubrick 18y ago
How about milestones achieved? Anything but hours. I did the startup thing (worked at a successful startup) 10 years ago, and we did work long days -- but spent most of that time creating things from whole cloth that exist as commodities today. (Everything from fast search libraries to infrastructure tools.) I don't believe that most founders need to work 12-hour days. Not anymore. It's not the hours -- it's your progress that counts.
- chenelson 18y ago
  Milestones alone are often abused, too. In startup work, people are invested and there's too little time and even less reward to compare what I'm dong to what someone else isn't. If someone doesn't deliver, someone else steps up and we move on. In mature organizations, everyone is not running to the copier, and people begin to take notice of the terrain. Politics, unpredictability, and general people challenges are perceived as a drag on the system. As a defense mechanism, especially if incentives are involved, milestones are defined not for the common good, but to route around points of potential failure. Milestones make it really easy for the offense to blame special teams and the defense to blame the coach after the team lost, even though they all celebrated success at different times during the game. I agree, progress and outcome is what counts. And I think iteration and feedback loops are essential: yesterday's unrefined solution isn't the best answer tomorrow.

Retric 18y ago

I have literally gotten as much done in 4 hours as anther teammate did in 2 weeks. (Fixed the same bug.) However, usually we don't have direct comparisons. I wonder if breaking a team down into 2 sub teams that compete over 2 week periods to fix the same bugs might be an interesting solution. I suspect most people would be more productive, but less than twice as productive. However, you would then be able to directly pick the "best" output which could be vary valuable. Add in the ability to discover and drop unproductive people and you might have a net win. Edit: Ok, you might also create a hostile, environment that is so stressful you force the most productive people to leave.

djahng 18y ago
Your experiment of creating 2 teams would be an interesting one. But I think one team should be given 2 weeks and the other team should be given 1 (or less), and they cannot know of the other team or that they're trying to solve the same problem. If teams are in direct competition with each other, you get that sibling rivalry effect that almost tore Apple apart (Machintosh vs II).
anthonyrubin 18y ago
This type of experiment was done by the Peopleware authors. They are the source of many of the productivity numbers you see quoted for software developers.
- rayvega 18y ago
  Yes. The concept of the "10x developer" is one of those examples that describe the variance in productivity among software developers http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivity-variations-among-software-developers-and-teams-the-origin-of-quot-10x-quot.aspx http://forums.construx.com/blogs/stevemcc/archive/2008/03/27...

swombat 18y ago

I would say, the only valid objective measure is results. That, interestingly, is what a couple of psychologists tried and succeeded in implementing at Best Buy, of all places. See: http://en.wikipedia.org/wiki/ROWE http://en.wikipedia.org/wiki/ROWE They seem to have been very happy with the results they got from that. If you want to evaluate results, why measure hours?

lennysan 18y ago
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.
  - 18y ago

shimon 18y ago

I think this is partly the point of the article: when you're forced to rely on objective metrics, you will avoid some of the questions that distinguish good performance from great performance. That's one advantage of tiny companies, which don't have to rely on such metrics because everyone takes the company's overall performance as their personal responsibility.

kubrick 18y ago

How about milestones achieved? Anything but hours. I did the startup thing (worked at a successful startup) 10 years ago, and we did work long days -- but spent most of that time creating things from whole cloth that exist as commodities today. (Everything from fast search libraries to infrastructure tools.) I don't believe that most founders need to work 12-hour days. Not anymore. It's not the hours -- it's your progress that counts.

chenelson 18y ago
Milestones alone are often abused, too. In startup work, people are invested and there's too little time and even less reward to compare what I'm dong to what someone else isn't. If someone doesn't deliver, someone else steps up and we move on. In mature organizations, everyone is not running to the copier, and people begin to take notice of the terrain. Politics, unpredictability, and general people challenges are perceived as a drag on the system. As a defense mechanism, especially if incentives are involved, milestones are defined not for the common good, but to route around points of potential failure. Milestones make it really easy for the offense to blame special teams and the defense to blame the coach after the team lost, even though they all celebrated success at different times during the game. I agree, progress and outcome is what counts. And I think iteration and feedback loops are essential: yesterday's unrefined solution isn't the best answer tomorrow.