4 ms·

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

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.

meditativeape 6y ago
These heuristics are interesting. Do you have concrete numbers for some of the big techs?
gen220 6y ago
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.
datadem 6y ago
Uber actually has some of the best technical writing in [datasci/causal inference](https://eng.uber.com/causal-inference-at-uber/ https://eng.uber.com/causal-inference-at-uber/).

meditativeape 6y ago

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

gen220 6y ago

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.

datadem 6y ago

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