161–170 of 317 posts
I know this is a very tired topic, but does anyone have any good blog posts or articles about "what exactly is it that you all do?" Yelp having 6000 employees. I'm not surprised, I'm not mad. I just want to understand.
Yelp's business model requires a lot of cold calls to small businesses.
Earlier quoted context omitted.
Look layoffs are always shitty, and Yelp in many ways is not an ethical company. However if you read the actual post, the leadership is at least trying. The CEO is taking no pay, execs are taking pay cuts. They've cancelled projects. My guess is that their revenue has tanked to near 0 and that since many of their clients are closing, possibly for good they're expecting significantly lower revenue for the next 2 years…
Yup. I don't like Yelp, but in this situation the choice isn't between layoffs and no layoffs, it's between layoffs and bankruptcy. And in bankruptcy you'd see massive layoffs anyway. There's not really even a choice here.
Good riddance to an exploitative business.
Please explain.
They will prominently display ads containing positive reviews for competitors on a business's page unless that business pays Yelp.
Earlier quoted context omitted.
I wondered this before joining a large tech company. As it turns out, a lot of engineering is done on experimentation to optimize the product. Only a small portion of users might see the experiment, and many don't succeed. An example might be complying with food and alcohol law in a single region, which you would never see unless you lived there. Another example might be a complete experimentally gated refactor that…
>Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects. So you need more engineers because you hired more middle managers? That's a little absurd in my opinion but I am likely wrong in this assumption. It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more enginee…
Also, UX wants to see the final result on their screen before they approve your build, so before deploy you have to push into a test cluster, but there are only 10 of those, and you need to wait until one of them is free.
And of course your Jenkins server takes 2h to build and fails sometimes, so pushing small changes takes 2h because you have to babysit the build. The testing cluster above also takes 2h to build. CTO believes in engineers taking care of their code, so SRE is not allowed to handle the builds.
And then there's an average of 2h of meetings per day (I'm not including the 40 minute daily scrum because your squad has 15 people). Half of them to discuss the production incident you had because you didn't see the Slack alerts when you were in another meeting. The other half is chapter and guild meetings where you don't talk, but participation is mandatory. On Mondays you have sprint planning, so forget about coding.
Engineering fact: A 300 watt amplifier is only twice as loud (+10 dB) as a 30 watt amplifier. The same math works for engineering teams.
Earlier quoted context omitted.
I wondered this before joining a large tech company. As it turns out, a lot of engineering is done on experimentation to optimize the product. Only a small portion of users might see the experiment, and many don't succeed. An example might be complying with food and alcohol law in a single region, which you would never see unless you lived there. Another example might be a complete experimentally gated refactor that…
>Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects. So you need more engineers because you hired more middle managers? That's a little absurd in my opinion but I am likely wrong in this assumption. It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more enginee…
Earlier quoted context omitted.
I wondered this before joining a large tech company. As it turns out, a lot of engineering is done on experimentation to optimize the product. Only a small portion of users might see the experiment, and many don't succeed. An example might be complying with food and alcohol law in a single region, which you would never see unless you lived there. Another example might be a complete experimentally gated refactor that…
>Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects. So you need more engineers because you hired more middle managers? That's a little absurd in my opinion but I am likely wrong in this assumption. It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more enginee…
- Things truly requiring management handling (like raises, big expenses, hiring, etc.) took FOREVER in the best case because of the bottleneck at the top. More commonly, they got lost/dropped without explanation.
- Flow of sensitive information was slow and inconsistent because the only way to communicate with a flat org is all-or-nothing.
- Specialist engineers found themselves trying to track too many projects before they realized the overload was a problem (this was me)
- The president (and effective sole owner) was still deeply involved in all projects and regularly exercised veto rights. As the project load increased, the vetos landed later and later - some times after we'd already spent 50% of the budget! This left our customers up a creek and our reputation suffered.
While job losses will pile further misery on the economy, I hope that means there are now fewer ad sales people trying to shake down local businesses so that they offer Yelp protection money to keep their ratings positive. Companies like this always start with a noble purpose, before the pressure to monetize causes them to ruin what was once a valuable service.
I know this is a very tired topic, but does anyone have any good blog posts or articles about "what exactly is it that you all do?" Yelp having 6000 employees. I'm not surprised, I'm not mad. I just want to understand.
I wondered this before joining a large tech company. As it turns out, a lot of engineering is done on experimentation to optimize the product. Only a small portion of users might see the experiment, and many don't succeed. An example might be complying with food and alcohol law in a single region, which you would never see unless you lived there. Another example might be a complete experimentally gated refactor that…
Why that is the case in every business, I haven't been able to figure out. I suspect it's because when businesses reach that size, the efficient market effects become greatly overstated in the short term, so these businesses naturally acquire a lot of fat.
One piece of evidence for this is that private equity exists. You can buy a business, fire a quarter of the people, then sell it and make a lot of money without hurting the operations at all.
Earlier quoted context omitted.
Yelp is accused of predatory practices on business owners including pushing them to sign up for a paid subscription to hide negative reviews on their Yelp page. Otherwise, you are vulnerable to their algorithm which hides/shows reviews that are often less than favorable. Yelp reviews are now overtaking business' own pages on Google searches leaving businesses with less option to control, let alone, curate their brand…
They're not just hiding negative reviews if you pay, they are hiding legitimate positive reviews if you don't. It's simply the online equivalent of the mob asking for protection money.
Earlier quoted context omitted.
I wondered this before joining a large tech company. As it turns out, a lot of engineering is done on experimentation to optimize the product. Only a small portion of users might see the experiment, and many don't succeed. An example might be complying with food and alcohol law in a single region, which you would never see unless you lived there. Another example might be a complete experimentally gated refactor that…
>Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects. So you need more engineers because you hired more middle managers? That's a little absurd in my opinion but I am likely wrong in this assumption. It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more enginee…