This is always the result of someone looking at productivity as zero sum, some management practices encourage zero sum behavior. If management doesn't actively incentivize non-zero sum behavior - then zero sum behavior rules. Consider the following list of highly effective zero sum behaviors.
Effective Zero Sum behaviors that management should avoid:
0) I can ship faster than all of my team mates if I nitpick their CRs and get mine quickly approved by our easier reviews.
1) I can make sure my CR reviews are always faster if I am the nitpicky a-hole on every other CR
2) I can ship faster if I don't add as many tests as my peers. I'll promise to add them in a later CR and forget about it.
3) I can ship faster if I write software that is difficult for others to work on.
4) I can seem like a smarter engineer than everyone else by using jargon and writing difficult to understand code.
5) I can convince management to look at my X,Y,Z productivity metrics, while the team remains ignorant. (Code Review iterations is a dangerous example of this)
Big thing is to recognize signs of zero sum behavior, and investigate if it's being done intentionally or unintentionally. Even if its intentional, it may simply be a bad reaction to the surrounding incentive model of the organization.
I think about Eli Goldratt's The Goal all the time.
Paraphrasing: A team (system) is only as fast as its slowest member (task); to speed up the team, focus on making the bottle neck faster.
Said another way, Goldratt also explains how a process that outpaces the others works to slow down the system overall. Local optimization leads to gloal inoptimization.
Pretty basic queue theory stuff. This aspect is aka Theory of Constraints.
Anyhoo. I don't buy most "10x programmer" tales. I just wonder who's on the receiving end of such awesomeness. And at what cost.
Effective Zero Sum behaviors that management should avoid:
0) I can ship faster than all of my team mates if I nitpick their CRs and get mine quickly approved by our easier reviews.
1) I can make sure my CR reviews are always faster if I am the nitpicky a-hole on every other CR
2) I can ship faster if I don't add as many tests as my peers. I'll promise to add them in a later CR and forget about it.
3) I can ship faster if I write software that is difficult for others to work on.
4) I can seem like a smarter engineer than everyone else by using jargon and writing difficult to understand code.
5) I can convince management to look at my X,Y,Z productivity metrics, while the team remains ignorant. (Code Review iterations is a dangerous example of this)
Big thing is to recognize signs of zero sum behavior, and investigate if it's being done intentionally or unintentionally. Even if its intentional, it may simply be a bad reaction to the surrounding incentive model of the organization.