At one place I worked, a high-up guy once remarked how he was puzzled how there could be such wide divergence in the level of effort software developers make. He stated it something like the following:
I look around and I see some people working really, really, hard—putting in extra hours and so on. Then I look around and see some people working not very hard. And I wonder why everyone isn't working hard. If those in the second group worked as hard as those in the first group, then we'd be getting a lot more done.
This guy wasn't the big cheese, but he was up there a good ways on the ladder, so I'm unsure whether his comment was merely an attempt to motivate us or if he really was puzzled about his employees' work ethics. I'm not puzzled why it's in some developers' self-interest to slack-off (because I've been in that position a few times). I've even formulated my own 80-20 rule to explain it.
In a sufficiently large software project, 80% of the developers produce about 20 hours of work, on average, each week.
Those words, “sufficiently large”, can cover a lot, but I mean them in the way that you'd probably expect—a project that's too complex to be understood fully by any one person and where (probably) not all developers know all other developers—at least, not well. In other words, I'm talking about a software project with a non-trivial social hierarchy.
As to why the phenomenon of the 80-20 occurs, here's my theory: Developers show up to work because of the paycheck, but they work hard only when they're mentally rewarded. Stated another way, a paycheck buys compliance but creative ownership earns actual productivity.
Small software projects can hand out the juicy, fun, creative problems fairly evenly among developers, but somehow this doesn't happen when there's a social hierarchy. When not everyone knows everyone else, when not everyone trusts everyone else, there exists perceived incentive to keep those juicy bits for oneself, and somehow, in sufficiently large software projects, the Keepers of the Juicy Bits self-organize to become about 20% of the project's staff. Everyone else is just going through the motions, solving routine problems at an easy-does-it pace and baffling the higher ups with their casual attitudes.
I don't have a solution to the 80-20 rule, and the higher ups may endlessly continue to puzzle why they can't get their developers to care as much as they do. But from the individual's perspective, the 80-20 rule suggests avoiding becoming lost somewhere in the 80%.
2 comments:
Excellent points. I couldn't have agreed more.
Anonymous—Thank you, though I also condone disagreement.
Post a Comment