3 ms·

10x productivity is fairly common when onboarding people to a project, though it's not quite so obvious because you'll give the new person small bugs or stories

10x productivity is fairly common when onboarding people to a project, though it's not quite so obvious because you'll give the new person small bugs or stories. And if someone is simply not productive, there might continue to be a 10x between team members, and the team keeps giving the unproductive person small or non-essential tasks, and not accounting for the support that member receives to finish that work. I've been on both sides of the 10x divide (i.e., the 1x working with a 10x, the 10x working with a 1x). To be clear, these productivity levels were relative to the project, understanding of the project, and the point in the project's lifecycle. There's native talent, but context is just as important. It's not really sustainable to have that productivity difference unless you have a team structure to support it and bring people up – and sometimes I wonder if the team structure is more emotional cover than an actual aggregate productivity boost. It's not sustainable because the 1x developer can't handle the 10x developer's velocity of change. If you are the 1x developer, just at the point when you think you've finally made a valuable improvement, the rug gets pulled out from underneath you yet again because of a change or fix made by someone else. It's demoralizing for everyone, and the 1x developer often becomes the 0x developer (I'm afraid this has also happened to me). It's harder to find unsustainable states because they don't last for long (team breaks up, everyone becomes demoralized, people drift off, etc), which is part of why I think 10x productivity is sometimes treated as a myth.

watwut 9y ago
I have seen similar dynamic happen too and would put blame for the situation on the supposed 10x developer. The result is more likely a conswquence of missing communication about changes being done and badly split tasks/responsibilities. Good senior developer should know not to pull rugs from junior. He should not be rewriting juniors work that often. I mean seriously, demotivation happening this way means that the 10x dude should not work in team at all - he should have work individually.
- ianbicking 9y ago
  People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to manage the velocity of change. A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output. How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.

watwut 9y ago

I have seen similar dynamic happen too and would put blame for the situation on the supposed 10x developer. The result is more likely a conswquence of missing communication about changes being done and badly split tasks/responsibilities. Good senior developer should know not to pull rugs from junior. He should not be rewriting juniors work that often. I mean seriously, demotivation happening this way means that the 10x dude should not work in team at all - he should have work individually.

ianbicking 9y ago
People can handle it better or worse, but honestly I think it's just a hard situation with no perfect answers. You're basically proposing adding process to manage the velocity of change. A common situation, for example – some small bug is assigned to a less productive member of the team. The fast developer has to touch that area of the code for some other (often more critical) change. The fast developer sees the bug and just fixes it, or perhaps invalidates the need for that bug fix. Now the less productive member has their work undone. Claiming territory would slow down the fast developer, and also is demotivating for people who are motivated by increased code and product quality and want to bring that attitude to every bit of code they touch. You can run a smallish team with widespread improvements if you are in a situation where turnaround is fast. We're not going to run into too many conflicts if each of us finish our work and get it merged on a daily basis. But then you have that one person who takes a week on a change, and it doesn't go so well. Unless you put them in some codebase ghetto, where changes won't conflict because no one actually cares about the output. How do you manage multiple kinds of vehicles on the road? Speed limits? Minimum speeds? Passing lanes? Semaphores? There's no one right answer, and all the answers are wrong from some perspective.