Why Great Engineering Orgs Thrive on "Normal" Engineers

I've never heard of this 10x thing but it reeks of "alpha male" exceptionalism that makes mediocre white boys feel powerful. Wherever these 10x people exist, I promise there are annoyed women and minorities having to take up the slack for them in every non-engineer aspect of their lives. The normal shit that's beneath them because they must dedicate all waking hours to the grind or the world will fall apart. Meanwhile normal people have to actually cook, do laundry, make appointments, raise children, etc. and catch flack for not being productive enough compared to the 10x guy who avoids showers and adult responsibilities.
- I've worked with three incredible developers who I'd consider 10x: people who can reliably build a solution quickly, or debug problems that go deep into the OS. One would fit your description, one is a mom who shuttles her kid to after school stuff, and the other is a really nice music nerd.
  Like the post states, some people are in the right place at the right time: they have the right background and temperament to do really well at their job. They don't need to be shitty people.
- I know like 3-4 people who I'd label 10x engineers and while all but one are male, they're all non-toxic both at work and outside of work. Huge part of being 10x is enabling the rest of the team to work faster as well. If you just shit out code 10x as fast but someone else needs to pick up the slack to fix your bullshit and you don't communicate at all because your work is sooo important, you're not a 10x engineer, you're an asshole. A true 10x engineer elevates everyone around them.
  
  Do they call themselves 10x?
- this was my introduction to "10x" engineers: https://youtu.be/kKAue9DiHc0

I'm so sick of this "moving fast" mindset. The result of which is my newsletter being full of security hole and hacked.
What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
Ah, really? Are you sure that's what matters?
- In the very first real programmer job that had, back in 1986, the IT department estimated that they had a 51 man-year backlog of development work. That would have translated to two or three calendar years of work. Probably more, considering how crappy estimates always are, and the always under-estimate.
  It turns out that this is pretty much the industry standard. Virtually ever place I worked for the next 35 years had a similar size of backlog. And that backlog isn't standing still, either. All you can hope is that 3 more years worth of new requests don't come in during the two years it takes to complete what you already have.
  Some of those new things are going to have a higher priority than stuff that's already in the backlog. The reality is that some item that's down at the low end of the list is going to get bumped down, again and again, and never get done. Or it's going to someday become an urgent priority that can't wait any more.
  So the pressure is always intense for the developers to go faster, faster, faster. And the business doesn't understand or care about good engineering practices, even though the shit hits the fan when a critical bug gets released to production. And God help you if that backlog of 51 man-years has grown to 70 after a year because of the technical debt you introduced trying to go faster.
  The fight to rein in scope is constant. At that first job, the head of the department told us, "to build Volkswagens, not Cadillacs". It was laughable, because they were struggling to keep up while building Skodas.
  You can't just add more programmers because the productive backbone of the development team is a group of programmers that have all been there for at least 5 years and they are domain experts. It's going take at least 5 years to bring new hires up to that level of knowledge.
  And that's all three sides of the project triangle: scope/quality, resources and time. You can't meaningfully add resources, scope's already stripped down to bare bones and the time is too long.
  And the truth is that every one of those projects in that 51 man-years backlog is important, even critical, to some aspect of the business. But the development process is unfathomable to muggles, so can't you just go faster? Can't you wring a bit more productivity out of those domain experts?
  
  And God help you if that backlog of 51 man-years has grown to 70 after a year because of the technical debt you introduced trying to go faster.
  The joke is, i had to explain the concept of "technical debt" to the "supercoder" that did most of the programming in my last company.
  He was a great guy otherwise tho.
- Moving fast doesn't have to mean poor workmanship.
  To make an analogy, if you want to be able to make a cup of coffee fast, you need to make sure that the coffee beans, the water, and the brewer are all near each other, that there is electricity and that the water is running. These are all things that enable you to move fast, but they don't decrease quality, if anything they increase quality because you aren't wasting time and effort tackling obstacles unrelated to brewing.
  Which is in fact the point of the article. That you should make sure you have a good development environment, with support systems and processes, so that you can work effectively even if your developers are not savants. Rather than trying to hire people who are good enough to do a decent job even in the worst environments.
- I'm bragging when I say this: A decade ago, I rewrote an indecipherable mess of code into an elegant and transparent procedure, nestled comfortably inside every sanity/insanity check I could think of for the situation. Today, that code (aside from an update for a vulnerable dependency) is still running just the way I wrote it.
  Releases should be fast and rare.

Because progress is for the most part iteration?

I feel like part of the problem is that management wants staff that can do a wide range of tasks when it ends up creating a staff that can't specialize in a small group of tasks.
I've seen plenty of times where people can operate well as a cog on a big machine, but fall apart when they have to work in roles that require a variety of skillsets. Larger engineering companies can typically create enough work for people to specialize in smaller tasks than smaller engineering companies.

Without reading the article, my guess would be because they give their engineers enough time to do their best work.

Implying engineers are normal

LIES! It's us unstable ones that carry EVERYTHING!

I won't read the article now, but
arguing that true productivity lies in team performance, not individual brilliance
this is bullshit, a categorical statement.
There are good processes and there are bad processes. Good processes are usually functional for people of (sensibly) different mindsets and mental conditions. Bad processes are usually "one size fits all" in one way or another.
There are things a team can't have, and there are things a talented individual can't have.
There's also experience that covers holes one can't plan for, yep.

The archetype of the 10x engineer is called "Brent"