I work outside tech, but can you please explain how number of X would be a good measure at all? What would be the justification for counting anything as a straight number as a measure in a creative field?
With coding in practice the high performers who deliver business value are often (but not always) the same people writing a lot of code; low performers might only make a couple PRs per month while a high performer did a couple per day.
The problem is that is more of a proxy outcome: it's also easily possible for a low performer to shovel out several negative-value PRs per day and for someone who does only a couple small PRs per month to be doing something difficult that delivers enormous value (especially if those few changes are like updating an ML model or finding key performance optimization opportunities).
There's a flaw with equating this to # of commits or lines of code. That flaw is - the amount of revenue increases with the number of logos produced but the amount of revenue does NOT increase with the # of commits or number of lines produced.
But there is no correlation to revenue potential between 99 and 100 commits. And most companies are not stuck at the first commit.
> Hard problems and low output happen situationally, generally not for quarters and years on end.
Absolutely untrue. The hardest problems I have solved required me to build observability over 2 quarters, write RFCs and get buy-in from other engineers. None of these contribute to commits.
And you were able to do this without writing a line of code and committing it?
Yes. I personally did not commit a single line because I had to influence other engineers to do apply said commits in their own repositories.
I had 0 commits for 6 months.
(Two simple examples: (1) how do you measure the productivity of a lead developer who spends much of his time mentoring, pairing, and helping the team deliver working code? (2) Is a developer who commits many small PR's "worth more" to the company than a developer who commits fewer, larger PR's?)
The reality is that when I look at who was strong and who wasn't there's a pretty strong correlation between people writing more code and also their business impact being larger. Many smaller tasks do go "X lines of new code are needed to fix a problem", and the person who delivered on 10 tasks did write 10x lines compared to the person who did one task, with all tasks size, difficulty and business value held constant.
There's obviously tons of noise in this including incredibly far outliers of the guy who writes zero lines but whose knowledge is a lynchpin, and the guy who writes 5k lines of negative value garbage code. And when it becomes a known measure it surely does create very perverse incentives, etc, but companies end up using it as a proxy metric because there is literally no other objective measure of code quality or business impact for engineers available: the sole two things to measure SWEs on is lines of code and feelings.
And you have hit the nail on the head. The problem is that businesses have to rely on proxies because there is NO metric to quantify this creative work.
The best thing for businesses is to first define what the right outcomes are: they certainly aren't lines of code, stack ranking, number of commits etc.
But it could be features, bug fixes, investigation of systems etc - you know, actual work engineers do.
Once the business identifies this, all a business needs to do is hire skilled managers who understand that proxies are not outcomes. The proxies, rules built on those proxies, and firing people on these proxies is literally the stupidest thing to do.
Like, it is literally costing actual $$ on the business that has too many managers who are using simplist metrics. This cost is in terms of time. Cost = (number of days to hire + number of days to onboard + number of days wasted on BS metrics + number of days management spent on measuring and stack ranking on BS metrics + number of days to fire + number of days to backfill the role + number of days to get them back up to the skill up to the last engineer's level)
Find these skilled managers who understand this cost is not worth any BS metrics, hire these managers. That's it.
You answered your own question. Management doesn't want to view engineering as a "creative field". In their ideal world, they want it to work like an assembly line. And for decades they've attempted to quantify it like an assembly line. But as of 2023, management has never been more wrong.
A good question is, "Why does management even desire quantification?" The answer to this is rather simple and unbelievable to most engineers toiling so hard.
The answer is - management (of all levels) is lazy and unskilled. They want to demonstrate to their bosses that they are running an efficient ship. They quantify it with # of commits or other such proxies. This gets them their own promotions. They don't care if the company survives or if their reports are working on the right things or if engineering challenges differ from one project to another. The most important thing for all managers is - their own promotion.
But just counting them is a dumb way to judge productivity, and every programmer hates it.
The way to become a manager at a tech company is to be good at programming for a long time, an extremely specialized skill set that has nothing to do with management.