I’m going to play the devil’s advocate because I have seen examples to the contrary many times prior.
I’ve had the pleasure of going to a school for undergrad where the vast majority of our assignment and scores thereof were conferred via group projects; and being a school, teams were formed on an ad-hoc self selecting bases (initially via familiarity, and as the semesters wore on, performance of different individuals would start to be recognized). Students of similar skill level would then congregate, as known A performers loathe to partner with B and C performers, likewise B would loathe to partner with C, and so it goes.
Multiply this by 3 semesters over 5 years and it should be rather obvious to see where this story is going to end. Groups of C performers, in general, do not perform as well as a group of B’s, and even less so compared to A’s. However, all three groups were formed under the exact same self-organization with the same mission statement (namely, the project specs).
What the author has detailed is an efficient execution of a matching market, where a group of A-performers (congrats on being able to attract them!) have converged to work at the same company. When you have a group of A-performers, their output is going to simply be of a higher quality than a group of B or C-performers no matter what type of organizational structure you impose on them (within reason, of course). This doesn’t usually happen (most companies have a mix of A/B/C performers), so when it does happen it’s extra surprising, but likely not for the organizational reasons that seems obvious. Likely it’s due to more nuanced reasons (the existing employees, company’s project/industry, location, “culture”, etc.) that allowed the A-performers to all converge at the same work environment.
To the contrary, over the years, we have had several B and C-performers. For this reason and others, we adopted pair-programming and frequent pair switching to help train them. If the group organized to not train those, we wouldn’t be really improving the team and code-base for long term productivity. The under-performers would make messes and bad decisions that would slow the whole group over time, and they would never improve.
With pairing, we have trained and motivated our lower performers that were willing to improve. Those that had no interest in improving got tired of the constant impedance mismatch and left. At this point, we have a majority of A performers, so we take on several new graduates and co-ops who are willing to go the distance to improve. We cultivate them into A performers with thousands of hours of pairing mixed with trust and respect.
I too have had bad luck with undergrad CS school projects, especially since at the time I was a C-performer. School projects mix a fairly homogeneous group of immature students with a subtly different goal: “pick a few other people, your work will be compared to everyone else’s”. Self-selected grouping by skill makes sense, it’s effectively a competition. One recommended alterations for group projects is “your grade is the average grade of all the group projects”. Suddenly, you won’t see those teams separating by skill. Instead students will organize with a team mix as even as possible, with cross-communication (and likely rotation) happening to ensure high quality across all the projects. Bam, now you’ve got my office ;)
I’m going to play the devil’s advocate because I have seen examples to the contrary many times prior.
I’ve had the pleasure of going to a school for undergrad where the vast majority of our assignment and scores thereof were conferred via group projects; and being a school, teams were formed on an ad-hoc self selecting bases (initially via familiarity, and as the semesters wore on, performance of different individuals would start to be recognized). Students of similar skill level would then congregate, as known A performers loathe to partner with B and C performers, likewise B would loathe to partner with C, and so it goes.
Multiply this by 3 semesters over 5 years and it should be rather obvious to see where this story is going to end. Groups of C performers, in general, do not perform as well as a group of B’s, and even less so compared to A’s. However, all three groups were formed under the exact same self-organization with the same mission statement (namely, the project specs).
What the author has detailed is an efficient execution of a matching market, where a group of A-performers (congrats on being able to attract them!) have converged to work at the same company. When you have a group of A-performers, their output is going to simply be of a higher quality than a group of B or C-performers no matter what type of organizational structure you impose on them (within reason, of course). This doesn’t usually happen (most companies have a mix of A/B/C performers), so when it does happen it’s extra surprising, but likely not for the organizational reasons that seems obvious. Likely it’s due to more nuanced reasons (the existing employees, company’s project/industry, location, “culture”, etc.) that allowed the A-performers to all converge at the same work environment.
To the contrary, over the years, we have had several B and C-performers. For this reason and others, we adopted pair-programming and frequent pair switching to help train them. If the group organized to not train those, we wouldn’t be really improving the team and code-base for long term productivity. The under-performers would make messes and bad decisions that would slow the whole group over time, and they would never improve.
With pairing, we have trained and motivated our lower performers that were willing to improve. Those that had no interest in improving got tired of the constant impedance mismatch and left. At this point, we have a majority of A performers, so we take on several new graduates and co-ops who are willing to go the distance to improve. We cultivate them into A performers with thousands of hours of pairing mixed with trust and respect.
I too have had bad luck with undergrad CS school projects, especially since at the time I was a C-performer. School projects mix a fairly homogeneous group of immature students with a subtly different goal: “pick a few other people, your work will be compared to everyone else’s”. Self-selected grouping by skill makes sense, it’s effectively a competition. One recommended alterations for group projects is “your grade is the average grade of all the group projects”. Suddenly, you won’t see those teams separating by skill. Instead students will organize with a team mix as even as possible, with cross-communication (and likely rotation) happening to ensure high quality across all the projects. Bam, now you’ve got my office ;)