One-tenth of the participants produce over one-third of the output. Increasing the number of participants merely reduces the average output.
“In fact, the least productive half of all participants seems to generate no more than 20 percent of the total output. … Only about one-third of all workers typically achieve a level of contribution equal to the average of those who contribute. … Astonishingly, the top 1 percent produce nearly twenty times the per capita output of the bottom half in many measurable undertakings.”
I assume that this information is backed by actual data on participant output. Surrounding text indicates that output was determined (in at least some cases) by production of patents or articles. I won’t quibble with that definition of output. It’s certainly more measurable than many contributions to software development projects, and seems more interesting than, say, SLOC produced.
My first wondering is whether the ranking of participants by productivity (or output) is intrinsic or situational. In the case of programmers, will programmer A (PA) always produce the same amount of output relative to programmer B (PB) in a given situation or can appropriate management coax higher relative output from PA while maintaining PB’s output?
Put that way, I have to think that ranking is a combination of intrinsic and situational. Data shows wide variance in programmer productivity on small projects (and there’s no particular reason to assume differently on larger projects, although I can certainly think of organizational factors that might break down in more complex projects). I have always assumed that there are differences in productivity based upon programmer knowledge (someone who knows 3D math is likely to be more efficient at creating 3D graphics code than someone who doesn’t) and based upon something I refer to as “temperament” (some people are more careful, some like jumping in and creating the first working version, some people like polishing the last problems out, some people are more intuitive debuggers, some are more methodical, etc.). There are also intrinsic qualities that effect productivity like one’s susceptibility to being interrupted. It would be fascinating to re-examine the data Joel Spolsky cites above to find out whether relative productivity is a quality of individual programmers or whether it is a quality of individual projects. Does programmer A always have roughly twice the productivity of programmer B or does the project they are working on matter? I’ve asked the question in Joel’s forums and perhaps there will be an answer.
My second wondering is specific to programmers: is a good manager’s opinion of ranking by productivity at all related to actual measurable productivity? This is obviously a hard question because real-world programmer productivity is a hard thing to measure.
If productivity (or a large part of productivity) is not intrinsic but situational, it puts a greater burden on managers to figure out how to get the most productivity from workers. It’s good for organizations in a lot of ways because it expands the possible pool of high-productivity participants. It’s bad for organizations because it’s harder to consistently reward high-productivity participants with the expectation that rewards will be recouped by future high productivity.
It’s especially bad for organizations that think programmers (or other knowledge workers) are interchangeable parts.
If productivity is largely intrinsic and can be reasonably accurately established by managers, doing reviews and raises is a lot easier, but the inherent limits in availability of high-productivity workers is a serious problem for organizations doing cutting edge development. If you want to do cost-effective development, if you want to produce the coolest stuff in the least amount of time, if you want, in short, to do efficient development, you have to do it with primarily high-productivity workers.
And they are a limited resource. If you are EA, you can’t expect to staff a 50 person team with only people in the top 10%. You especially can’t expect to keep a lot of people in the top 10% if you treat them like field hands.
If productivity is intrinsic, that suggests moving to larger and larger teams is, in the long run, counterproductive. Less counterproductive, perhaps, if you can isolate the bleeding edge of the product and let a small Tiger team of high-productivity workers do it while a bunch of less-productive workers do the rest of the “grunt work”, but that sort of organization is going to make a hash of employee morale and esprit de corps, not to mention almost certainly hurting retention and overall productivity among the non-Tigers.
In the long run, it might turn out that the best strategy for people doing cutting edge development (or who require efficient development for other reasons) turn their attention to working in smaller teams, assigning only their best high-productivity workers to those teams, and thus perhaps end up with smaller projects as a result. Much easier to do a limited content one-level game this way than the next Madden (and perhaps there is more need for creativity and efficiency if you’re launching a new game property, or a new game type, than there is in doing the next version of an established sports franchise).