This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way.
It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.
That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.
Which is not to say they're doing everything right.
> That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.
That doesn't really jive with my personal experience, which is that contributors really don't want the only path to career progress to be a transition to management. I saw this happen firsthand at a consulting company--the technical side was pushing for the split, not the current level of management.
Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.
You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.
Even if they don't transition to managing people, someone in an individual contributor role presumably needs to be growing in some way if they want to get raises. While someone doing something valuable even without growing will probably continue to get small raises anyway, it's not the ideal path.
And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.
People high on our technical track don't spend their days on code. The job of a Staff, Sr. Staff, or Principal engineer is about coordination, negotiation, and consensus-building across bureaucratic distances. Most only look at architecture diagrams. Some review code. Vanishingly few contribute. When they do, the contribution is about keeping their skills fresh and their understanding of the project grounded in reality. It's not not what they're really getting paid for.
It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.