“Normal” engineers are the key to great teams

Let's take a made up example of a structural engineer designing a building. As another comment mentioned, in theory the design space here is enormous. Just the concrete mix can be endlessly optimized. But here there's a large monetary cost tradeoff that's obvious to everyone involved. Say an overenthusiastic junior proposes attempting to rediscover ancient Roman concrete mix for this project. Everyone from the other engineers to management can call that out as absurd.

In theory you can make the building out of anything. But in practice the economics of producing real world components only allows for a few choices in each stage of the design.

Meanwhile, software components are essentially free, especially if they're open source. Just clone the repo, hook up the code and you're done, right? So surprisingly often, the overenthusiastic junior can convince the whole company to build the new feature with some obscure framework that'll be unsupported in a few years. And no one can reliably call them out, because there's no easy, objective way to measure something like tech debt. (Another compounding problem is the rapid growth of the software field. Juniors are minted faster than they can be trained.)

To make the software example more concrete: there's an internal config language "blub" in one of the FAANGs that someone designed in two months. It looked simple, gained a lot of adoption quickly. Fast forward 5 years, and it turns out using blub was a big mistake. It scales terribly, the semantics were badly thought out and cause subtle bugs everywhere. But here's the kicker: there are now millions of lines of blub. Over the next decade, the company makes several very expensive attempts to replace blub and fails. Blub continues to underpin their production infra to this day.

So to sum up, I think maybe the core issue is not so much "3d space versus hyperbolic space". If you view the space as the tree of decisions you need to make to reach the goal, all engineers are working in hyperbolic space.

However, when designing real world things, economics rapidly culls the design tree. Buying materials requires cash up front. But in software it's often the opposite: you get the libraries "for free", and the unmeasurable tech debt accrues over time.

The board decided to promote these people who negotiated a 4-days week; after all the team had never missed a deadline, and gradually I was given more and more tacit responsibilities without explicit status recognition. This creates a double-bind situation for both sides. While I could never be satisfied because of this lack of trust, you have to understand why they approached me with suspicion while being dependent on me.

A 10x engineer (or any Nx engineer with N > 1) has to interface with the rest of the team and this necessarily implies more work. In my case, resentment grew because of the increased workload this led to for them, and my colleagues felt more impacted by this than by deadlines being not met. As for management, since deadlines were already met, they felt more compelled to listen to the negative feedback they gathered about me and develop suspicion. And yet, they had to rely on me for any impromptu problem they had.

What's this article is discussing is not engineers with bouts of outstanding performance but engineers with that symbolical status. It's attacking the myth, and the attribution of that label, not a reality with measurable outcomes. The article doubts that such a measure exists, however the departure of an employee can have destabilizing effects on an organization. The delta won't exactly measure this employee's worth, but an organization can put itself in such a configuration that it will unknowingly rely on a few key individuals for its financial strategy and use the added value these people bring against its competitors, to win investors attracted by this differential in efficiency or proceed to acqui-hires. This leads the company to bind itself to commitments which pushes it near to a dangerous threshold.

Once crossed, when one of the cheap keystone employees leaves, this excess of work can cascade to other keystone employees, and cause more resignations, and the company won't be able to make up for it because its finances are already engaged elsewhere.

I too have been nothing short of perpetually shocked at how dysfunctional a large part of the software industry is. This is why I'm never able to take the "engineering" moniker seriously when people talk about programming.

The hiring process is so maddening and I'm glad you said that.

I get that resume scanning and what not is fully automated and makes no allusion to being a useful nor functioning process, but I'm perpetually amazed as I submit resumes (where I meet or exceed every "requirement") to companies I know are not well-functioning organizations only to be rewarded with an automated rejection email minutes later.