That said, at every place I've worked you could get a starting point idea of who the top devs were by looking at overall code commits. This Tim sensei situation may be more common than I think, but I've never run into it.
This works for Junior through Senior level roles, but it falls apart quickly when you have Staff+ roles in your company. Engineers in those roles still code, but they write a fraction of what they used to and that is by design—you want these people engineering entire initiatives, integrations, and migrations. This kind of work is essential and should be done by your top devs, but it will lead to many fewer commits than you get out of people who are working on single features.
With a few exceptions for projects with a high degree of source-level complexity, a Staff+ engineer who's committing as much as your Senior engineers is probably either misleveled or misused.
Because they were leaning more into a product archetype - which it turns out they were very suited to.
We’re building the things that other people use to deliver features better and faster.
Basically, treating (non-)productivity like bot detection, lol.
But then one middle manager sets a target. His peers, not to be outdone, set more ambitious targets. And their underlings follow up aggressively with whomever is below target. For a few months there was an implicit "no vacations" policy in much of the company, until they updated the attendance dashboard to account for PTO. And now an engineer's position in the stack rank is presumed to be her position in the PR count rank barring very strong evidence to the contrary.
The approach you outline is probably optimal, but I don't think middle management as a culture would be capable of pulling it off. You give them a KPI in a dashboard, they're going to compete on it, in a very open and simple way. Metrics are hard to argue with, and nuance requires constant vigilance to maintain.
Yea, in the current place I work at we do not measure coding performance metrics, but if you look at the top commiters to the repo — by number of commits — you will see all of the people who bring the most value to the company. Even at staff eng the best engineers are still the ones who crank out code, albeit maybe as not as much as a senior engineer. Staff engineers who only commit 1 a month are usually the ones who don’t bring value to the company, especially given their high pay.
When I think of highly functioning staff engineers Im thinking of people like Jeff Dean and Mitchell Hashimoto. Similarly at companies I have been at, even the highest level principal super staff++ engineers still code. They do the high level strategy and design, but they are still writing PRs at least every week or two. If you are spending 100% of your time on politics and architecture as a staff eng I think that shows a somewhat dysfunctional organization.
Maybe in a business where the cost of iteration is very high, it makes sense to do this. But in a good business you should not be doing architecture reviews and writing proposals, you should be doing refactoring and creating prototypes, respectively.
Solving business problems using bespoke software solutions surely is the absolute most expensive option on the table, and should be aggressively avoided unless no other options are available, AND the problem is in a domain which is a core competency and market differentiator for your business.
The process of figuring out what your company needs, and how best to solve that problem long term, is dramatically more valuable to a business than software/technology implementation.
Architecture reviews ensure that there is some strategy on how things are being solved at an organisational level.
Related to Goodhart's law: "When a measure becomes a target, it ceases to be a good measure".
I'm wondering if this is only true if the act of measurement is transparent (so that the people being measured can game them). If the act is opaque enough such that the form of the metric cannot easily be guessed SEO-style, then maybe wave function collapse can still be avoided?