I do not understand the gut desire to obfuscate individual accountability in an industry that is so inherently meritocratic—within a capitalist society at that. The highest performers, that is, the people who will dictate culture meaningfully, are inversely incentivized toward such dissolution of transparency. Certainly management is bad at judging productivity because it insists on reducing the qualitative to quantitative. However, as an industry outsider, I will nonetheless maintain that there must remain some means of macroscopic judgement.
I feel you are on the right track considering pair programming and not allowing individuals to pull tickets.
But at the same time, even these are limited solutions when much more effective approaches are available, such as cross-functional teams who create software, find bugs and solve them together. In that environment, of perhaps 8-14 people, the software creation process is informed by identifying bugs and solving them in a virtuous cycle. In many cases it may not be necessary to record much info if any for small bugs or feature improvements before release.
There are many examples of this approach from team-based continuous improvement practices at companies like Toyota, Buurtzorg or Favi.
I do not understand the gut desire to obfuscate individual accountability in an industry that is so inherently meritocratic—within a capitalist society at that. The highest performers, that is, the people who will dictate culture meaningfully, are inversely incentivized toward such dissolution of transparency. Certainly management is bad at judging productivity because it insists on reducing the qualitative to quantitative. However, as an industry outsider, I will nonetheless maintain that there must remain some means of macroscopic judgement.
Meritocratic industry? You truly have to be an outsider.
Fully capable of being such. Sometimes you need an outside mirror to know what you can be. The answer is not to run from merit.
Why would individual effort be a bad thing? Why is this something you’d like to “hide”, for a lack of a better word?
I feel you are on the right track considering pair programming and not allowing individuals to pull tickets.
But at the same time, even these are limited solutions when much more effective approaches are available, such as cross-functional teams who create software, find bugs and solve them together. In that environment, of perhaps 8-14 people, the software creation process is informed by identifying bugs and solving them in a virtuous cycle. In many cases it may not be necessary to record much info if any for small bugs or feature improvements before release.
There are many examples of this approach from team-based continuous improvement practices at companies like Toyota, Buurtzorg or Favi.