The real problem in Uber's engineering orgs is that Uber hired too many people for too few real projects. From what I learned from my friends in Uber, many teams had largely overlapping responsibilities, and therefore created bogus projects to justify their existence. Their standard MO is picking a missing feature in a service, and then creating a new system that implemented that feature.
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.
This is a really interesting observation and something I think doesn't factor into most people's calculus of company culture and execution.
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.
I have literally never seen stack ranking mentioned in any context but horror stories and toxic company culture. What on earth possesses people to keep using it?
Most companies operate on the myth that the people responsible for doing work are interchangeable cogs that can be eliminated and replaced by a new doer with little to no impact to how the company functions.
So if you have enough traumatic brain damage to buy that line, stack ranking makes a ton of sense.
I had this exact same conversation with a manager who seemed suprised when I told him people are not interchangeable cogs. He said that some people may be quicker at a particular technology / domain / whatever, or quicker to ramp up, or do slightly better work, but smart engineers can and do learn anything needed and do work that's good enough after a ramp-up that's short enough. Beyond that, he says, there are minor differences he doesn't worry about as a manager.
This is largely a natural difference in perspective.
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.
> But it's worth remembering that every time you enter a transaction, you're having your work reduced to a pass/fail grade.
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.
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.
It's sort of true but a very one-dimensional view on an individuals contributions which is a bit worrying coming from a people manager. I think its funny people go around lionizing individual technical skill and at the same time insist that people are interchangeable.
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.
Outside of truly unique skills, it's basically true - engineers are interchangeable with sufficient time to ramp up.
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.
>Outside of truly unique skills, it's basically true - engineers are interchangeable with sufficient time to ramp up.
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.
Everything's a matter of degree. So maybe it takes longer or shorter depending on how big the shoes are. But that bundle of knowledge you cited seems learnable in a year.
> 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.
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.
" I don't doubt that has been true on all the teams you've managed. My experience differs significantly, and there's a lot of data which indicates my experiences may have been more representative. Caveat Emptor, of course
Management is interesting because you can be a terrible manager yet still have a successful career at it.
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.
I realized Uber was in pretty bad shape 2 years ago when the company i was at was trying to hire one of their VPs of Engineering. Not only did they have many VPs of Engineering, they had multiple VPs of Engineering in his specific discipline. It seemed like people were literally only there to get a title and a piece of the kingdom.
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.
It sounds to me like the cutthroat system OP describes would cause the rise of the sort of people who would perpetuate systemic misogyny.
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 jacket drama had nothing to do with gender really and she was making a big deal out of something trivial. I can imagine the scenario is like "ok we're too cheap to create custom jackets for everyone so we will order the jacket size that fits the majority and the minority can try to fit in it". If the gender ratio was the other way around, there would be a similar situation.
The response to other reports are standard. Whether it is a homosexual boss or a female boss, the company will seek to protect itself.
Sure, and we could save money by only have women's restrooms on every other floor, or not at all since we can certainly save money by not hiring women at all. Its just economic sense: we know that its easier to find men, so lets just optimize for men. Then there's all that diversity training. And don't forget women create tension at the office because they are pretty and their women parts distract the men who can't be expected to control themselves.
If you think that any of this is trivial, you are part of the problem.
Your argument isn't relevant for the situation and is very black and white. Wearing male sized team gear is a trivial matter. There are obviously other cases where accounting for every minority is important but this is not one of them.
I do get that it's inconvenient but it's a huge slap in the face to tell a sizeable percentage of your workforce that no, you can't get them a jacket that almost everyone else now has. They could've at least given them something of equivalent value. Even if it might not be sexist, it's a dick move.
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.