Hacker News new | past | comments | ask | show | jobs | submit login
Uber cuts 3000 more jobs, closes 45 offices (wsj.com)
1063 points by WFHRenaissance 14 days ago | hide | past | web | favorite | 651 comments



Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs? We always are amazed at the number of developers at companies like this. (the numbers I've seen are old, but I guess out of 22,000 employees, it was something like 5000 engineers?) While that allows you to build in a more robust way than a smaller company, it seems like there's no shortage of developers working on tooling, R&D projects, and at least partially on open source projects, roles that could presumably go away if a company had to focus strictly on the core product.


I've never worked for a true unicorn but I've been in companies that got a sudden success and grew way too big way too fast. I think you can tell from the inside when a company loses its way. As you mention, suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product. You have man-years worth of work going nowhere as projects get scrapped mid-development. You start having a massively more complicated hierarchy of bosses and managers and project leaders and it seems like everybody is chief of something and everybody loses sight of the big picture as they just become focused on a single aspect of a given product. What was once a lean startup with a vision is now struggling to get new products out of the pipeline even though they have ten times (or more) the manpower.

Growing is hard and unicorns are expected to grow really, really fast. In the end many companies with a completely viable product end up going under just because investors thought that a million dollar company should be a billion dollar company.


>suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product

At scale it tends to be worthwhile, even necessary, to engage fully with the complexity of all those "niche" aspects.

When you don't understand how something could possibly take so much effort, it's possible all the people working on it are idiots and you could do it better in a weekend. (When you spot situations like that, think of them as startup opportunities...)

It's also possible they're doing a good job hiding the complexity from you.


I think there is a lot of truth to both your comment and the parent comment.

Everyone underestimates the complexity of systems they aren't personally familiar with. Ask the average person how many parts are in a modern automobile and they'd probably guess too low by an order of magnitude.

But it is also true that large organizations get weird when money is easily available. You get a Cambrian explosion where without selection pressure to ensure people and teams do real, useful work, everything starts to seem like a good idea.

Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business.


This is a very nice description of what I've noticed moving to a large organisation. There is also a lot of busy work. As the organisation grows, communicating and negotiating between groups requires extra effort that often ends up being the role of a new management level, and groups have self-preserving incentives to stay relevant leading to lots of entropy (busy work, repeated work, hero projects that are just there for internal branding). As someone who has recently been put in this level of management I spend a lot of time having to negotiate out of new project initiatives invented more to attract exec attention or satisfy a rogue execs dream project. Makes me really look forward to moving back to working in a smaller company.


> Determining which organizational complexity is essential and which is accidental is likely the quintessential hard problem of business.

Three questions.

(1) "What would the impact on our business be if we built the best possible, state of the art feature here?"

(2) "What would the impact on our business be if we half-assed a solution in a quarter of the time?"

(3) "What would the impact on our business be if we utterly failed?"

(Usually, the different between 1 & 2 is negligible. Sometimes, between 1 & 3. Don't ask people to justify success. Ask them to justify why we should spend any more time than slightly-above-failure.)


Those questions assume an existing framework where "the feature", "state of the art", "half-assed", and "failed" are all well-defined. But my experience is that the framing itself is most of where the challenge lies.

You end up with team A who wants to add the feature, team B who thinks it's an anti-feature, team C who thinks the entire application where feature lives should be scrapped, PM D who says users can already accomplish what the feature does using existing features, UX design E who says the fact that users are still asking for the feature means all those other features must be poorly designed and we should fix those...


That second paragraph summarized the last 5 years of my professional career.

In my experience, I've always listened to the last UX design E guy. Every time we worked on what he said the users asked for, we did well..

The problems caused by "half-assed" solutions are likely somewhere down the line, in distant future and their true costs impossible to estimate.

Anything less than perfection will incure avoidable future costs, and perfection approaches infinite time to deliver.

Ergo, standing in the present, one should do ones best to estimate future costs and decide what percent of perfection seems optimal.

In reality, when asked to self-estimate, too many teams (and especially naive PMs) select perfection as the optimal approach.


Every tech company thinks they’ll just build their own CRM until they try.

See also: build systems and UI frameworks.

That’s a false dichotomy. It’s likely that that are both not idiots and what they are doing isn’t necessary.

When large companies have such excess engineering power to blow, they tend to say yes to all requirements and scope creep takes over everything. So no, the engineers building the abstract framework factory are not stupid, but they should have just built the report dashboard instead of the tool to generate tool generators.


As soon as an organisation gets above a size limit, organisational politics becomes the most important factor in any decision.

The decision to agree to a feature request starts to consider Who the feature request came from before any of the practicalities of the feature itself.

They're not idiots, and they are doing what is necessary, but the goals have moved from outward-facing market and customer concerns to inward-facing organisational-political concerns.

Every coder in a large organisation, sooner or later, gets given a task that makes no engineering sense but achieves some internal political goal.


It is fair to say that when you have R&D headcount in thousands it better be something really impressive.

Boeing 747 design team was 4500 engineers and they were done in 29 months.


I can't find you a source right now but back in '94 when I was learning IBM mainframe Assembler the history was mentioned and they claimed thousands of engineers, mathematicians and physicist worked for 3.5 years on the first mainframe (or was that the 360?).

The IBM of that era was literally inventing the modern computing systems. The complexity of the tasks at hand were essential, not incidental. I think the general trend of thought here is a critique of the latter day NIH syndrome and the consequent inflation of the technical teams.

Software is a little strange sometimes.

It’s a different type of systems engineering, that’s more akin to sorcery, than to actual physics.

The hardware is, of course, limited by physics, like the speed of electrons and heat dissipation. But once you get past that, your computer system is a collection of bytes that you reassemble to form whatever it is your imagination desires.

And while the 747 is a magnificent plane, it did have the benefit of over 50 years of aviation and aeronautical science behind it, all figured out.

Whereas software is still somewhat in its infancy right now. And every few decades, it seems to revolutionize itself, as newer and faster hardware become available.


A taxi company over here had a contractor build them their own hailing app. Cost them less than €600k, it's pretty slick.

The functionality may be similar, but the scale is completely different and shouldn’t be ignored. Building a machine that cooks 1 pancake every 5 minutes is a fun project for precocious college students; designing a system capable of cooking 10,000 uniform pancakes per minute is a feat of incredible industrial engineering.

I'm talking about R&D specifically, not infra folks.

But let's say designing for scale is 100 times harder than a taxi app for just one national taxi service. Based on my 23 year career in trenches I seriously doubt that's the case, but let's be generous.

That would net us into ballpark of €60M expense. Non-negligible, but it translates into a hundred developers pulling €100k a year for 6 years, still at least an order of magnitude below Uber.

Very obviously it does not scale anywhere near linear. There has to be a severe case of diminishing returns in technical hiring.


So did early Uber. Famously, the contractors were Spanish-speaking, so FTE engineers #1-5 had Spanish-English dictionaries on their desks to understand the code.

fair, but also a lot of Uber's business model is leveraged on top of the basic platform.

What does that mean?

It means that the functionality of the app that immediately comes to mind is only one of the many ways in which they lose an extraordinary amount of money.

>> You have man-years worth of work going nowhere as projects get scrapped mid-development.

That's better than seeing man-years go into features that get deployed. I witnessed one successful control system company spin up a team of new hotshot UI engineers, all right out of the best schools. After months of work the team "updated" the product. Withing hours the call center was hit with hundreds of "You changed the g-dam menus!! Put them back NOW!!".

The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.


> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

Is this sarcasm? Seems like a really user-hostile attitude if not. Admittedly, my personal point-of-view is that the majority of UI updates are make-work for engineers and PMs with at best no value added, and at worst negative value created (as you experienced).


It's a funny joke because everyone from Microsoft, IBM, and Apple to Canonical and the GNOME Project has been guilty of this in the past.

Oh god you're right

That's more of a failure for the ux and product vision than it is a failure of project management. The trick isn't to just roll out new changes slowly, but to involve the users and figure out what needs to change and how.


>> roll out new changes slowly.

That really depends on your customers and the product. In this case, control systems, incremental changes are definitely not the way to go. Imagine if your car made an incremental change to the position of the brake pedal every time you turned it on. In such situations you don't babystep. You announce the change ahead of time, provide your customers with transition training, and make the change as scheduled.

In the case of "adaptive" menus in control systems, imagine if the elevator in your building rearranged its floor buttons so that the most requested floors were always at the top. Total chaos. People learn where their button is on day one. After that ANY change is going to go badly no matter what the UI engineers say. That UI should be carved in stone for the life of the building.


Were there any dedicated UX people involved? To me, a UI engineer is someone who works exclusively on the front end, and would implement the work of the UX designer. They wouldn't actually do the designing and research themselves.


This is one of those cases where that Ford quote about a faster horse is relevant. Many people will be happy to just have what they have now without thinking how it could be better.

> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

Fuck people doing this. Especially extremely radical design changes such as Twitter's and Facebook's "redesigns" that they force down the throats of their users. Or Microsoft.


Or do A/B testing and incremental rollouts?


A/B tested products are terrible. Please don’t do that to an actual product people pay money for.

“On this page, 12% more users clicked save if the save button was green instead of blue”


Bad A/B testing is bad. Incremental rollouts are not bad.

> The trick is to squeeze your long-term UI project in the same update as some routine security fixes. Then the clients are forced to learn the new system.

No, the trick is to iteratively change the UI in a way that's easy for the user to get used to.


[flagged]


Please don't take HN threads on generic ideological tangents. It's off-topic and tedious, and leads to nasty flamewars that are also off-topic and tedious. It's also against the guidelines (https://news.ycombinator.com/newsguidelines.html), as other users have pointed out.

Internet forum threads can't withstand this sort of provocation, which means your comment had troll effects whether you intended it to or not. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...


> Eschew flamebait. Don't introduce flamewar topics unless you have something genuinely new to say. Avoid unrelated controversies and generic tangents.


Indeed. That was not a debate worth bringing up.


> I'm not saying anything about anyone's intent, but replacing "man-year" with "person-year" is a painless, traditional-grammar-friendly way to go gender-neutral.

It is not painless: it is dissonant and takes another syllable.

One might argue that is worth the pain and stylistic cost of infelicitous phrasing in order to be sex-neutral or welcoming or whatever, and that might indeed be the case.

I think that language is far less important here than culture. Persian, for example, is a genderless language: it has no 'he' or 'her,' no 'waiter' or 'waitress,' no 'actor' or 'actress.' And yet I think most folks would say that Iran is far less gender-neutral than any English-speaking country.


Speaking of dissonant, as a woman it's always a bit difficult to figure out when "man" means "human" and when "man" means "not you, lady". "Men's room" = "not you, lady"; "man-years" = "of course I'm talking about you because I'm certainly not sexist; man means human, of course, except when it explicitly doesn't, like when you didn't have the right to vote because the right to vote was for all men who are created equal, haha".

Makes me think of Ismo and the word "ass": https://www.youtube.com/watch?v=RAGcDi0DRtU


As with many things that don't make much sense, it started from something more reasonable. Long, long ago the word 'man' unambiguously referred to all human beings, while 'woman' was used for females and 'werman' was used for males.

The forgotten sexism is that we began using 'men' to refer specifically to males, almost like they were the only people that mattered. It happened so long ago that it's been mostly forgotten that there even was another name.

Though, you still see vestiges of it in the language. That's the same wer- as in werewolf.


This is a good point, excuse a quibble: 'werman' did not seem to actually see usage in Old English, although 'wepman', meaning male human, did in Middle English.

I'm basing this on a discussion at Wiktionary:

> Their point, that Old English mann was not specifically male, is correct; but their example of the specifically male word is apparently mistaken.

https://en.wiktionary.org/wiki/Talk:werman

And 'wepman' is documented on the Middle English Compendium.

https://quod.lib.umich.edu/m/middle-english-dictionary/dicti...


Thanks for pointing that out. I think Wiktionary is where I first heard the word, and I hadn't seen it was removed.

So, wer did mean male/husband and man did mean everyone. It's just that they weren't used together. I should probably also have noted that woman was 'wifman' back then. That one has more obvious descendants than the male version.


But this is something you do constantly as an English speaker. "Drinking" can mean any liquid, or just alcohol. Wood can be a material, or a forest. A bank can be a financial institution or the side of a river. A mouse can be a rodent or a computer peripheral. Does it really take conscious difficulty to figure out the intended meaning?

> Persian, for example, is a genderless language: it has no 'he' or 'her,' no 'waiter' or 'waitress,' no 'actor' or 'actress.' And yet I think most folks would say that Iran is far less gender-neutral than any English-speaking country.

I don't want to be that person but Zoroastranism is the religion you should be comparing against -- it predates Islam by a good deal and developed alongside Farsi. And Zoroastranism does hold men and women to be equal. [1] Iran was actually a pretty liberal country prior to the Islamic Revolution (which was really more of a rebellion against American control).

[1] https://www.hinduwebsite.com/zoroastrianism/gender.asp


Iran has been Muslim for over 1300 years. Zoroastrians today are a tiny minority. It's a bit disingenuous to refer to the (brief, mainly urban) liberalism of the Pahlavi years in place of everything that came before or after.

> It is not painless: it is dissonant

The dissonance should be cause for reflection and growth. Why does the gendered version sound harmonious? What does that answer say about the society that evolved our language?

> and takes another syllable.

That's just silly. If typing three additional characters causes you pain, you shouldn't be writing comments on the internet in the first place.


Dev-hours, suggested below, also sounds harmonious. Employee hours sounds okay; it's cumbersome but it seems to project the concept of hourly pay directly into my mind. Hu-years and hu-hours are physically uncomfortable. Is there anything to learn about our society from that?

I think language is something we don't really understand. Maybe you have a more refined model, but any reflection upon this for me will be complete conjecture. Language is this ancient thing that evolved in concert with our minds, optimizing for some vast array of factors. Human intervention into that process seems to always go wrong, down to US attempts to fix the spelling.

It bothers me that speaking my dialect with common definitions is not good enough. Can we not just be charitable in our interpretations of others' speech? Why do I have to dedicate cognitive load to verifying that every possible interpretation of every word is acceptable with no expectation of others meeting me in the middle, even just as far as the dictionary definition? If people's feelings matter, why don't mine?


> If people's feelings matter, why don't mine?

Of course your feelings matter. I'm sure there are plenty of situations where your feelings are the most important factor to consider. But this is not one of those situations. Your feelings of minor inconvenience from being asked to use different words are less relevant than others' feelings of oppression from decades/centuries of societal biases.


This is long, and I apologize for that. I think I've said some important things though, and I'll ask you to do me the kindness of reading it. Thanks.

There's a notion in improv that when you respond only to the last thing that someone said, it's because you are in your own head and you're not listening. Additionally, it feels like you're talking down to me and others in this thread. Are those feelings invalid? It just seems like showing some respect to others should be a precursor to caring about whether a word could be misinterpreted as exclusionary, if the goal really is to make people feel less bad.

I personally devote a huge amount of time and energy to the feelings of others. I need to be doing it less, it degrades me. If I were to start caring about this on top of everything else, I would be completely dysfunctional. You call it a minor inconvenience, but if I were to accept that this is worth doing, I'd implicitly be agreeing to a thousand minor inconveniences, overthinking everything I say even more than I already do (this is a fifth draft, and look how long it has been made so I can feel I'm communicating effectively), and inevitably retreating altogether from social interactions that already give me anxiety.

Back to the subject at hand. What the word 'man' as in 'mankind', 'manpower', or 'man-hours' means to me is a dehumanized, de-individualised, notion of genetic humans working towards some end. This is a _very_ useful construct for me. A person is something else, a human individual. It is impossible for me to consider a single person, let alone thousands. People have 86 billion neurons of uncompressable complexity, and I've only got 86 billion of my own to try and grok that. This is also an incredibly useful construct for me. I can't just swap one for the other, it would be a significant long term effort to rewire all of the associations.

A better solution would be a new word to take the place of 'man' there. 'Man' already does the job, but I'm sure there are other prefixes in english that also mean human. I don't think it's a material issue, so I'm not going to devote energy to solving it. But if someone is going to tell me how to talk, they can afford to make the damn effort to find a suitable alternative instead of forcing me to adapt to the first thing that comes to mind. And when it is pointed out that it doesn't work, and it doesn't sound right, they could maybe try to figure out what is wrong with their solution, rather than assuming I'm a closed-minded closeted sexist. I don't know.


> It is not painless: it is dissonant

You'll get used to it in about 5 minutes.

> and takes another syllable.

Seriously, the amount of time people who pretend to be hard and rational loose their minds over things like "one syllable."

> Persian, for example, is a genderless language: it has no 'he' or 'her,' no 'waiter' or 'waitress,' no 'actor' or 'actress.' And yet I think most folks would say that Iran is far less gender-neutral than any English-speaking country.

That's a straw man. Asking for gender-neutral terms when referring to groups of people does not equate to asking for gender-neutral culture. Take it from a trans person, that is _not_ what most of us are asking for.


>Take it from a trans person, that is _not_ what most of us are asking for.

statements like this are not useful for building understanding.

rather than speaking in negatives and stating what it is that you're not looking to achieve, tell us what is being sought.

Being disconnected from the struggle/lifestyle/issue, I do not know what to take from your statement.

What, in your opinion, are most trans people asking for, and what makes you sure that the majority seek that?

For what it's worth, I already use 'dev-hours', but not from any gender/rights perspective, it just sounds better and correlates the specific industry to the metric. It's also about the same amount of verbal effort as 'man-hours', so the change was easy.


> What, in your opinion, are most trans people asking for, and what makes you sure that the majority seek that?

We're asking to simply feel included (this includes women as well as trans people; I'm both). When so much of your life is being told you don't belong or that people like you don't / shouldn't exist, it's a big deal. It's 1) more accurate and 2) more reflective of the wide variety of experiences a person can have. I'm not being glib here, but of course the need for gender neutral language seems irrelevant: it is to you because you were already included. It's doubly important in heavily male-dominated industries.

I, too, prefer using "dev" or "employee" in place of "man" in these cases simply because it's more accurate. But it's really not a lot of effort and it actually means something when someone corrects themselves because it's basically "wow I feel seen and like I have a place here". When you've never seen someone like you in a position of success above you because you're one of the first, it really, really matters to feel accepted in any way you can.

Like, you don't have to do it. But these days it really does sound a bit anachronistic to use "man-hours" -- language changes along with the culture and it always has.


I'm totally with you on the inclusion part, everyone in a diverse team needs to feel included.

However, on the solution part, if you say dev-hours, I as a designer would have a huge problem :-), or even as a PM I would have same problem. 'Employee' comes close, but then it precludes estimating for consultants, freelancers etc. 'Person Hours' does not seem to have any of above problems, but then as mentioned it is awkward to use.

Well, maybe perfect solution does not exist, or maybe the perfect solution is being more accepting - accepting gender diversity AND also accepting that many times things that we do is out of laziness or choosing easier path or just out of habit - people in professional work environment do not do things with ill intention.

There is no ill intention behind using certain phrase and doing so does not spread any harmful stuff around.


> There is no ill intention behind using certain phrase and doing so does not spread any harmful stuff around.

I agree; very few people use male-centered language with ill intentions. But it's still a choice people can make if they choose to, and it means a lot to those of us who often feel marginalized. You're not a jerk if you don't, but it's pretty much all upside if you do.

Anecdotally, I would say I hear gender-neutral language used about 2/3 of the time in the Fortune 500 world. While I don't hide the fact that I'm trans, I'm fortunate to pass for cisgender so most people I work with outside my immediate team don't know -- I'm pretty sure they're not altering their language for me. Maybe it's because I'm a woman, but it was a trend I noticed before I transitioned as well.


> statements like this are not useful for building understanding.

I don't ask you to "understand," honestly I'm not sure if I even particularly want you to. I want you to _respect_ us, and others. And no, understanding is not a precondition to respect. By insisting on using exclusive language, or even by framing otherwise inclusive language as exclusive, you are showing lack of such respect.

And true understanding is a huge amount of work. If you need understanding for respect, there ain't going to be many people you'll respect.

> Being disconnected from the struggle/lifestyle/issue, I do not know what to take from your statement.

> What, in your opinion, are most trans people asking for, and what makes you sure that the majority seek that?

We ask you to say "humankind" and "employee-hours." Among other mostly practical, material things: don't exclude us and don't get in our way.


I do hope you know that it’s never intentional. I’m definitely not excluding any gender when I think of the concept of “man hours”—it’s just an abbreviation for “human” to me. I try to use gender neutral language where ever I can, whenever I think of it... I end my meetings with “thanks everyone” rather than “thanks guys”, even though “guys” just means people to me. But it can be stressful to always have to worry about the different intentions people can put behind words, even if none are meant. Basically I think trying to use more gender neutral language is a great thing, but we also shouldn’t criticize it every time it’s seen. I think it’s fair to assume we all have good intentions and that we’re not secretly sexist.


I don't alter quotes, even for PC reasons. And If I am going to reuse language for effect I am not going to make changes unless they add to the point I am making. The first comment said man-years and I stuck with that as I wasn't trying to correct their gender grammar.

Also, "person-year" is vague as "persons" includes non-humans entities such as corporations and partnerships. "Man-year" refers only to work by biological humans. "People-years" might be better but that is plural. Had I been the first I might have used person-years, but when someone else sets a precedent that avoids confusion I'm happy to stick with it despite potential microaggressions.


Since people don't like the man part of human, what if we started saying hu-years? Hu is still only one syllable.


sde-year, dev-year, engineer-year, resource-year, employee-year, are all variants I've heard before.

I can understand not wanting to miss-quote something, but otherwise seems simple enough to use different language.


While those variants solve some complaints, they're a lot more specific and may change the meaning of some statements. For example, many of those terms exclude work that isn't done by "engineers". Using a term like "employee-hours" might make contractors on your team feel less valued.


Call them contributor-hours, this way only the people that slack off can be offended.

I'm not saying anything about anyone's intent either, but it's also painless and traditional just to refrain from unsolicited corrections of people's word choice when there isn't any ill intent to be talked about.


I find it very enlightening when people who find issue with my expression let me know about it in a friendly way. I think the commenter took a lot of care to phrase their concern in a very nice way; when people do this to me I thank them. It’s the only way that I can keep learning how the language changes with time.


If matt_morgan has concern, matt_morgan can personalize his concern, not preach about what's "painless, traditional-grammar-friendly" generally to all. I don't find that friendly, I find it intrusive.


I always find it so interesting that a full-out flamewar is just fun, while a side comment about improving communication is "intrusive". This is the internet, my friend...


> there isn't any ill intent to be talked about

In addition to intent, outcome must also be considered.


The OP's intent was not to single out a gender. He/she was using a very common catchphrase. Your call-out was really passive-aggressive and uncalled for.

Do you get pressed everytime someone talks about history, and suggest they use the word "herstory" or "perstory" instead?


I typically use “resource-year” so as to dehumanize everyone equally.


Why not go with "work-years"? It has the benefit of being gender neutral and even more relevant.


Seems to imply a different amount of time. Work year would be the amount of time worked in a year (usually ~2000 hours give or take). Sort of like how a work-day is 8 hours rather than 24.

Man/woman/person/dev/etc-year seem to imply an amount of work that is equivalent to a year (~8760 hours).

Or at least that's how I would use those terms. It's entirely possible that these definitions are regional in nature.


We were once negotiating an SLA and my colleague happily agreed to a 24 hour turnaround time. I asked him if he thought that was perhaps a bit optimistic and he replied, “24 business hours, that’s a three day turnaround time!”


I always interpret a work year to be the same thing as a person year, which is ~2000 hours.


That is a life-year.


I actually considered that when writing my original comment but "the mythical man-month" is such an obvious reference that it felt weird to change it. I suppose you can also think of it like "horsepower", it's an equivalency but doesn't actually mean that the power literally comes from a horse.

Still, point taken, I'll consider using person-year next time.


Can we call it "sweat-year" or "work-year" please?

you are missing the point, it is still a year of work, regardless of gender.


I suspect they got the point, and rather you are missing their point, which is taking the (trivially easy) opportunity to be more gender-neutral with our language..

That's all!


[flagged]


You are in fact the one that sounds like you are crusading, not the person you are replying to. You seem really fired up about it.


[flagged]


And yet you are treating their comment like a "real problem"... you're the one crusading, they just gently and non-confrontationally made a suggestion. You could have just passed on by if you didn't agree with their suggestion, but you turned it into a crusade against them. To the observer, you are in fact the one acting like a "snowflake" fired up (dare I say "triggered") by their actually quite gentle suggestion, in which they make it clear that they weren't accusing anyone of ill-intent.

Do you think your annoyance and anger at their suggestion is a "real problem" or a "snowflake problem"? If you don't think it matters that much if someone says "man year" or "person year" (you said it wasn't a "real problem"), why is the suggestion to do either way so triggering to you? Do you think it might be more in line with how worthy of your annoyance it is to see someone suggest "person year" (maybe not worth that much annoyance in the grand scheme of thing when we have 'real problems'?) to reflect on your own about why their suggestion to say "person year" made you so angry and upset, without needing to reply on HN and turn it into a crusade?


My annoyance is that it has absolutely no relevance and adds nothing to the discussion regarding the story/post. It's just noise, which begets noise (my response) and so on. Let's talk about tech.


Sounds like a snowflake problem to me.

If left alone, there would have been nothing distracting about that short and explicitly non-accusatory comment, but you were triggered and chose to build a crusade around how you don't want to see certain kinds of comments on HN. You seem to have trouble handling the fact that some people have different opinions than you, about what comments are worth making. Very snowflake problem.


Sounds like you have a problem handling the fact that some people are tired of the bellyaching every time someone uses a common term in which it is not meant in a derogatory way.


I guess we're all equally snowflakes here then.

And look where we are now. There are 30 comments that have been made on an irelevant topic, that detracted from the issue.

Was it worth it? Did you feel good about yourself, to distract everyone like this?


The fact that you view a history of systemic sexism in tech and in the world as not a real problem is, in fact, part of the problem.

The good news is when people start being more inclusive with their language you'll see fewer people correcting them!


And yet it is completely and utterly irrelevant to the story/post.


You understand that there are millions of women who are victims of abuse, sidelined or disregarded by society, and constantly repressed because of sexism, right?

Losing your job is a temporary problem for most people. Sexism, like the kind that is baked right into our language, is an inescapable daily struggle for many women.

We have the capacity to think about both women's rights and the recently unemployed at the same time. It's frankly sad that you can't look deeply enough at this issue to see it as more than a problem of "grammar preferences".


Once again, none of this is relevant to the post regarding Uber's layoffs unless they're somehow disproportionately laying off more women than men can it be even considered remotely relevant.


I disagree with such a compartmentalized way of thinking about these issues, where it's inappropriate to discuss gendered language when it comes up in some other context. That's often the only effective opportunity to address this kind of problem. A comment about the use of gendered language is relevant in response to a comment that uses arguably gendered language.


I presume all the developers are men? as in members of mankind... All people are men.


This is not a common way of speaking anymore, IMO. When I read "all the developers are men", I didn't understand what you meant at all. I thought maybe you were making some kind of ironic joke about sexism. I did get what you meant after re-reading of course, but "All people are men" sounds very archaic to me, like something out of Tolkien.

Usually when we want to talk about humans as a species or whatever, we now use the word "human."


This is going to sound stupid but at some point, it's less important what's right and more important how something makes people feel.


Language is fluid. The thing that was "right" to say 500 years ago wasn't right 100 years ago, and what was "right" 100 years ago wouldn't be right now. There are clear arguments for why encouraging people to think about the gendered language that they use and how it perpetuates gender roles would be beneficial in combating sexism. The arguments for maintaining existing language because it is currently the most popular tend to be pretty thin.


When you move into how people feel are we introducing inequality? People feel at different rates. Some can go into a rage in an instant while others can be a rock. Are we rewarding the primate brain over scientific obvervations when we choose to accept personal feeling as the gold standard? Should we be encouraging one over the other?


Sure, but the idea of "mankind" is gendered / male-centric in the first place. We just defaulted to male because we always default to male.

Training yourself to default to non-gendered language like person-kind and to think about whether a term originates from problematic aspects of gender dynamics is a relatively easy first step towards breaking down some of the insidious aspects of sexism that are imbedded in language.


> Sure, but the idea of "mankind" is gendered / male-centric in the first place. We just defaulted to male because we always default to male.

That is not actually true. The Old English word for a male human being is wer, as in werewolf; it is cognate to the Latin vir (also meaning a male human being, and the source of modern English words like virile & virtue). That word is no longer in common use in modern English, although I think maybe it survives in some dialects.

The word man(n), OTOH is the gender-neutral Old English word for a human being, as found in such words as woman (from wifman, a wife-man) or leman (a mistress, or love-man), both notably referring to female human beings. It is cognate to modern German mann, again referring to any human being.

The word mankind thus refers to … any kind of man.


Modern German "Mann" is an adult, human male. Ehemann (husband), Fachmann (expert), Kaufmann (salesman). The parallel, of course, is Frau (adult, human woman), which also does double-duty on its own as a word for "wife": Ehefrau (wife), Fachfrau (expert), Putzfrau (cleaning lady). That "Putzfrau" is a long-standing word but "Putzmann" doesn't exist, and that "fachmännisch" and not "fachfrauisch" (fachfräulisch?) is a word are examples of the sexism deeply embedded in languages a lot of us are going on about. Thoughtful Germans are finding their way towards more gender-neutral terms, especially in job postings, which used to be horribly gendered - think "Reinigungskraft" (cleaning power) instead of "Putzfrau", or "Entwickler*in" instead of "Entwickler" (developer, grammatically male).

Modern German "man" (single 'n') is an indirect pronoun that is usually best translated as "one" or "someone", but even then, you fall into the sexism of male as default. "Man ist was man isst" (one is what one eats)


This is amazing.

This is why I come to read HN =) - interesting content like this, or esoteric/cool facts, or awesomely deep tech discussions.

Out of curiosity - do you have a background in this kind of thing (linguistics), or its just an interest topic for you?

(As a side-note, this whole SJW crusade does irk me somewhat, but hey, I guess it resulted in gems like this).


> Out of curiosity - do you have a background in this kind of thing (linguistics), or its just an interest topic for you?

I love languages. Each one is beautiful and endearing and ugly and infuriating in its own way. I really love English, because it’s my native tongue and I know the most about it, but I love studying languages in general. One thing I have found is that the more one knows about many languages the less likely one is to go off half-cocked about perceived problems in one’s own.

I did study a little bit formally, but I also love computers and there’re a lot more career opportunities in software development than in philology or etymology, so that’s where I focused.


Can we be species neutral. Person refers to humans and leaves out animals and other substances like carbon which would experience a year in the same manner as a human.


Corporations are people too, my friend.


For what it's worth, this isn't unique to unicorns. Almost company successful enough to get to the scale of tens of thousands of employees likely has huge amounts of waste within it. The situation you describe of niche projects being scrapped after several person-years of effort had been invested, incomprehensible management hierarchy, and no coherent strategy perfectly matches my first job out of college, a year at Sprint in 1999. Me and two other new hires spent a year doing next to nothing on a team of 20+ building a complicated Java service with a purpose I never understood, but which had been going on for about a year, with half the team made up of contractors. Pretty sure I never wrote any actual code, though I did have to fill out time sheets every week. I had two managers, neither of whom I ever talked to. After a year, I got a 15% raise and a promotion. Then soon after I found another job and quit, our project got cancelled, but everyone on the team just got moved to other teams doing similar "work".


"...you can tell from the inside when a company loses its way."

Those example pathologies you listed are SOP at all the mature orgs I've worked at.


Do you think the degree to which a company succumbs to one of these "pathologies" matters? Is it a matter of timing (i.e. becoming successful faster than they become moribund)?

What do you think differentiates a company that becomes "mature" vs one that flames out?


Mature companies, notably, make a profit. Not a future profit, not an expected profit, not profit-discounting-advertising, a right-now end-of-year no-accounting-tricks more revenue from sale of goods than expenditures from all sources. I'm going to take a page out of the IRS handbook, and say that they have made a profit for the last three out of five years, in fact. Let's take that a step further and say that they've existed for five years. Their primary method of financing operations is not private equity, but public equity or loans. Once a company looks like this, it's pretty well set.


Sound like what happened at Intel


Well said. That's exactly what happened to many unicorns, including Uber.


Oh, you might be surprised how many people are not working on anything of consequence. Some of these companies don't even do much in the way of building stuff outside of the product teams, and even then, they frequently fizzle after some point.

You know the line "don't mistake motion for progress"? There's a whole lot of motion up in those SoMa offices... but very little progress. Some of these teams are very good at doing a lot of jiggling around while never accomplishing anything. They manage to snow their manager, which snows the next-level up, and if nobody calls BS, it just goes on like this.

R&D? When the response to building something new is an _immune system flare-up_ from the people who benefit from things remaining exactly as they are, there can be no R&D.

Just like the server situation, the employee situation is bloated beyond belief. You have people making messes and others cleaning it up, instead of just not making the mess in the first place (and then needing neither of those people).

If a million monkeys at a million typewriters would eventually produce the works of Shakespeare, some of these companies would likewise boil down to "three monkeys, ten minutes" (not my line but I love it).


I see it more as scaling problems that make it look like people aren't actually busy.

As the userbase scales, infrastructure scales, and what was once a simple "ALTER TABLE" is now a system with a team managing it because a single Postgres instance didn't scale.

As the engineering headcount scales, code changes, builds, even understanding the system become slower. You overcome that with better engineering, but mostly more engineers.

As the product matures, there's still a drive for growth, but the low-hanging product fruit has been picked, so you get lots of product teams trying to either optimize their little part because, at scale, it makes a big difference, or product teams working on new, crazy ideas--the startup within a unicorn-startup--that will most likely fail.


I'm at Airbnb (opinions strictly are my own). The number of engineers working on tooling for us is actually not that large. The vast, vast majority are product engineers and with our most recent layoffs the majority of the cuts were for those types of engineers. My own opinion is that we simply had way too many product engineers for the amount of actual output we got from them.

Uber is on another different plane altogether... they have more than double the number of engineers and from talking w/ colleagues that worked for years at Uber it's my impression that even on infra there's a lot of bloat. Plenty of high level ICs that couldn't produce quality IC work to save their lives and plenty of pet projects.


> Uber is on another different plane altogether

These are complete guesses for the pre-covid era, but it gives an idea of scale difference. The average Airbnb user probably books 2-3 times per year. The average Uber user probably books 2-3 rides per week. At 50x the volume, the infrastructure is different, and probably more complicated to handle the volume.


Eh, they're solving different problems. I don't think you can necessarily call Uber's problem more complicated just because it's an order of magnitude more volume. I worked at a small ad tech start-up with a team of 5 engineers on a real-time bidding platform that was serving 1k requests/second and moved to a travel company that's now 100+ engineers that serves maybe ~250 requests/second at peak traffic, but the travel company's infrastructure is a lot more complicated even though the volume is smaller.

right. this recession is actually giving cover to let go of a lot of bloat that has built up over the years.


Well, freeing it up to compete. I expect some of the bloat is just so that someone can't work for a competitor.


You'd think so but that's at least not the impression I've gotten. At Google that's certainly going to be the case but at a company like Uber/Lyft/Airbnb the bloat ends up largely arising due to managerial bloat (managers want to grow their org to make themselves seem more important) and low technical standards for higher level ICs (which results in far more resources used to accomplish each project).


Are you saying that technical standards are lowered as one moves up the IC ladder? If so, how and why?


Technical competence isn't as well evaluated at companies like Uber/Lyft/Airbnb at L6+ especially for external hires. So it's not so much that the technical bar is dropped but that it just is less enforced at higher levels. As a result you end up with a lot of ICs that are all talk but little else. This is, of course, a gross generalization. I've worked with and know great engineers of all levels at these companies. But Uber in particular had plenty of really bad apples that got hired into other companies across the bay at L6/L7/L8.

Where does IC stands for? Probably not intensive care :D


Individual contributor (technical path as opposed to a managerial path)


Individual Contributor. Basically means no direct reports.


The fact that this term exists implies bloat and a focus on process not productivity. You may as well call them "leaf nodes".

There are programmers and senior programmers, data designers and senior etc. There are also team leads and program managers. There's basically two tracks, you either create stuff or you manage the creation of it.

They have different titles now, and there's a lot of Agile fluff (how is a scrum master not just a secretarial service and the function of a team leader not to keep their meetings focused?)


Thank you! That makes sense, I will try to remember it :)


This is just a myth.

Software has way gone out of the stage where one person keep the recipe for the secret sauce, and could change the game.

No one is irreplacable.


> Plenty of high level ICs that couldn't produce quality IC work to save their lives and plenty of pet projects.

This seems so strange to me. As a lead, most of my work is management, organization, and planning. To scratch the development itch I usually have 1 pet project going on that I either use when I'm taking a break from actual work or work on in my spare time. But even that pet project has pretty clear long or short term value and the only reason why it's not being worked on by my team is because it hasn't been prioritized yet. I can't imagine working on a pet project that has no clear value to the company.


In a bloated org, they can get away with it though... we had to let one high level Uber hire go because they couldn't code to save their lives, had insufficient technical expertise to guide any kind of substantive project, and played a lot of politics to seem important. I've run into at least 4 high level hires from Uber with the same kind of profile.

At the end of the day, it's just a reminder that careful screening is important. Could be a cultural issue that impacts certain unicorns, but it's also on the hiring company to thoroughly fact-check and test a candidate (and no, leetcode and simple arch questions aren't enough).


Worth pointing out that Uber is no longer a unicorn. It is a large publicly traded corporation with a market cap of $58B. I suppose you're asking your question about large tech companies generally, not so much unicorns? Most unicorns are still quite small (revenue and employee count-wise) relative to large publicly traded corporations like Uber and the FANGs.


Am at a Unicorn. Engineering is 20-30 engineers total. This person is definitely confusing Unicorn with some generic big engineering heavy company. Many companies scale very differently. Some scale with large engineering efforts - mine doesn't. The change in number of engineers has barely moved in the last 2 years.

That said - to the question about unicorns: You're always expendable. Same as any job - same politics - same nonsense. No matter how important they make you think you are to a products success - they'll fire you regardless. It's amazing how fake management will be about urgency. "This is the most critical business function! We must have people working on it!11!!1!1!" Fires key employee because they didn't like them - "critical business function" gets shoved into the backlog to never be seen again. People are fake and think they need to show urgency to get the most value out of their employees.


> show urgency

I call this "artificial panic". That term came to mind when I joined a FMCG around Y2K, and on my first weeks I noticed people were running around stressed, like headless chicken. When I asked "what's on fire" and the answer was "nothing".

https://dilbert.com/strip/2012-07-15

The "Minimalists" say on their podcast that "most emergencies, aren't". When I see panic setting camp in a company's mentality, I make myself scarce for a while until things calm down. If I see that the artificial state of panic is a perpetual feeding machine, I try to dance around it. I've read my share of Dilbert to know to avoid these toxic environments.

Sometimes you need to be a Wally to survive.

https://dilbert.com/strip/1994-11-12


Urgency is a matter of prioritisation.

Ideally in a company there would be one single order backlog, showing the relative value of each project to everyone. However getting such an ordering would involve huge co-ordination across vastly differing internal companies / cultures and would drag up every buried political hand grenade of the company's lifetime.

So instead you do what someone shouts loudly about. If the shouter is right more than 50/50 they are doing pretty well.


Correcting myself (for the record). The Minimalists say that "most CRISES, aren't" (apologies for the caps). I used the word emergencies, which is inaccurate quote.

Reminds me of Douglas Adam's "Crisis Inducer" :)


> "critical business function" gets shoved into the backlog to never be seen again.

Never worked for a unicorn, but everything from big corp to startup to government. "Urgent" provokes no reaction from me anymore because of this.


>"Urgent"

,"Critically Important", etc. is the most recent whatever caught the attention of a typical S/E/VP with the attention span of a ferret long enough for him/her to be able to utter it in the words. If you're able to highly visibly jump and demonstrate activity during exact that moment - a great talent leading to advancements/promotions - there is no point to react as the next new "critical" directive/change of course/etc. is coming very soon. Of course if your manager is one of those aspiring "talented jumpers", he/she will try to make you jump with him/her - it is a real PITA to have such a manager who instead of filtering and protecting the team from would amplify all that stuff flowing down.


I am shocked at how often I can just ignore an annoying email and have the issue go away...


"Never put of until tomorrow anything you can get out of altogether"


I wonder if there is a way to convert Harvard Business Review articles into top-of-the-backlog items automatically...


There's your Startup Idea!


You jest, but an email to backlog service is something some managers might buy.


Gasping in horror at the prospect of that JIRA plug-in coming into being, especially since even I, a casual admin for our Atlassian products, have a good idea what combination of API calls would make that happen.

The only truly urgent thing I've seen is a product being down / a critical bug in production.


Anything that can cause your company to lose a lot of money can be truly urgent. For example, your biggest customer needs a new feature, and if they don't get it by the end of the quarter, they'll switch to your competitor.

On the other hand, artificial deadlines that are invented by your company's management are usually not urgent.


How can a person working on features tell the difference between critical and non-critical features?


Ignore it and see how many calls you get

Go to lunch with the PM?


A large company would never manage to switch to a competitor in one quarter. And they try any hard, it most likely means their getting a cashback under the table for the new contract, or other perk of the sort, the feature is just an excuse.

When I was working at Stanford, a new colleague came rushing out of a meeting ready to start a big new initiative because our VP said something should get done. I had to explain that patience was important because no single person at the University could make a project happen, but hundreds of people at all levels of the org chart could stop a major initiative in it’s tracks if they felt threatened.


Hmm, sounds like you've got some dyfunctional managers. I've never personally witnessed management faking urgency on a project just to get productivity on it. Management is generally charged with making sure ICs know what the priorities are as set by Product. It's possible that Product changes its mind often, confusing everyone. But if Product, Management, and ICs are confused about what your "critical business functions" are, I think you've got some systemic leadership problems.


Systemic leadership problems are more common than you think. Most larger corporations have orgs within them with very different cultures. It’s not hard to know why: the effective managers listen to their developers and shield them from the shit that comes from above. A healthy tree is nurtured under the protection offered by these managers; their reports never know what kind of shitstorms they were protected from. But these kinds of managers are rare albeit very effective.


I love how you distinguish between "ICs" "Management" and "Product". When you say "Product" do you mean Marketing? Sales? Production? Manufacturing? Do they have "ICs" as well as their own "Management"?

The whole point of "Agile" was supposed to break down these divisions. Management is "generally charged" with getting the greatest productivity they can out of their resources. How that productivity is measured may be by "the priorities as set by Product", but that doesn't take into account ROI, sunk costs, COGS, Cap/Opex etc etc.


You are not[1] correct. Product Owner is a well-defined Agile manifesto role.

[1] https://manifesto.co.uk/scrum-roles-product-owner/


Yeah, I was taking artistic license with the term, but "large tech" is probably a better term, though I'd filter it down to those on the lower profitability side. (even those with large IPOs are often just a startup at scale)


Unicorn never meant lower on the profitability side though. It just means a valuable pre-IPO late stage start-up. Plenty of them were or went on to be insanely profitable.


As someone who has hired many engineers and PMs, and runs a hiring budget today, there are some reasons to feel at least fairly secure if you're an engineer at a growing company:

- Building a high-quality product is a longterm investment and most technology companies know that. As a result, in my experience companies who expect growth would always prefer to keep engineers and PMs as investments.

- Companies generally find it hard to hire Engineers and PMs that meet their standards, especially in competitive markets like the SFBA, NYC, Boulder/Denver, Seattle, Austin etc. (You can argue whether that's caused by overly stringent hiring standards - that's a much more complex question). As a result, companies are somewhat more likely to "hoard" engineers if they expect that they'll need them to grow.

- Because engineers in these markets are expensive, it makes economic sense to spend to improve their productivity. If I have 100 engineers on my team and I can make them all just 1% more productive by hiring an additional engineer who focuses solely on internal tools or open source libraries that improve developer QoL, that's arguably money well spent.

- Many products at scale are more complex than one might expect from the outside, which demands a lot of ongoing product/engineering effort to maintain. If you're working on something that has a credible path to revenue or clearly makes/saves money now, your job is probably fairly safe.

This all assumes that 1) the company wants to keep you, and 2) the company is growing, even modestly. Once the financials go downhill companies will cut directly to the bone in order to survive, and at that point nobody in any industry is safe.

(edited for formatting, thanks @mkl)


Quoting for readability:

"""

- Building a high-quality product is a longterm investment and most technology companies know that. As a result, in my experience companies who expect growth would always prefer to keep engineers and PMs as investments.

- Companies generally find it hard to hire Engineers and PMs that meet their standards, especially in competitive markets like the SFBA, NYC, Boulder/Denver, Seattle, Austin etc. (You can argue whether that's caused by overly stringent hiring standards - that's a much more complex question). As a result, companies are somewhat more likely to "hoard" engineers if they expect that they'll need them to grow.

- Because engineers in these markets are expensive, it makes economic sense to spend to improve their productivity. If I have 100 engineers on my team and I can make them all just 1% more productive by hiring an additional engineer who focuses solely on internal tools or open source libraries that improve developer QoL, that's arguably money well spent.

- Many products at scale are more complex than one might expect from the outside, which demands a lot of ongoing product/engineering effort to maintain. If you're working on something that has a credible path to revenue or clearly makes/saves money now, your job is probably fairly safe.

"""

Please don't use code formatting for text. If you want bullet points, put a blank line between them to make separate paragraphs: https://news.ycombinator.com/formatdoc


It's not about in unicorns or not. It's about the scope and impact of your projects, both of which have more to do with the size than the PR status of a company. When the quantity of people in a company exceeds the quantity of work, you'll be much more expendable.

Following this type of logic, joining Uber in 2015 or later is a bad idea. Joining airbnb in 2015 is a bad idea. Joining Google now is likely a bad idea. Joining new orgs in AWS is probably a good idea.

A few heuristics that I find useful: 1. Revenue per employee 2. Moving average of number of substantial launches in the past X months 3. Actionable technical blogs that address real challenges directly related to specific business needs. So, no, Uber's why they switched from MySQL to Postgres and then later another article by the same person on why they switched from Postgres to MySQL do not count.


I agree this is a great way to think about it. At the end of the day “business impact” per employee is the thing that matters most to your individualized risk. If your expertise is essential to the continued improvement of the company’s core business model, you have nothing to fear.

It’s super important to note that business impact is not even close to uniformly distributed throughout a company, even though we sometimes like to pretend that it is.

This is all to make a subtle refinement of your point, that it’s worthwhile to join teams that are high value per engineer, even if the company is more bloated. (Ad serving infra at Google, ec2 at AWS, payments processing at Uber).

However, because those teams are so essential, they tend to have low turnover, higher bars for entry, and a higher than usual rate of internal transfers (as high performers from less essential teams are shifted into more critical roles). So you’re less likely to be placed into those teams from the outside, unless you have a history of working for those kinds of teams.


Uber actually has some of the best technical writing in [datasci/causal inference](https://eng.uber.com/causal-inference-at-uber/).

These heuristics are interesting. Do you have concrete numbers for some of the big techs?


Let's say you like the Warriors. You and a group of friends get together every game to cheer for them. You're the one everyone looks to for bringing the beer, and you enjoy the group you hang out with. And when the Warriors win (or lose), there's a huge energy you get to be a part of.

I think it's the same with big companies. You can be a big part of your individual team, and it doesn't particularly feel much different than working at a startup day-to-day. And as a bonus you get to be a part of the large-scale wins and loses. Much like how it's exciting when the Warriors win, it's exciting when something big comes out of your company. Even if you did nothing but cheer.

Everyone is expendable. Travis, the founder and CEO of Uber, was expendable. So are people at large companies or small startups. But within your team, you get to do good work, and it doesn't feel that way.


Much like the Warriors in the last year, it's hard to ignore your team taking losses, especially when success was so easy in the past, and thinking about finding a new team if things don't improve.


> Travis, the founder and CEO of Uber, was expendable.

I didn’t like the way he conducted himself or ran his company, but the jury is still out on that. TFA is about how that ball is still currently in play.


Definitely. The company just felt bloated. Feature teams needed 7 or 8 people working constantly on single screens that would be an afterthought in an MVP, just to keep up with the constant changes in architecture and infrastructure. Lots of over-engineering and NIH from veterans that didn't want work on teams. Lots of rewrites due to performance issues. All that without any noticeable change for the customer (other than the website becoming slower). VCs and middle-management kept asking for more developers, though, so everyone was happy, but the general perception was that we would do just as well (or better) with a half, or a third of the staff.


All developers are expendable. If 5% of all developers at any of FAANGM's got hit by a bus, the company would keep moving.

I work at company with less than 100 people, I know where many of the bodies are buried, etc. But if I get hit by a meteor tomorrow, they would send flowers to my wife and open up a req and keep moving.


> But if I get hit by a meteor tomorrow, they would send flowers to my wife and open up a req and keep moving.

You don't have a group life insurance policy through your company? Sudden unexpected death is exactly what that supposed to cover. If not, that's unfortunate, especially since it's fairly common among white collar jobs at least.

If you do, it should cover at least your funeral costs, which should be pretty minimal if your cause of death is meteor strike. It would likely cover a percentage of the income you would have earned for your remaining years of work.

But opening a req seems totally reasonable when you are demonstrably not coming back.


Group life through most companies are 1x salary. That amount is a pittance to buy on your own.

But the point is everyone is expendable. I worked for a company around 2009. They laid a lot of people off that had more seniority than I did. I wondered why they kept me around.

Three months later I found out. The founder had written a bespoke development tool chain in C++ using MVC and assembly. The board push him out and the CTO told me that I was now responsible for maintaining the tool chain because I was the only one who knew C++ and assembly.


> But the point is everyone is expendable.

In the extremum, everyone is expendable, but not everyone is equally expendable, as your own anecdote bears out.

When you expend enough people, especially increasingly less expendable people who carry your basic institutional knowledge and skills, you do so by inflicting damage on your company or organization.

The economic winds may dictate that, as they did frequently in the 2008 economic crisis, but it's not like there is no institutional cost to expending people. This is the basically why countries like Germany and the UK are paying employers to keep idled people on payroll.


It's a double edged sword, on the one hand you have the freedom to work on interesting projects, new technologies and get well compensated. On the other hand most engineers working at uber should be able to critically think about their job and say "Is what I'm doing contributing to the noticeably to the core business or am I part of a gamble the company can afford to make right now"


I don't understand your point, can you please elaborate more? I read it twice and your comment isn't making any sense to me:

1) Are you suggesting that developers should go join a smaller company so they are less expendible?

2) Are you suggesting that developers, now that they are laid off, go work on R&D projects, tooling and open source startups?

I am so confused. What is the take away?


I'm saying that large companies in tech tend to have a large developer headcount, often working on projects outside of the core business. As such, I think those employees are more expendable.


Teams that open source stuff typically have leveraging roles, i.e. they build things that several other teams depend on.

Orthogonally, typically large companies have a maslow hierarchy of sorts: for every infrastructural endeavor, there may be a number of others that are more "nice-to-have" niche projects that aren't really critical to anyone else's ability to deliver results.

The most vulnerable employees are those on niche projects, despite these projects being internally focused (as opposed to open sourced). Infra folks whose work may be open source are typically less vulnerable because they do in fact work on critical, well, infrastructure.


I do not think he is suggesting any course of action beyond awareness that their position is less stable than it might be in other jobs.


Worth pointing that your position at a unicorn is probably more secure than at a random small startup.


Ohh....I get it now. Jeez, I need more coffee.

I've always worked in manufacturing so people aren't that easily expendible. Takes a long time to train someone and without them, one of the line shuts down or gets less productive / slow.


How long do people usually stay at your company?


Average is probably 8 years.


I worked for small and big. Everyone is expendable. Running lean or efficiency is not something those companies optimize for. That's why they have so many employees. They optimize for growth. Until something bad happens.


I've noticed that, as projects or entire companies grow, the effort spent on the product decreases relative to the effort spent on things _about_ the product.

Effort spent on building specialized libraries, tooling, secondary infrastructure as well as meetings, coordinating with stakeholders, dealing with outside research firms, etc. explodes while effort spent building those things that are clearly on chain delivering value to the customer grows rather more slowly.

It's really hard to decide if this is a good or bad thing. Certainly huge amounts of it can be seen as non-value-adding wankery, but it may all be in some way intrinsically necessary in order to scale up.


"Developers at unicorns:" Prato principal crystallized. Look at any big repro or any large company. There is usually about ~5 ish people that know wtf is going on. I think uber could be ran with 10 people.


> Prato principal crystallized

You're wrong, and not just about the Pareto principle.


He is probably Portuguese speaking, and his autocorrect changed the spelling.


Can confirm, I was having a hard time parsing how "main course" in Portuguese made sense in the middle of that sentence.


I wish we would take a hard look at corporate culture from a systems perspective, as self-professed systems professionals intent on "solving hard problems" and see how we ourselves contribute to the culture of disenfranchisement through our cumulative individual actions which we often attribute to "that's just how it is" rather than taking extreme ownership and fixing things in our own favour


I think for large companies this is true and by design. Companies don’t like single points of failure so by design should be able to afford to loose x% if engineers (or marketing etc).

Of course any large company with staff in the thousands or tens of thousands will have bloat. But I’d guess a lot of the engineering headcount that is not in “core stuff” are adding value. There is a lot of value to be added by making relatively minor tweaks when your revenue and costs are in the billions. Reducing a few percent server load or getting a few basis points of additional revenue / members etc can be worth multiple teams of engineers.

The company will survive if those teams are gone, but it’ll probably hurt long term growth trajectories to some extent.


https://en.wikipedia.org/wiki/Bullshit_Jobs

Through this pandemic experience, companies that were not previously forced to run more efficiently are now having to learn. Once they have figured this out, and IMO that does not take long, then there are few reasons to again carry the same amount of overhead, including employee compensation and benefits, office space, etc.

These BS jobs are not responsible for increasing revenues or decreasing costs. Eliminating them to reduce overhead is a no-brainer.


>>Eliminating them to reduce overhead is a no-brainer.

Having read David Graeber's original article and his follow up book, I believe he went to some lengths to explain why those jobs are so difficult to remove.

Jordon Peterson has also touched on this subject in one of his less controversial lectures. He uses Price's law to explain the proliferation of these jobs, the subsequent demise of the organisation when the handful of useful workers leave, and also that the remaining employees are unable to step up when this happens.

I prefer Peterson's interpretation, mainly because Graeber is quite fundamentalist in his view that a job is either bullshit or it isn't. Peterson's view is that large numbers of employees do productive work but that it is minimal in comparison to the few very productive workers.


I think there are more than just those two interpetations.

I also think more people than Graeber have been aware of the existence of BS jobs for a long time.

What is nice about the Wikipedia page is that it acknowledges that BS jobs "is a thing".

Perhaps it facilitates more open discussion of the phenomenon.

SARS-CoV-2/Covid-19 may be facilitating the discussion even more as it has forced people to consider what jobs are "essential" versus what logically can be referred to as "non-essential".

I have seen one commenter on HN raise the issue of why pay does appear to correlate with whether a job is essential or not. Perhaps this is something more people will start to think about.


Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs?

I've never been at a unicorn, but I have been at many startups. The story is the same everywhere. Almost no one is irreplaceable. When times get tight, cutting overhead means letting people go.


All the big startups hire all the best people mostly to stop them from getting hired anywhere else until they can't sustain it. Having 1000 extra developers is better than having 200, 5 person engineering teams working against them.


Well you don’t get VC money because you want to give people jobs, so yes.


The risk is the same at non-Unicorns. Look at developers at J Crew, hospitals and governments. All will face a squeeze.

These companies are beyond being unicorns though. I work at a unicorn and our whole R&D team is only like 100-120 people.


Even at Google, how many people work in advertising?


Arguably everyone from the CEO to the intern pulling gofer duty seeing as how that is the vast, vast majority of their revenue and profit and everything else is just more advertising for Google itself.

5,000 engineers for Uber. Absurd.


Anyone working at Uber, can you share how is morale in Uber at this moment? How might this affect hiring in the future when they need more people, but people don't want to go there?

Honestly, in the beginning of 2020, I was too optimistic and planning to apply to Uber around June, thinking that corona will go away


Well, everyone knew it was coming. Dara has been pretty transparent about the timelines, plus there were a ton of leaks in the news about details over the course of the last few weeks. It looks like everyone in eng got an email this morning that stated in bold italics whether they are affected or not. Gotta say I appreciated that clarity.

But the day's just starting so I don't really have a grasp on what teams are still around yet...


I don't understand why the firings are waves. Is this a logistics thing, or a morale thing somehow? Because it seems like it would negatively impact morale, more than anything.

In either case, don't feel obligated to answer given the current circumstances. I'm sorry this is happening to you and your company. I'm sending you and the other workers good wishes.


The logistics. In the best of times it takes at least a week to let go a few thousand employees. I can think of about ten things to take care of. Now multiply that with number of countries, the local laws to be handled. Add another multiplier or two for being a public company. The PR angle. And finally the unprecedented COVID-19 situation we are in, which compounds by adding a few more variables, the least of which is remote coordination.

All said and done, I’m actually impressed they got through this in under a month.


At Lehman Brothers, the waves came every few weeks. On Tuesdays, HR fired business people, and engineering people cleaned up the mess. On Wednesdays, HR fired engineering people. On Thursdays, HR fired each other.

It allows you to ramp down without pandemonium.


I don't know whether it's an urban legend or not, some HR people were asked to write their own emails firing themselves at Lehman.


If you broke labor laws while laying yourself off, would it be grounds to sue the company afterward since the actions were taken by an employee of the company?


It's a funny thought, but I have to think it'd get noticed pretty quickly that you're suing the company for something you actually did, and it'd be dismissed pretty quickly.

It'd be fun to negotiate your own exit package in that situation though :-D


A few years ago I worked at a small-ish company that had to do a mass layoff of about 10% of their employees. The only HR person had to write her own layoff letter. A few days later she had to walk back her own layoff because the company realized they probably shouldn't layoff their only HR person during a mass layoff.

I feel like a skilled HR professional probably could have communicated the error of this decision before it was taken.

Jeez, I hope they remembered to declare their base class destructor virtual.


The leadership team has repeatedly said they acknowledge it sucks to leave people hanging for weeks on end since it obviously drags morale through the mud, but that the logistics are complicated, due to the sheer number of people involved, local laws, etc. The leaks have just made it all the more stressful.


For the layoffs last year I'm pretty sure they were trying to stay under the 500-employee threshold of the WARN Act.


Not me personally but a close friend I know that works there says morale is at an all time low understandably. Luckily he wasn't fired but a close coworker of his who was the #25th employee of Uber was removed. 6+ years at Uber and was managing and running a team that wasn't deemed essential to Uber core services apparently. Kind sucks but these people are at a position where it shouldn't be difficult to find another position elsewhere.


I only speak for myself and my own observations - both morale and productivity have been low the past 2 weeks.


[flagged]


Geez, this is incredibly callous. These are real people who are losing their livelihoods.


It's gauche to say it on the day a bunch of people lost their jobs (and there's no need for the schadenfraude) but I think the underlying point is sane. Uber's business model is replacing FTEs in a a hidebound, regulated industry with gig workers (& good UX!).

If you were forecasting how this company in particular would deal with a downturn, it's a reasonable guess that they'll try to do the same thing to their own workforce, if they can find engineers willing to take on gig work. It's in their DNA.

To be charitable, the grandfather comment is a warning to think about the broader effects of the work we do, driven home by the possibility of a "what goes around comes around" situation.

EDIT: as many have pointed out, taxi drivers don't get benefits either (I originally said one of the margins Uber competes on is not providing benefits).


The reason why software companies don't generally hire contract software developers rather than bringing them on as FTEs is that they're less effective. Software development is a high-communication, high-trust activity; it's very helpful to be able to explicitly direct and manage the activities of your workforce, because otherwise they don't produce anything useful. For specific tasks that don't need to be high-trust and high-communication (eg. writing an iOS app for a non-critical part of the business that uses a public API), companies are already inclined to hire contractors.

The bigger risk with getting a job at Uber is "will they be in business in 2 years?" Tech company success tends to be binary: either you're growing and on top of the world, or you'll be out of business in a couple years. Just ask DEC, Symbolics, SGI, Sun, Yahoo, AOL, Netscape, etc.


Exactly, Uber's business model only applies to (highly) fungible labour markets. As past experience shows, you (usually) can't swap out 10 devs here with 10 devs there and expect similar results (although who knows in the future)


I don't think this is accurate. I've worked several contracts in my life, often working alongside the company's FTE developers. In every situation, we were fully integrated into the team, with the same level of access, etc. We fully participating in meetings and planning. The contracts were several months. (one as long as 18 months; it only was cut short due to 9/11) I will admit these weren't strictly software companies, and in every one of these roles, I was a w2 employee of a staffing company, not a 1099. However, I was at least as effective as their regular team members; probably more so because I could be released far more easily.


> either you're growing and on top of the world, or you'll be out of business in a couple years. Just ask DEC, Symbolics, SGI, Sun, Yahoo, AOL, Netscape, etc.

I think rather than looking at those names we might ask ourselves about the ones that managed to survive: Oracle, IBM, Microsoft, as an example

Sure, we might argue that they have not always been the most ethical companies out there, but it doesn't mean they haven't had to reinvent themselves here and there

How come Oracle and IBM got more money from Java than Sun? Windows is now "free" but MS continues to make money.

Those companies that went away seems to be mostly good examples of the Inventor's dilema. Especially SGI.


>The reason why software companies don't generally hire contract software developers

Have you ever been inside a FAANG? Sometimes it feels like red badges outnumber FTE 2:1 so I have no idea what you're talking about.


Worked for Google for 5 years. Red badges were largely confined to QA testers, physical security, and the kitchen, along with a few UI designers or engineers that didn't want to be employees because they liked the freedom that being a contractor allowed (eg. being able to work for someone else on the side). Basically everyone I interacted with on a daily basis was a FTE. Product area could have something to do with it: I was on a core product (Search), it's possible red badges are more common in peripheral products.


Your comment downplays the number of contractors at Google as if they are rare, but in reality, Google employs ~100k FTEs and ~120k contractors. It's definitely more than just QA testers and kitchen staff.

https://www.nytimes.com/2019/05/28/technology/google-temp-wo...

You may really have just been on a team that doesn't interact often with contractors, but the reality for the broader company is that contracting is a way of life for much more than just Uber.


My understanding is that a lot of those are jobs like street view driver, autonomous vehicle tester, search quality rater, contract recruiter, content moderator, con-ops (help forums & customer support), etc. That's a big portion of the company but not a big portion of core engineering teams. I'd acknowledged the existence of them in my original comment, but this article is specifically about layoffs of software engineers within Uber's core products. I maintain that someone in that position is far more likely to come in contact with other FTEs than with contractors.


I'm not sure about Google, but I know that many companies segregate contractors into other buildings. At one of my previous employers pretty much everyone I interacted with was a full time employee as well, but that was only because contractors largely did not have badge access to the office and worked somewhere else.

I think the even bigger risk with getting a job at Uber will be that some of the future employers may not be willing to consider you due to sketchy reputation Uber has as a company.


This is something I see employees worry about all the time, but I have never seen a business owner or person with hiring authority consider it. People who get to that position within a company learn to inhabit shades of grey; unless you personally did something illegal, they're not going to hold the company you worked for against you, except to the extent that they may think that people working at that company are incompetent.

I see ex-Facebook and ex-Uber employees popping up all the time at high positions within hot (and sometimes even ethical) growth companies within the valley.


Not a thing I’ve ever considered on a hiring front unless you’re famous as a sexual harasser or for pulling a Damore. Literally never heard of anyone doing this either.


"You're either a one or a zero. Alive or dead." Gary Winston from AntiTrust


> The bigger risk with getting a job at Uber is "will they be in business in 2 years?"

what's median job duration for a software engineer in startup-land anyway? I'd be surprised if it was much over 2 years...

I'd think that if your famous company goes under, folks won't generally hold that against you. Heck, I'd think people who watched it all fall apart would would have the most interesting stories (and valuable lessons about mistakes to avoid).


You seem to not know how taxi companies work. They are independent contractors except they are even more at a disadvantage. They need to pay money upfront for their shift and spend half their time earning that money back before they even make money. And they have no benefits.


> Uber's business model is replacing FTEs

Where are taxi drivers employees with benefits? At least in New York, they're mostly independent contractors. (A minority are sole proprietors.)


Check where they unionized more?


New York is probably one of the most union heavy places in America. Checking where they are unionized more isn't an accurate reflection of the rest of the world.


NL.


Look more at car service companies (Uber's original service), not taxis.


Why? For the vast majority of people, Uber is a taxi service.


The reason is that car service drivers are also being replaced and they are more likely to have been FTEs.


Great, I think you came up with the simplest solution: Uber should make whatever single digit percentage of total drivers that comprise their Uber Black drivers FTEs.

This might be a good selling point for the higher levels of Uber service: You're getting a full-time, professional driver who's been thoroughly vetted. It's not just some random person with an app.

I think for the vast VAST majority of riders, the "random person with an app" is good enough. In the age of turn-by-turn directions, rides are commoditized. A hundred crimes per year divided by billions of trips per year represents decimal point percentage crime rate — which is a risk not all that different from aircraft crash statistics, or even car crash statistics.

I know I definitely prefer to save tens of dollars per ride vs the services provided by some platonic ideal of a "professional driver".


> one of the margins on which they can undercut competition is not paying benefits

You think minicab firms paid benefits before Uber?


A large portion of taxi drivers are independent contractors.


and they dont' pay % of their revenue to the 'base station entity'.

This Uber trick: taking % of the revenue for the fixed cost service (they provide to the taxis drivers ) is the master trick making uber money.

So far, in Europe, all taxi corporations charge taxi driver FIXED (quite small 100..200 usd/month) amount for operating telco/web/radio and coordinating fleet of taxis.

Uber's ability to push bulshine here is really business milking 101 course: Fixed costs, uncaped incomes.


> and they dont' pay % of their revenue to the 'base station entity'.

Unless they own their own medallion, they pay "medallion rent". They'll also pay dispatch fees. Many taxi drivers switched over to being Uber drivers because they could earn (and keep) more money, not less.


So are cab drivers.


[flagged]


Sure, but do you feel the same way about AirBNB, Google, Facebook, Apple, every major auto manufacturer, Tesla, Amazon, and myriad of other companies that behave in unethical ways?

I can't think of a single tech company that hasn't engaged in some eye brow raising behavior.

There was even some controversy with YCombinator funding a fantasy sports betting company.


I'm a little more nuanced in my analysis than the GP, but yes, I do feel that way in some degree about all the companies you mention, and how the employees have some incremental responsibility for the bad those companies do.

Offered rents in Vancouver have dropped 15% since the pandemic took hold and AirBnB became a dead business for a bunch of mini-hoteliers. If you helped build that software, then I hold you a little bit responsible for the crisis in affordable housing we've been struggling with, that AirBnB has contributed to.

If you work at Facebook, then I hold you a little bit responsible for the consequences of the 2016 U.S. election and Donald Trump's presidency.

Your share of the responsibility is likely tiny, and I'm not going act like you're a mass murderer. But at the end of the day you were part of the machine that left a trail of damage in its wake, and I won't ignore that just because you were merely a cog.


I get your point, but any culpability on their part should not cause us to withhold compassion and empathy to a person losing their livelihood.

Being laid off sucks.

I can't imagine what it's like to be laid off during the worst economic period in US history since the great depression, AND to have people bag on you because you were employed by a company they didn't agree with.


Are you sure it's AirBNB, or the general economy dropping? RE values and rents as a knock on result have been dropping everywhere as demand ($$$ to pay for rent) has dropped globally as peoples jobs are lost and people move in with their parents or similar and drop leases fairly suddenly.

When you really research how much AirBNB is part of a housing market, it's minuscule. One or 3 condo buildings can usually cover whatever supply AirBNB put into alternative demand markets. AirBNB is a convenient scapegoat in most markets, because it diverts attention from building more supply and all the NIMBYs blocking it.


Yeah.

AirBNB has destroyed the rental markets of 100s of metropolitan areas. If you're working there, then you helped that.

Facebook is the sole reason we have AntiVaxxers, Trump, and fake news in general. Working at facebook, you're supporting that.

Apple I don't really have a beef with.

Amazon has killed people in it's factories, and if you work there you are in some part responsible for those deaths and the destroyed small businesses.

You can work where ever you want, as is your right. But by you working at a company, does not make you immune from being responsible for the company's actions. You have a choice of where you work, and if you choose to work there knowing the bad things the company does- that's on you.


> Apple I don't really have a beef with.

I'm curious if this is because you agree with everything they've done or because you haven't really looked too deeply into it.


The cynical part of me is thinking about the people who never had a chance at a decent livelihood. Demi-employment didn't sneak up on us, we just thought we were too classy and sophisticated as workers to have it ever effect us.

This isn't the first time our generations have experienced this. It's practically the third. You should know very well by now that many of these jobs aren't coming back, and those that do are really only going to be open to people who are younger than you.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: