"The productive programmer in that environment is the one who is best at understanding and implementing the users' needs, not the one who can write the cleverest code." (From Carson63000 answer)

That key point coupled with bethlakshmi's points makes a huge point. A great developer can be great in his/her one slice of reality but break apart soon as the world changes. Being able to keep up with the business' needs is far more important than anything else. At the end of the day, unless your business is technology, the business doesn't care about technology; they need solutions. So being great with design patterns doesn't mean diddly squat to end-users who just need a data dump to show on a webpage. I've seen mediocre developers secure themselves a job by catering to the business that supports them while great developers get bored and walk away in search of a never-ending challenge. Depending on your organization and project(s), it's possible to feed these challenge-starved developers but likely, there will be a point in time when you just don't need that amount of processing power. These developers don't like to just sit idle like a processor. They'll shutdown and reboot elsewhere.

Lastly, I'll say it's OK to know who your "key" performers are, but a development "team" is still a team. To reiterate bethlakshmi, "what are you going to do with this metric?" If you need a team that behaves like a team, I wouldn't focus on metrics as these. I would realize that even the smallest player is still an important part of the team. Even at 60% less of the productivity of your key player, that one player may be giving your team something it needs. Find out what it is and try to multiply it. Don't burn out your key player by assuming he should lead the team, find ways to multiply his output as well, by contaminating the other players with that greatness. This requires a bit of creativity, not just numbers. In the end, you may learn that what makes a good programmer is not even that programmer, it could be his peers, his opportunities in the workplace or it could even be you.

"The productive programmer in that environment is the one who is best at understanding and implementing the users' needs, not the one who can write the cleverest code." (From Carson63000 answer)

That key point coupled with bethlakshmi's points makes a huge point. A great developer can be great in his/her one slice of reality but break apart soon as the world changes. Being able to keep up with the business' needs is far more important than anything else. At the end of the day, unless your business is technology, the business doesn't care about technology; they need solutions. So being great with design patterns doesn't mean diddly squat to end-users who just need a data dump to show on a webpage. I've seen mediocre developers secure themselves a job by catering to the business that supports them while great developers get bored and walk away in search of a never-ending challenge. Depending on your organization and project(s), it's possible to feed these challenge-starved developers but likely, there will be a point in time when you just don't need that amount of processing power. These developers don't like to just sit idle like a processor. They'll shutdown and reboot elsewhere.

Lastly, I'll say it's OK to know who your "key" performers are, but a development "team" is still a team. To reiterate bethlakshmi, "what are you going to do with this metric?" If you need a team that behaves like a team, I wouldn't focus on metrics as these. I would realize that even the smallest player is still an important part of the team. Even at 60% less of the productivity of your key player, that one player may be giving your team something it needs. Find out what it is and try to multiply it. Don't burn out your key player by assuming he should lead the team, find ways to multiply his output as well, by contaminating the other players with that greatness. This requires a bit of creativity, not just numbers. In the end, you may learn that what makes a good programmer is not even that programmer, it could be his peers, his opportunities in the workplace or it could even be you.

It's a shame I can't comment or up-vote due to lack of points. Having said that, this is not an answer, just my strong support for Carson63000's and bethlakshmi's contributions plus a few of my own.

"The productive programmer in that environment is the one who is best at understanding and implementing the users' needs, not the one who can write the cleverest code." [Carson63000]

That key point coupled with bethlakshmi's points makes a huge point. A great developer can be great in his/her one slice of reality but break apart soon as the world changes. Being able to keep up with the business' needs is far more important than anything else. At the end of the day, unless your business is technology, the business doesn't care about technology; they need solutions. So being great with design patterns doesn't mean diddly squat to end-users who just need a data dump to show on a webpage. I've seen mediocre developers secure themselves a job by catering to the business that supports them while great developers get bored and walk away in search of a never-ending challenge. Depending on your organization and project(s), it's possible to feed these challenge-starved developers but likely, there will be a point in time when you just don't need that amount of processing power. These developers don't like to just sit idle like a processor. They'll shutdown and reboot elsewhere.

Lastly, I'll say it's OK to know who your "key" performers are, but a development "team" is still a team. To reiterate bethlakshmi, "what are you going to do with this metric?" If you need a team that behaves like a team, I wouldn't focus on metrics as these. I would realize that even the smallest player is still an important part of the team. Even at 60% less of the productivity of your key player, that one player may be giving your team something it needs. Find out what it is and try to multiply it. Don't burn out your key player by assuming he should lead the team, find ways to multiply his output as well, by contaminating the other players with that greatness. This requires a bit of creativity, not just numbers. In the end, you may learn that what makes a good programmer is not even that programmer, it could be his peers, his opportunities in the workplace or it could even be you.

"The productive programmer in that environment is the one who is best at understanding and implementing the users' needs, not the one who can write the cleverest code." (From Carson63000 answer)

That key point coupled with bethlakshmi's points makes a huge point. A great developer can be great in his/her one slice of reality but break apart soon as the world changes. Being able to keep up with the business' needs is far more important than anything else. At the end of the day, unless your business is technology, the business doesn't care about technology; they need solutions. So being great with design patterns doesn't mean diddly squat to end-users who just need a data dump to show on a webpage. I've seen mediocre developers secure themselves a job by catering to the business that supports them while great developers get bored and walk away in search of a never-ending challenge. Depending on your organization and project(s), it's possible to feed these challenge-starved developers but likely, there will be a point in time when you just don't need that amount of processing power. These developers don't like to just sit idle like a processor. They'll shutdown and reboot elsewhere.

Lastly, I'll say it's OK to know who your "key" performers are, but a development "team" is still a team. To reiterate bethlakshmi, "what are you going to do with this metric?" If you need a team that behaves like a team, I wouldn't focus on metrics as these. I would realize that even the smallest player is still an important part of the team. Even at 60% less of the productivity of your key player, that one player may be giving your team something it needs. Find out what it is and try to multiply it. Don't burn out your key player by assuming he should lead the team, find ways to multiply his output as well, by contaminating the other players with that greatness. This requires a bit of creativity, not just numbers. In the end, you may learn that what makes a good programmer is not even that programmer, it could be his peers, his opportunities in the workplace or it could even be you.