I worked an early employee at a YC startup that was developing a hardware device and I think really ran into similar issues.
There were significant delays with shipping the device which meant that all the teams which had been built up to support its launch had _nothing_ to do for months. People in a "Customer Success" department with no customers. Developer evangelists with nothing to evangelize. Support departments twiddling their thumbs and the worst was the sales and marketing groups which devolved into a Lord of the Flies type environment where they tried latching onto any and every project they could just to justify their existence.
Timing really is everything.
So if you have enough traumatic brain damage to buy that line, stack ranking makes a ton of sense.
I didn't know how to respond to that.
The typical interaction between manager & engineer is that a manager tells an employee what to do, and the employee does it. From the manager's perspective, any employee that's reasonably competent will do: success is binary, either you did the assigned task satisfactorily or you didn't.
From the engineer's perspective, if you're good you considered a lot of alternative ways of solving the problem and finally settled on the best. It seems ridiculous that all employees could be interchangeable, because it's a pretty good bet that some engineers did not consider some of the alternative solutions you did. But remember that the whole reason the manager hired you was so that he didn't need to think about the details. All of those alternative solutions are outside of his conscious awareness; he's condensed his mental model of the problem to a binary "is this good enough to ship?", which frees up mental space for him to think about other stuff. Among those engineers that you think of as "not good enough", there are some who may not have thought of the brilliant solution that you came up with but still have code that is "good enough to ship" in the manager's estimation, and those are the irritating folks on your team who IYNSHO always produce shitty code but stay on the team because they have your manager's political favor. And then there are the folks who both you and your manager agree are too shitty to get the job done, and they're fired.
Who's right? Well, both of you, and neither of you. It's fairly likely that you're overestimating the quality requirements for the job, which is why a number of your shitty coworkers still have jobs. It's also fairly likely that your manager does not have complete visibility into all the long-term consequences of all the code being produced, which is why whole teams occasionally just catastrophically fail.
But it's worth remembering that every time you enter a transaction, you're having your work reduced to a pass/fail grade. It's the fundamental bargain you make when you take a job, and it also is the fundamental bargain you make when you sell a product (entrepreneurs are not exempt from this, and it's a major cause of startup failure among technical founders...including, quite possibly, mine). The advantage of producing better work is that it qualifies you for more different opportunities - which may or may not be relevant, depending on whether you take advantage of those opportunities.
This is true as an employee and as a contractor and as a business. The nice thing about transacting as one of the latter two is there is no pretention of the transaction being anything other than a binary one.
Now that you've brought it up, is a postmortem of your startup written up somewhere?
http://diffle-history.blogspot.com/
I'm still working on the 2nd (or 5th, or 11th, or ~50th, depending on how you count)...not exactly ready to declare it a failure, just, well, a whole lot of pivots.
In my experience most programming jobs don't really require deep domain expertise or share it by osmosis. Ideally a smart, dedicated person that gets a 40 hour a week crash course from experts in the field should get up to speed reasonably quickly.
In the absence of experts there exists a whole slew of technology that democratizes hard fields like game creation and machine learning. You can commit all sorts of sins and still end up with a well functioning product. Partly resting on technology developed as an enabler and partly resting on the sheer amount of available compute.
IMO people are far more easily replaced in terms of making an individual code contribution than they are as members of a team and it's the latter that is significantly more important. Good teams are multipliers for their members. Replacing a team member in a well functioning team is a super risky prospect. Yet we live in a world of frequent re-orgs, teams smooshed together haphazardly and overvaluing individual technical skill.
I don't see that changing anytime soon as it all sort of works and there is an endemic lack of interest.
I learned this lesson pretty early in my career when most senior engineer on the team left. I and everyone else freaked out because he was the only one on the team who fully understood how everything works. But you know who was not freaked out? My manager. And he was right, we did not even miss deadlines. In two month everything was back to normal with other people filling his shoes.
Obviously you can't replace Principal engineer with fresh grad and expect success but most of the work done is not that unique or hard.
That qualification at the end makes it false.
If I have to give someone 1 year to learn all of the minute details of the behavior of TCP across the various operating systems clients use, the behavior of packet re-ordering in LAG algorithms, convergence times of BGP, etc, then they are most definitely not interchangeable with someone who does know these things.
Any manager who thinks this way is incompetent and will impose massive opportunity costs on the company by not fighting for raises for existing good employees under the guise that they can be easily replaced.
Have you ever looked around the room and asked yourself "gee, why do we have so many coworkers on this project?" Or said "isn't it nuts that there are some weeks when I can measure my productive output in a handful of hours?"
The current vogue in management is cramming teams into an open floor office and micromanaging scrum points; these measures are introduced because they demoralize and _average_ output, thus introducing slack into the system. That's not a bug -- that's a feature! When someone important leaves the workers can be motivated or "motivated" to increase their output until the proper amount of slack is reintroduced from a hire.
"My experience differs significantly" might sound like "I can't pick up new technologies and work on them". What did you have in mind?
A lot of competent management practices seem counter-intuitive if you've never been exposed to them. Most managers I know have have never even read a book on the subject. Management is often the blind leading the blind. Most likely this kind of environment will scare away any good managers, so the cycle continues.
So, unfortunately, it shouldn't be surprising that these counter-productive practices continue.
That said, reports like this never cease to amaze me.
Microsoft were often cited. You'll note that their renaissance coincides with their elimination of stack ranking.
Which is funny because my experience at Uber was EXACTLY the same. 3 years ago one of the heads of their department emailed me and asked me to come in and give a talk to their managers as the team wasn't doing so well. After I did this, I asked the VP if they were hiring at my level (I was a director/senior manager at the time) and she said yes. When I came to interview it was clear that I was interviewing for the job of one of the people who were interviewing me. Everyone seemed to love me except for this person, who told me they don't hire managers and that I would have to report to him. He was very junior to me and seemed to only want to keep his title/piece of the kingdom. It was obvious I didn't want to be a part of that, so I declined the offer and not only was the person gone a few weeks later, they were gone from their next job a few months after that. There's some serious political stuff going on at Uber.
If by "the real problem" they meant "the root cause" then their theory does appear to fit the facts. I personally suspect it was "both" rather than "one caused the other" but have insufficient data to go beyond "suspect".
The response to other reports are standard. Whether it is a homosexual boss or a female boss, the company will seek to protect itself.
If you think that any of this is trivial, you are part of the problem.
It might be okay if all the talents that Uber hired could work together to build truly great software, but hell no, their management created this weird cut-throat culture by enforcing stack ranking with forced curve down to each team of first-line managers. It's hard to imagine that a team with fewer than 10 people had to name an engineer who "didn't meet expectation". Yet that was exactly what happened in Uber. They also doted out disproportional amount of bonus to a few top performers. Naturally, people's expectation was distorted, and chaos ensued.