Which American companies do this?
You get silliness from supposed "engineers" who will inflate the points for stories they work on and downplay points for stories others work on. It's pathetic.
It works more generally though ... if management sets a metric, people will try to game it. On the flip side, you can't just have abstract 'quality' or 'customer satisfaction' because it is hard to know if you are really improving. I've never seen this solved once your scale gets past the small-group-of-people-with-a-shared-dream.
Perhaps people are so checked out that they don't care if the policies make any sense at all, as long as they get their paychecks on time.
At least from a few places I've been recently, "productivity" is viewed as the number of PRs you push through. QA of any sort is viewed as a waste of time, and it's far better to just push a PR today then take an extra day sanity check your work. On top of this user facing, demo-able, code is much more important than any back-end or infra work. This means the priority is rapidly releasing 90% of the way done products/features and moving on to the next thing.
Heck if there's a small bug in the code you just shipped (and of course releases are nightly because that's how you show that you're really moving) all the better since it means you get another easy PR when someone else discovers it.
19th century: the cobra effect. https://en.wikipedia.org/wiki/Perverse_incentive
Source: I've sat in on meetings where engineers were ranked, with # of commits being a key metric. That experience taught me the importance of making lots of small commits, more than any readability concerns ever could :)
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.
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.
Then again, Google is best thought of as a collection of semi-independent companies loosely bound by culture. Individual managers have a lot of leeway in how they operate, and VPs and Directors have tons of control on how they run their organization, including measuring performance. There are good teams and there are not so good ones.