I am glad this discussion is being brought to the fore. In my experience, far too many managers are clueless about what engineering actually means. They see it like warehouses or factories where the number of units shipped == output. But in engineering, number of PRs or commits or lines of code are meaningless. In fact, setting these output targets take away time from engineers in doing things such as meaningful design choices, system health investigations, cross-team situations.<p>I see software engineering more as a team sport than as an individual sport. In team sports, each individual sacrifices some metrics for the good of the team.<p>Here is my rant about how soccer teams would perform if they were evaluated like the McKinsey-style nonsense becoming pervasive in the tech industry: <a href="https://medium.com/@NTDF9/if-soccer-managers-did-performance-management-like-tech-companies-69c54b587386" rel="nofollow noreferrer">https://medium.com/@NTDF9/if-soccer-managers-did-performance...</a>
I lol'd at this quote from the original McKinsey article:<p>> For example, one company found that its most talented developers were spending excessive time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those highest-value developers to do what they do best: code.<p>How dare our senior dev leads spend time _designing_, we need hands on keyboards!!!
I was onboard with this until<p>> CEOs and CFOs are increasingly frustrated by [...] software engineering is too nuanced to measure, when sales teams have individual measurements and quotas to hit, as do recruitment teams in the number of positions to fill. The executive reasoning goes: if other groups can measure individual performance, it’s absurd that engineering cannot."<p>It's absurd to think that those other can be! THAT is the flaw!<p>Those measurements and quotas of sales/marketing/recruitment/etc are hugely corrupting! They lead to selling features that don't exist and cannot exist. They lead to bad hires. This same incorrect thinking leads directly to Teaching-to-the-test. To bureaucratic grant proposal systems. And most likely tons more that I just don't know about. Measuring the wrong thing is pervasive.<p>That the article thinks other fields can be measured without corruption totally undermines the entire article. This is exactly why McKinsey are stupid enough to think programmers can be measured: because they are not programmers. Exactly like how politicians think they can measure teachers: they are not teachers.
Developer productivity is fundamentally unoperationalizable for all meaningful ways. The desire for which is a foolish consistency ie: the hobgoblin of little minds.<p>Every one of the listed decisions can be made effectively without an operationalization[1][2] of developer productivity and the sooner a playbook of methods takes over, the better.<p>1. <a href="https://en.wikipedia.org/wiki/Operationalization" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Operationalization</a><p>2. Campbell,Norman Robert. Physics The Elements 1920 <a href="https://archive.org/details/physicstheelemen029733mbp" rel="nofollow noreferrer">https://archive.org/details/physicstheelemen029733mbp</a>
My company uses scrum to try to track engineering output. My boss looks at metrics like line counts. It is extremely stressful to be on a team of people who are all worried about losing their jobs and will accidentally (?) commit your changes to their MR. It's extremely stressful to spend all day doing research tracking down a weird issue in prod, deploying a hotfix finally, and realizing that all of that effort, which did not go towards anything you were supposed to be working on that sprint, but was nonetheless necessary, resulted in a one line change. 8 hours of your life, feeling highly stressed, maybe skipping lunch, results in fixing one typo somewhere. You think about how you'll get a bad performance review despite working hard.<p>I wish I was on a team of engineers who just did their work and didn't worry about gaming the system. I wish the engineers I worked with had enough time to be careful that such small mistakes, which are difficult to track down after the fact, did not make it to prod to cause our customers grief. I wish that management was competent enough to know that adding a missing quotation mark to the repo isn't just adding a missing quotation mark to the repo.