> Do you think “engineering” is only the physical labor? Do aircraft engineers and building engineers actually do the construction work?

No, but software is inherently different because you can leverage existing software to create more software. Every airplane has to be created individually, but software that already exists can be extended or reused by just calling functions or in the worst case copy/pasting.

> The actual certified workers (mid level developers). This is the level that the completely head down people are. No matter how good they become at being a hands on plumber , there is a hard ceiling they are going to hit at this level.

Yes, with hardware this can be the case as there is a small number of ways to build something. With software there is no ceiling, and the proof here is AI. We might soon see general intelligence that just codes anything you want. This means software can be designed to automate virtually anything in anyway shape or form, but it requires more and more expertise.

> I did my high level designs before they came on to the project. Was my design work, figuring out priorities, risks, making sure it met the clients needs, discussing trade offs, etc not “engineering”?

I agree what you're outlining is how the industry works. Perhaps the core of the issue here is how software engineering was modeled after other kinds of engineering with physical limitations. Software is closer to mathematics (arguably it's just mathematics). You can of course still design and plan and delegate, but once the role starts dealing with the high level planning, scheduling, managing, etc., there is less of a requirement for the technical details.

I've worked with architects that didn't know the specifics of a language or design patterns, not because they're bad at engineering but because they had no more time to spend on those details. These details are crucial for good software that is reliable, robust, extensible, etc. Junior and even mid level engineers also don't know these details. Only someone that has been hands on for a long time within a domain can hone these skills, but I have seen so many good engineers become senior or tech leads and then forget these details only to then create software that needs constant fixing and eventually rewriting.

I'm a senior myself and have no choice but to engage in these activities of planning, scheduling, etc., when I can clearly see they do not require technical expertise. You just need some basic general knowledge, and they just are time consuming. My time would be better spent writing advanced code that mid-level and junior level can then expand on (which has happened before with pretty good success, accelerating development and eliminating huge categories of bugs). Instead I have to resort to mediocre solutions that can be delegated. As a result I can see all kinds of problems accumulating with the codebase. It's also really hard to convince the leadership to invest in "high level" engineering because they think that you create more impact by managing an army of low to mid-level engineers instead of leveraging properly written software. I'm convinced that it does add value in the long term, it's just a hard sell. Ultimately I guess it comes down to the type of org and the business needs, which often does not include writing software that will not break. Most companies can afford to write bad software if it means they get to scale by adding more people.