I don't agree with almost any of the assertions and implied points here except the very top level one - obviously the code belongs to the company. Everything else seems weird to me - especially the advice to let managers make technical debt decisions and to let anyone refactor the code even if it is bad because then they will understand that (bad!?) code better now.
The steelman feels weak or misguided to me. Many companies (not all!) explicitly want engineers to "own" products and codebase (it's on almost every job description I see or write) and to me that means keeping the deep and detailed knowledge of all the nuances that drive a project. Managers often can't do that and usually don't want to (and it's a waste of their breadth if they have to know that much detail) - thinking abstractly about projects is important for strategy and it's hard to do that while keeping all the weeds in your head.
I agree the project engineers shouldn't (and can't for the other side of the same reasons above) own the company strategy - tech leadership should help set the proverbial dial between speed today and speed long term and product leadership should set the various facets of long term product strategy. Engineering should own the codebase so that it fits into those goals and doing that correctly, planning ahead so you can be robust in the static places and nimble in the dynamic/growth places is exactly what ownership of a codebase entails.
The steelman feels weak or misguided to me. Many companies (not all!) explicitly want engineers to "own" products and codebase (it's on almost every job description I see or write) and to me that means keeping the deep and detailed knowledge of all the nuances that drive a project. Managers often can't do that and usually don't want to (and it's a waste of their breadth if they have to know that much detail) - thinking abstractly about projects is important for strategy and it's hard to do that while keeping all the weeds in your head.
I agree the project engineers shouldn't (and can't for the other side of the same reasons above) own the company strategy - tech leadership should help set the proverbial dial between speed today and speed long term and product leadership should set the various facets of long term product strategy. Engineering should own the codebase so that it fits into those goals and doing that correctly, planning ahead so you can be robust in the static places and nimble in the dynamic/growth places is exactly what ownership of a codebase entails.