|
|
|
|
|
by Kadin
3212 days ago
|
|
I recently re-read the classic "Peopleware" (written 1974) and I think it's a bit unfortunate, given all the innovation elsewhere in the field, that there hasn't been much innovation or even experimentation about the nature of employment or how teams are constructed and actually execute work. Sure, there's a new "method" every few years but these seem like tinkering around the edges. I admit this is not a fully-formed idea but I've wondered about a concept where an entire team would be compensated as a team, but then the team would be responsible for hiring/firing. (Which seems only fair -- if you're going to be compensated as a team you should have control over it.) A group "audition" interview technique is discussed in Peopleware that I have sadly never seen implemented, but something like that could form a part. But as long as people are compensated on an individual basis there will always be an incentive to treat communication and particularly assistance or training of other team members as a second-tier function, to be done only reluctantly if at all. But viewed from the throughput or potential of a team, someone who increases the performance of multiple other developers has a much greater shot, in my experience, of being the mythical "10X developer" than even a very strong individual contributor. And the reverse is certainly well-known to be true: someone who hurts the performance of people around them, even if they produce good code at a reasonable rate, may actually be worse than useless to the team as a whole. Producing an incentive structure that takes those issues into account that's based on measuring individual performance is extremely difficult, and I've begun to think impossible, given that the industry has been trying to do it for decades with little apparent progress. |
|
It's the same result of you get what you measure