Many companies must build out rigorous standards, and checks and balances in order to deal with regression to the mean.
If what you're saying is true you're multiple standard deviations above the normal engineer, and scaling you is non-trivial. Bob martin has said the population of coders doubles every 5 yrs meaning at any given time 1/2 of the engineers have less than 5 years experience. When you need something that would take 1000 of you, which might not even exist on the planet, they instead have to build a system that takes 10k of those 5yr and less engineers -- and have the highest quality outliers leveraged though standards, automation, building engineering culture etc.
I get that a lot. It's absurdly easy to verify (I point to all my work), but folks would rather sling mud, than take a peek.
Doesn't matter. I'm not looking for work anymore.
In my time, I have worked with many people that make me look like a piker. I suspect they get chased out, too.
It really doesn't matter to me if it's true about you or not, we can still discuss the issue of designing for talent several standard deviations above the mean vs one that falls within, say, [0-1] std deviation above the mean.
And I feel you on process. I got involved in process because I wanted to quickly solve user problems, and then keep on solving user problems. But so much of the process-industrial complex is not focused on that. E.g., the SAFe® process is the effective opposite of what early Agile pioneers were aiming at. Its major function is to give managers and executives a sense of control almost without regard to how achievable that is or what it costs in terms of productivity and lost opportunity.
In perticular, you're not working in the same semantic framework as GP, who was talking about "It+1", "It+2" and so on
It has been my experience that actually delivering, working, high-Quality, supported, documented software (regardless of what the software does), within a reasonable period of time, is beyond the capabilities of many corporations.
I suspect that some folks make money by convincing others to invest, then hightailing it, before the chickens come home to roost, as opposed to actually selling a finished and supported product to end-users. In that case, looking like a "shipper," is much more important than actually being one.
But that's just one "It" on the continuum. It could also be grant-writing, selling, managing, singing, shredding guitar, racing minibikes, whatever.
In any given case, there's always some threshold of what an "effective It" is. It may not be a clear-cut line. For example, research is very "fuzzy," and a researcher that can do "It," may be excellent at failure, because their job is to poke holes in theories.
In fact, if the company is all about getting A-round funding, then folding up the card tables, and moving on, someone that "looks like a shipper" could be an effective "It."
I've been doing "It" (shipping software -which is quite different from "writing" software) for my entire adult life.
Basically, if you want to actually ship a superb-Quality native iOS/iPadOS/WatchOS/MacOS app, in an astonishingly short period of time, I'm a good person to talk to.
What I have learned, is that very few people seem to want to actually ship software. Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). As it comes time to start preparing for it to go out the door, all kinds of roadblocks start piling up. It's crazy.
I was "frozen out" of the industry, because of my age, which really pissed me off, but that has turned out to be a great thing. It's been a real joy, writing my own stuff. Out of necessity, I have to keep the scope humble, but that's fine.