3 ms·

> The best developers are almost always intrinsically motivated. Have you managed a large team before? The single best way I know to demotivate a highly motiva

> The best developers are almost always intrinsically motivated. Have you managed a large team before? The single best way I know to demotivate a highly motivated developer is to let them see a coworker at the same pay grade do significantly less work without any good reason. (footnote: individuals going through cancer treatment are the tricky complication here, due to privacy issues) And I should emphasize that for most of the developers I've managed, it wasn't a fear thing like, "oh, he'll fire me if I don't work" but rather a removal of the sentiment that, "why should I keep working so hard when others here don't pull their weight and are being rewarded for it?" That's a large part of the reason I like semi-enforced distributions in curve-oriented review systems. Many managers, particularly first-level leads, tend to pull their rewards towards the mean (barely rewarding high performers and still rewarding low performers) instead of focusing on doing the right thing at the tails. Though that's certainly no guarantee of success; I got a decently sized development and test organization (~60 of each) merged into our organization and it took nearly a month of full-time work for myself (and one of my peers) to sort out the years of misrewarded individuals to get neglected high performers promoted and HR action started on people who'd been resting and vesting.

InclinedPlane 14y ago
These aren't comparable situations necessarily. How you fix a mostly functional organization with problems is different from how you fix a fundamentally dysfunctional organization. If you have a functional organization then it makes sense to get rid of all the low performers, regardless of how much "effort" they're putting in. And if you end up with someone who is able to work fewer hours and still be as productive as other team members you would be silly to get rid of them even if other team members were upset.
- lsc 14y ago
  and, I think, Engineers have their own hierarchy; we understand that an hour of the new kid's time is worth maybe 5 minutes of the really expert person's time. Generally speaking, if one person isn't working all that hard but is contributing a lot (due to greater skill) the other Engineers can recognize and appreciate this. We all understand the tradeoff between ability and effort; The better you are, the less effort is required (but, there are minimum levels for both effort and ability; no matter how awesome you are, you need some minimum level of effort; even if you dedicate your life to the job, you need some level of ability. - but, to some extent, ability can make up for a lack of effort, and effort can make up for a lack of ability.)
rpfennig 14y ago
>That's a large part of the reason I like semi-enforced distributions in curve-oriented review systems. I'm still at the point where I tend to see the disadvantages of this approach. It seems to me that, in terms of performance management, that the important pieces are the regular one on ones and an honest effort to work equally with people who are high/normal/low performers to improve. A forced distribution seems to work against that because it puts people in the position of defending themselves rather than being open to a discussion. However, that's my view from a bit further down the food chain from your own experience (as a first level lead for teams between 21 and 37 developers). I also agree with InclinedPlane that ultimately it's about intrinsic motivation and being connected to work that interests you. If you can create that kind of work environment you'll get developers who are engaged and want to work hard because it's something that interests them.

InclinedPlane 14y ago

These aren't comparable situations necessarily. How you fix a mostly functional organization with problems is different from how you fix a fundamentally dysfunctional organization. If you have a functional organization then it makes sense to get rid of all the low performers, regardless of how much "effort" they're putting in. And if you end up with someone who is able to work fewer hours and still be as productive as other team members you would be silly to get rid of them even if other team members were upset.

lsc 14y ago
and, I think, Engineers have their own hierarchy; we understand that an hour of the new kid's time is worth maybe 5 minutes of the really expert person's time. Generally speaking, if one person isn't working all that hard but is contributing a lot (due to greater skill) the other Engineers can recognize and appreciate this. We all understand the tradeoff between ability and effort; The better you are, the less effort is required (but, there are minimum levels for both effort and ability; no matter how awesome you are, you need some minimum level of effort; even if you dedicate your life to the job, you need some level of ability. - but, to some extent, ability can make up for a lack of effort, and effort can make up for a lack of ability.)

rpfennig 14y ago

>That's a large part of the reason I like semi-enforced distributions in curve-oriented review systems. I'm still at the point where I tend to see the disadvantages of this approach. It seems to me that, in terms of performance management, that the important pieces are the regular one on ones and an honest effort to work equally with people who are high/normal/low performers to improve. A forced distribution seems to work against that because it puts people in the position of defending themselves rather than being open to a discussion. However, that's my view from a bit further down the food chain from your own experience (as a first level lead for teams between 21 and 37 developers). I also agree with InclinedPlane that ultimately it's about intrinsic motivation and being connected to work that interests you. If you can create that kind of work environment you'll get developers who are engaged and want to work hard because it's something that interests them.