That's just not true, the main reason being that if you're not programming any more, how can you define a modern technical architecture? If you don't know the precise technical limitations, how can you negotiate functional specifications?
Engineering is Engineering, whether it's IT systems or bridges
Knowing one's limitations is key - I certainly won't get in the way of implementers. But functional requirements do drive some architectural decisions and spotting them upstream helps, for example once the conceptual data model and typical query usage are defined, one can decide whether the contractor one sends a purchase order for needs to grok graph databases or relational ones.
I do advocate a high-low mix with fewer people and a higher proportion of the higher tier, but the purchasing department loves low unit prices and has decision over them. Well, at least we have the developers co-located with us in the same office and no longer work with offshore Indians through two layers of intermediaries... Progress !
I can manage large business requirements, I write functional specifications and negotiate them with users, I plan technical architecture... And then I'm happy enough with programmers who need hand-holding at every step - anyway my telco employer has long stopped having budget enough to pay contractors who understand our business.
Pure programmers may be short sighted but they provide the value some of the market needs, for people such as me who are decent analysts and exceptionally bad programmers - learning the latest Javascript framework is a dirty job but somebody's got to do it !