He argues that “interdependencies and nuances of individual work are too complex to be measured by an outside observer,” concluding that the only good way to do it is to measure it at the team level—“does this team consistently produce useful software on a timescale of weeks to months?”
I agree; what other people do can have a strong impact on your productivity, and what you do can have a strong impact on their productivity. Probably the worst case is a policy where you fire the least performing member of each team, because that directly incentivizes doing things that slow down others—like, forget that anyone working in such environment would ever document anything in an actually useful way.
Makes me wonder… did any company try to internally implement “group selection”? I mean some policy like: keep the best teams intact (even if some of their members are low-performing), and fire the worst teams en masse (including their high-performing members)? Assuming that the teams work on independent products, without the opportunity to sabotage each other. I wonder what teams would survive such selection...
Or perhaps a more flexible version of the above, where the high-performing teams would be allowed to fire some of their members, if the majority of team members vote (anonymously?) for that. If the team is aware that next year they will be judged by the group performance again, they have an incentive to fire an obvious slacker, but wouldn’t fire a person who may seem replaceable to the management, but the team perceives them as important for the group dynamic. That would allow the team to have people specialized on doing things that seem useful to fellow developers but unimpressive to the management. Also, the team would have to approve a new hire. (New hires are necessary, because the existing team members sometimes leave the company on their own.)
On the other hand, when the low-performing teams are disbanded, their members could get a second chance, by receiving an invitation into a surviving team, or being randomly mixed into new teams. Only if your team is disbanded twice in a row, and no existing team wants you to join them, then you get fired.
(Perhaps in a sufficiently large company, the successful teams should be allowed to grow and eventually split into two teams, by their own internal decision. I say “sufficiently large”, so that splitting the team will not feel like creating a competitor that may get my half of the team fired in turn. Like, if the bottom 10% teams are disbanded each year, and only the top 30% are allowed to split, that might make them feel sufficiently safe about the outcome. And maybe there could be some encouragement to splitting as opposed to playing it safe. For example, a certain fraction of company profits could be distributed as a bonus to members of the teams created by splitting during the following three years, assuming they don’t fall to the lowest 10% and get disbanded. -- Would need to think more carefully about potential perverse incentives this might create.)
I feel like this might prevent some types of careers like people who make the rest of the team suffer, but the management likes them, attributes the successes to them and the failures to other team members; or people who join as experts, introduce some random changes that seem like huge improvements to the management, and then leave before the project falls apart, being introduced to the new company as the experts who saved the previous company.
Also, it seems to me that companies often do the oppposite of this strategy—successful teams complete their projects, and get disbanded as a consequence. No matter how well the employees cooperated with each other, they get randomly assigned to either the remaining or new projects, and the successful team dynamic is just thrown away. (Sometimes this makes the members of the formerly successful team quit, because they just lost something that kept them working there. Hey, if you are going to have a new project and new colleagues anyway, why not also try a new company that offers you a higher salary?) It is the teams failing to complete their projects that persist.
I agree; what other people do can have a strong impact on your productivity, and what you do can have a strong impact on their productivity. Probably the worst case is a policy where you fire the least performing member of each team, because that directly incentivizes doing things that slow down others—like, forget that anyone working in such environment would ever document anything in an actually useful way.
Makes me wonder… did any company try to internally implement “group selection”? I mean some policy like: keep the best teams intact (even if some of their members are low-performing), and fire the worst teams en masse (including their high-performing members)? Assuming that the teams work on independent products, without the opportunity to sabotage each other. I wonder what teams would survive such selection...
Or perhaps a more flexible version of the above, where the high-performing teams would be allowed to fire some of their members, if the majority of team members vote (anonymously?) for that. If the team is aware that next year they will be judged by the group performance again, they have an incentive to fire an obvious slacker, but wouldn’t fire a person who may seem replaceable to the management, but the team perceives them as important for the group dynamic. That would allow the team to have people specialized on doing things that seem useful to fellow developers but unimpressive to the management. Also, the team would have to approve a new hire. (New hires are necessary, because the existing team members sometimes leave the company on their own.)
On the other hand, when the low-performing teams are disbanded, their members could get a second chance, by receiving an invitation into a surviving team, or being randomly mixed into new teams. Only if your team is disbanded twice in a row, and no existing team wants you to join them, then you get fired.
(Perhaps in a sufficiently large company, the successful teams should be allowed to grow and eventually split into two teams, by their own internal decision. I say “sufficiently large”, so that splitting the team will not feel like creating a competitor that may get my half of the team fired in turn. Like, if the bottom 10% teams are disbanded each year, and only the top 30% are allowed to split, that might make them feel sufficiently safe about the outcome. And maybe there could be some encouragement to splitting as opposed to playing it safe. For example, a certain fraction of company profits could be distributed as a bonus to members of the teams created by splitting during the following three years, assuming they don’t fall to the lowest 10% and get disbanded. -- Would need to think more carefully about potential perverse incentives this might create.)
I feel like this might prevent some types of careers like people who make the rest of the team suffer, but the management likes them, attributes the successes to them and the failures to other team members; or people who join as experts, introduce some random changes that seem like huge improvements to the management, and then leave before the project falls apart, being introduced to the new company as the experts who saved the previous company.
Also, it seems to me that companies often do the oppposite of this strategy—successful teams complete their projects, and get disbanded as a consequence. No matter how well the employees cooperated with each other, they get randomly assigned to either the remaining or new projects, and the successful team dynamic is just thrown away. (Sometimes this makes the members of the formerly successful team quit, because they just lost something that kept them working there. Hey, if you are going to have a new project and new colleagues anyway, why not also try a new company that offers you a higher salary?) It is the teams failing to complete their projects that persist.