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 shaves 1 second off loading time. A lot of effort would go into simply making sure the change can be turned off, and verifying with unit tests, which takes time and effort.
These projects might be pointless on a small app, but in a large business might be worth millions to the company.
Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects. Your projects are also analyzed by data scientists, to make sure they're not harming the business - and if they are, your work might be thrown out, which contributes to even less visible change to outsiders.
All of these in concert slow things down, and necessitate staff.
That's a really charitable explanation and I think it explains some percentage of labor, but not nearly all of it (not even the majority of it, IMO). Yes, there is more going on behind the scenes in every company than you'd ever know about. But I think the majority of labor follows the pareto principle-- there are maybe 100 employees in every company of, say, 1000 people that do nearly all the work, and 900 employees that do very little to nothing at all at best (and produce negative value at worst).
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.
> These projects might be pointless on a small app, but in a large business might be worth millions to the company.
With enough traffic and revenue, you'll get a positive return on hiring a bunch of engineers to optimize things that wouldn't be worth it for smaller sites. With enough engineers you'll get a positive return on hiring engineers to make engineering more efficient.
It's only natural in that case that as traffic and revenue drops, the ROI calculation changes and it suddenly becomes better to lay those people off.
And that's just engineering. I can imagine that in this downturn the sales department just isn't generating new revenue. What brick and mortar business is going to advertise right now? It only makes sense to lay off as much of the sales teams as possible. You can hire them back later.
> With enough traffic and revenue, you'll get a positive return on hiring a bunch of engineers to optimize things that wouldn't be worth it for smaller sites. With enough engineers you'll get a positive return on hiring engineers to make engineering more efficient.
Very insightful! As a corollary, you should not staff up until there is something to optimize.
You probably can't "hire them back later". People who you've fired might have an aversion to working with you in the future, or simply be occupied with other work when you want them back. If you mean ripping out entire teams and replacing them with outsiders, that also has costs.
What I've seen is that salespeople are lot more fungible than veteran engineers who have a lot of knowledge of the companies system. Sales armies tend to have a lot of more junior staff too. They might not hire back the same salespeople, but they should be able to hire what they need. There will be a lot of people looking for work.
There's also reputation issues with a "hire them back later" attitude. Engineers are likely to become skeptical of recruiters from companies with a policy like that, and then you start struggling to hire anyone.
That reference was about sales employees, not engineers. I think most people realize that in larger companies the sales team and the engineering team are managed very differently, with the employees having very different expectations about the stability of their position.
> With enough traffic and revenue, you'll get a positive return on hiring a bunch of engineers to optimize things that wouldn't be worth it for smaller sites. With enough engineers you'll get a positive return on hiring engineers to make engineering more efficient.
The problem is that no modern tech company I know actually measures the ROI of this (positive or negative) so it's completely unrealistic to determine the IRR on it. In other words, there might be a scenario where it actually is more profitable NOT to do it.
Check the incentives. For corporate managers, your salary is generally proportional to the number of people you manage. Who cares if your 1000-person org doesn't accomplish anything, you're a big shot now.
On a sports team, coaches are rewarded for championships. There is no room for waste, and underperforming people get cut.
Most sports teams rosters are restricted by league rules. However coaching staffs are not, and they have grown tremendously in recent years, as have college athletic department staffs. When someone actually does take a hard look, these staffs seem exceptionally bloated and wasteful.
Ohio State lists 458 people in its athletic department. There are 192 faculty members in Ohio State's English department, with a support staff of about 50.
One assistant coach is called the recruiting coordinator, but he’s backed by a Director of Player Personnel, an Assistant Director of Player Personnel, a Coordinator of On-Campus Recruiting and a Recruiting Assistant. There are three video coordinators.
That is a charitable view of private equity - that it improves margins without hurting operations.
Another explanation lies in reputation mining. Think of it like doing something profitable but unsustainable.
Curious what kind of experience or data sources you base your first graph on — the Pareto principle piece makes sense. But isn’t it possible the very end of the tail is still profitable, albeit less so, than the head?
> 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.
i think it's more likely that no business will know in advance who those 100 employees that create value are. It might even be that the combination of those 100 creates value beyond the sum of them individually (lets say, they are in one team).
There are also mundane work - fixing bugs or upgrading libraries, as well as keeping up the infrastructure running.
And then there's the middle management - that comes from the mis-trust that upper management generally have for the "grunts", and this happens all the way thru the organization.
> private equity exists...
and if you look at those companies that did this - very few of them becomes the next big thing. Very few of them actually innovate. Very few of them, even survive.
Private equity is really about taking risks with a failing business, e.g. buying it really cheap, and cut the fat and ride out the storm for hopefully a better future. I dont think any private equity will buy a company that isn't failing in some ways, and try to "make it better".
Companies doing well generally aren't for sale at a reasonable price anyway, so yeah, private equity by nature buys failing firms and tries to turn them around. That's the goal of the business.
Yes, you're probably right to some extent. A lot of efficiency and velocity is exchanged in these large scale environments for risk-aversion in the form of heavy testing, supporting the ability to revert changes and requiring approvals.
I'm not personally a fan of it, but I get why it works this way. The financial loss if you break something adds up in an excruciating fashion on a per hour basis.
They don't get efficient during a downturn. They might shrink but cuts for the most part will fall on those that lost the political jousting regardless of actual contributions to the top or bottom line.
The real answer is that it's a publicly traded "tech" company that has to maintain a charade of growth. They can either give their profits back to shareholders (violating the growth charade) or they can hire more people and hope they figure out how to create actual growth.
Corona spoke up and pointed out the Emperor had no clothes.
>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 engineers to increase velocity.
It sounds wasteful until you've been with a company that outgrew its management structure. I spent many years at a place that grew from 200 to 800 people in about 3 years. We prided ourselves on the flat org and high level of responsibility. But as we approached the 500 mark, the cracks really started to show:
- 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.
It's not just approvals from managers, sometimes you need approval from a group of peer engineers just to create new routes in an (internal) API, or to launch a new cron job that will upload an Excel spreadsheet in marketing once a day with data from Google Forms.
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.
The best way I’ve ever heard this explained is to imagine a software business as a machine. Early on, it’s easy to trust - the machine is small, there aren’t many working parts and dependencies are all manageable. Making things even easier, the founders generally have control over hiring and they’re often still at the hiring friends/colleagues stage of their evolution.
Then, the machine gets bigger and the dependency graph gets more complicated. Suddenly, if you change one small part of your module, you run a very real chance of ruining something someone in a faraway department relies upon. So, the machine evolves to have things like coding standards and more formalized review processes. Unfortunately, the machine is composed of humans and humans aren’t as simple as just pulling it all apart, greasing it up and putting it back into service. So every single time you add a review step, there’s a chance it genuinely adds to quality (or removes risk). But, there’s also a chance that that change was about ego and organizational power. Then, in five to ten years, they hire MBAs to come in and lay people off.
I think you need as many approvals as your risk tolerance allows for... they're not pointless. If they are pointless then sure, get rid of them. But I don't know how you'd guess that number without deep knowledge of the business.
It is sometimes better to go slower than you could and be more confident that the product is acceptable. Approvals can but don't necessarily help with that.
You start out with a very light process. Then you have outages, or you discover that not every part of the system with appropriate care, etc. Then you put some process into place. That slows everyone down a bit... your business keeps growing, though, so "more slightly less efficient people" can capture more of the market than "fewer more efficient people" can because you have a calculation where something like 1000.4 is still greater than 101.0, so if that additional stuff getting done is worth the cost of more people, you keep doing it!
And you can cycle through this a few times. And yes, people will also cycle through "we need to reduce bottlenecks" and such, but at this point, you've been successful, you've got a bunch of money coming in, and pissing off your clients is something to be avoided, since individual efficiency is not the end goal by itself.
> So you need more engineers because you hired more middle managers?
Companies often implement more process for good reason.
The antithesis of old Facebook's Move Fast And Break Things is to have policies that ensure good security, stability, accessibility, privacy, internationalization, meeting legal requirements, etc. and that usually means processes to ensure that eager engineers and product managers actually meet those policies, instead of rushing to launch.
It's easy to scoff at process when you're a small company or startup whose mistakes will go largely unnoticed unless you suddenly go viral. If you're a Big Tech Company, accidentally messing up security or privacy somewhat means getting a front page article on The Verge detailing your crimes.
Working at Google now, there's plenty of process involves in developing and launching a thing, but I can't really say any of the pieces are without merit.
You're not hiring more middle managers because you want too, no large companies have to promote engineers to senior engineering managers to handle the complexities of approvals required by compliance such as SOC2,SOC3,ISO27001,FedRAMP, GDPR, etc.
I've worked at companies were every line of code has to be reviewed and approved by a lawyer. Yes a lawyer (usually a former engineer that the company paid to go to law school) is reviewing some dumb little javascript or python script for license and legal compliance.
> I've worked at companies were every line of code has to be reviewed and approved by a lawyer. Yes a lawyer (usually a former engineer that the company paid to go to law school) is reviewing some dumb little javascript or python script for license and legal compliance.
Jesus, what company was that? And how about libraries included... Will this lawyer now also need to go through that?
The approvals usually come from other engineers. It stems from having to modify highly-sensitive code which usually has an owner you need to work with to get an approval.
The approvals often exist for valid reasons. You can't just get rid of them. You can try to streamline the approval process but that only gets you so far.
Yelp's engineering isn't likely much more than ~150 people (I worked there ~2 years ago, maybe has grown since then but honestly, given their revenue situation even then, likely not by much). The mix there is just like most companies; you've got dedicated teams for each of their apps (which includes Android, iOS, web, business-facing, etc), you've got API teams, back office teams working on moving data around and business analytics, a very secretive abuse management team, IT, etc. Yelp also, given their age, wasn't (at some point) running their primary workloads in the cloud; they had (have?) a colo DC in San Francisco that hosted a ton of stuff, so there were people dedicated to that hardware. There was some movement to get rid of this as I remember.
Surprisingly, or hopefully not, the vast majority of the company is more directly revenue generating; sales and customer acquisition. Its spread very globally; at least as of a few years ago, the SF HQ didn't house any sales people, though I think they had an office in Oakland which did.
Point being, I always got the impression that their engineering team was very "right sized" given their revenue and product scope.
When I left last August, we had around 600 in engineering, around 900 in product and engineering.
Engineering was mostly based in SF but with satellite offices in London and Hamburg. It looks like they were expanding in a large way into a Toronto office too.
Infrastructure was around a fifth of that total but included verticals like search and machine learning infrastructure.
Yelp turned off their last datacentre in early 2018 (IIRC) - and is entirely on AWS.
You may be right. I never counted nor directly asked, that was just the number I overheard. It felt right; afaik, all of the engineering happened in SF, except one remote office in (IIRC) Germany. I know there were a few companies they had acquired (Eat24 and SeatMe) which remained somewhat isolated from the primary Yelp engineering teams (with their own floors of the building and everything), definitely possible the numbers I heard were not counting them.
That number ~150 engineers seems way too small, at most tech companies I worked at, engineering comprises 40-50% of the staff, if it doesn't something would seem very off. Engineering in this case is product, platform, IT, hardware etc.
Abuse management is usually secretive because if you publish the "rules of non-abusive behavior", you end up with a bunch of behavior that complies with the official rules while still being abusive.
Because of the value in subverting abuse systems such as Yelp ratings or Google SEO, these teams usually are handled differently with an entirely different threat model - which is why they may be referred to as "secretive".
Even 150 blows my mind. Years ago I worked for one of the top 10 EHR software makers (at the time - maybe even now, I haven't looked) and we had 1/3 the number of engineers on that system.
It's funny, as soon as you have a system that has to take into account human behavior and variety of possible inputs/states, it gets massively complicated if your goal is to try to have people not be dissatisfied with it. (and if you're trying to do it right -- or alternatively, NOT making the right decisions about that goal). People just don't behave like you think they will/should.
As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple?
No, it turns out that you have to also take into account people whose orders got delayed by the human-based shipment system, people who got coupons and they expired/want to extend the coupon, people who returned the merchandise and never got any confirmation that it was received back. Or what if someone modifies the meeting location after people accepted -- does a minor change to the meeting description trigger a re-invite or update, or not? Can meeting rooms be held by more than one person at a time? Or what if you want to tie it to the email marketing system that wasn't properly integrated or planned to be integrated -- that's another couple of engineers who have the thankless task of maintaining ETLs that constantly break whenever a change comes along.
Or in the case of Yelp, I'm sure there's small teams who are responsible for the mundane tasks of how to keep track of when a business closes, or reopens, or temporarily shut down due to virus situation -- how are the entries for those businesses supposed to be updated? We never had a field for "closed by mandatory government order" -- that's gonna take a refactor of xyz to implement, etc. etc. We have users who review things, and then those users someday die/go idle/get banned. What happens to the ranking of their reviews? It goes on and on.
(and usually, the people who take the time to think about these things in advance set themselves up for much less pain, and far fewer people needed to fix it, later)
> As an example: a retail transaction database. Or a calendar booking system. That should be really simple, right? Just record who ordered what, when they received it, who sold it, etc. Who reserved the room, who to send invites out to, simple?
I am not sure people downvoting me understand what all goes into an EHR/practice management software. Calendar booking? Yep. Billing. Oh hell. Don't get me started on the byzantine mess that medical billing is! Then there's charts with icd-9/10 hell. And then everyone you sell it to wants their own charts a little different. Patient records, insurance, I mean, it goes on. The database had several thousand tables. It was insane.
I don't mean to be flippant or unnecessarily mean, but my anecdotal experience is that many EHR systems are pretty widely derided by healthcare providers (i.e. end-users).
Maybe it's not a good thing that only 50 engineers were working on that system.
Doesn't matter to me, I'm not in that industry any more. But yes, they're a mess. But, honestly, I don't know you would make it less of a mess. People just need to accept that some systems are complicated and the more you try and make it less complicated the further from that goal you get.
There is a whole bunch of stuff behind the scenes that you wouldn't be exposed to as a consumer, such as analytics data pipelines, ad sales interfaces, etc that in many ways are more complicated and do more than the consumer facing thing itself.
An old EHR system from years ago does none of those things, doesn't do engineering heavy things like live updates with thousands of A/B/C/D tests running simultaneously with multiple clients for multiple operating systems and so on.
Often this comes down to how much money you're making. Any product has a long, long tail of work you could be doing to improve things. When you're a scrappy startup with few engineers you wouldn't even think of spending time on that stuff. But when you have substantial revenues, why not hire more engineers to work on it?
The problem is edge cases take a shitload of work via pareto principle. And if your company is small, edge cases can be ignored because they affect 1-2 users. When you're serving millions, those are thousands of users. You might be the only entity in that industry at that scale and have to custom build everything.
Yelp is a public company, and their SEC filings will give you insight into where they spend money. In 2019, over half of their expenses were Sales and Marketing, so we can infer that many of the 6000 employees are likely in roles dedicated to Sales and Marketing.
And it'd make sense that the sales team would be first on the chopping block. With small businesses under pressure, and many closed down entirely, publicity services like Yelp are a very hard sell.
Not exactly, if they just so happen to be spending a lot of money on purchases of ad-space, or advertising services.
For example, just one marketing VP with a salary of $120,000 could have an advertising spend budget of a few million.
But in Yelp's specific case, they do have a ton of sales/customer service people who most definitely are among the first to go, along with engineers who are working on projects that are not related to keeping the website from 404ing
Most consumer technology products are much more complicated under the hood than they appear to be to regular consumers.
Even most programmers -- who are well aware of the hidden complexity of the products they themselves work on -- usually seem to believe that this must not hold true for the products of other companies.
For every feature you're aware of on a random consumer tech product or service, there are probably ten or twenty more that don't concern you, that you haven't seen, or that you don't care about.
Don't forget the multiplier on how many more internal systems a company has vs its external ones. It's not uncommon at all to see thousands of engineers at a large company working on internal-only systems, covering the full gamut of every need of a large corporation. Hell, even just the facilities management systems for the office spaces are complicated.
I read somewhere (can't remember where) that Airbnb had a dedicated team of 13 engineers and designers working on the welcome email alone. Getting the CTA "just right" resulted in a huge difference in conversions.
That's a great point I always struggle with coming up with UIs for side projects, but really everything I come up with will always look cheap compared to the efforts of 13 experts.
I mean you could go work for them? McDonalds is highly optimized fast food but they have a quality issue. Breakfast and chicken nuggets are about the only thing they do well. Walmart is getting better with e-commerce and online groceries. I think that’s the future. If in were Bezos, I’d be worried about Walmart. Target needs to step up their game too especially around grocery delivery and pickup.
The question is could they have achieved the same with two people.
When I was contracting I was always surprised how outwardly similar businesses could have vastly different IT functions. Sometimes an order of magnitude larger for no apparent gain.
Speaking from experience[1] I attribute this to the "empire-building" mindset that sets in once a company gets funding.
It begins innocuously enough. It takes just one or two mid-level manager empire-builders to join the company. Thanks to the funding, the product and business want growth at all cost which means everything needs to be built and launched yesterday. The engineering-managers say well sure, I need 100 engineers. And so the game begins; the early empire-builders get promoted to dizzy heights.
It doesn't take much time for others to take notice that they need to build an empire to get promoted and every mid-level manager is hiring like there's no tomorrow. In no time you have an incredibly bloated org. In this environment not building an empire is not an option; teams with fewer than 10 members don't get new-shiny projects and are brutally sidelined.
[1] I've been on both sides. The start-up I was working in got acquired by a behemoth that had skilled empire-builders. My team got massacred. In my next gig I had learned my lessons so hired like crazy and in no time had 40 engineers reporting (direct/indirectly) to me 15 of whom had any real work to do. The rest were building random CRUD apps. In the end, realized that empire-building is not for me; I enjoy running a small tight knight team producing high throughput and impactful work.
Sales and account management are easier to hire and fire. That said I bet some engineers were let go. If you're not directly client facing or related to e-commerce, you're not essential right now.
Yes but they're the easiest to ramp up and wind down. Certain segments of the economy as devastated right now. Would not want to be a flight attendant, but airplane engine mechanics are probably still in demand as cargo flights replace passenger traffic (since we're ordering everything online now).
Logically, that would extend to people whose job revolves around signing up restaurants to marketing portals. The restaurants that have an online business are already there. Those that don't have an online business are already closed.
According to flight aware, global air traffic is down 75%. So I'd bet mechanics aren't doing so hot either unless they were dedicated to cargo.
Programmers arent as easy to replace because they already understand the system. Training takes time, and if there's not enough documentation then you'll end up contacting the previous programmers for help (I've seen it happen) anyway.
Marketing and SDRs are really easy to scale up/down; there are some things that are specific to each product but generally it doesn't matter what you are selling it is the same soft skills. Account Executives and Sales Engineers who provide long term support are a lot harder to replace though.
Engineers are easy to fire, but incredibly hard (and expensive) to hire, especially if you become known as the company that'll fire people immediately in a crisis. There's a fine line between saving money now and spending it later, and I'm sure Yelp - just like every other company out there - is trying to figure out where does that line lay.
I don't think engineers have this as a specific trait. Every worker in any occupation has the attitude you describe above.
The thing that truly influences "hard to hire" is supply and demand. With the influx of bootcamps Software engineering supply has increased and with COVID-19 decreasing demand Engineers may no longer have the luxury of picking and choosing like they used to.
I'm an engineer btw. Just viewing the situation from a realistic lens.
I am an engineer too. I've helped hire engineers at two pretty big companies before and have done all the hiring for my current company.
While the supply has increased, the number of senior engineers hasn't grown at the same pace. I know of companies who've fired even their senior engineers, but they've been hit particularly hard by this crisis (think 'business model is literally rendered invalid' level of affected). Most people who think they'll be able to weather at least the next six months will be reluctant to fire more experienced engineers, because they know how hard it was to hire them to begin with.
While some of the options might be gone, chances are people who get laid off or are still in the market will look for companies with better chances of surviving this (think Google, Apple, Facebook, etc.), so the pool of experienced talent might actually be reduced for startups.
In other words: people with 5 years of industry experience are playing in a completely different arena than more junior engineers, who are unfortunately in a more precarious situation.
>In other words: people with 5 years of industry experience are playing in a completely different arena than more junior engineers, who are unfortunately in a more precarious situation.
The logic is sound, you have a point. But I think it doesn't play out this way in reality. Maybe it's like this for your current company, but is that the general trend?
I know that during the dot com bubble bursting many years ago what you said was not the case. Could be different now but do you have any other supporting evidence?
That's actually a good data point I'd like to have. Unfortunately I wasn't in Silicon Valley at the time, but at least where I was, it didn't affect my opportunities of finding a job at all.
I was born and raised in silicon valley. It was pretty bad across the board. Tons of good programmers got killed including ones that were really solid.
Mind you the situation is different now so what you say could be right in a certain way.
I think they mean easy to fire in the sense of "easy to go through the process of firing and deallocating tasks/knowledge/etc.", not "easy to justify firing."
I believe a lot of Yelps employees are outbound sales - they cold call small businesses and try to convince them to pay Yelp money.
More generally, it's kind of amazing that any company with 178 million unique "customers" only has a few thousand people working there. I know this is the norm nowadays due to the power of computers and the Internet, but I imagine how many people would have been employed to perform the same tasks fifty years ago and suspect it would have been three orders of magnitude higher (and completely uneconomical to do).
I was never satisfied with answers like "actually it's way harder than you think" but this article helped me understand: https://danluu.com/sounds-easy/
I forget where, but somewhere I read that at large companies relatively small optimizations can be worth millions of dollars. Because of that, it's worth it for these companies to apply a lot of engineering resources to optimization problems (including developer experience).
I know you're not saying this, but I'd caution anyone against saying things like "<company>'s product is just a glorified <something simple>". It's very hard for people not working directly on a product to truly understand its complexity and everything that goes into it.
What happens is that when a pure software company is a startup it is severely constrained in what it can execute on. As it gains traction, it receives funding and revenue that allows it to invest in more people to get more done. In the beginning the marginal ROI of each hire is high, but as they grow it slowly decreases and may become dominated by communication overhead if proper structure isn't added. But as long as growth is on pace, they will keep hiring to stay ahead of the curve and squeeze as many gains as possible. When VC money is at play, management will be pressured to grow at all cost, and worry less about the downside because the investors are looking for the grand slam. There's never any shortage of internal stakeholders who will have ideas of where to put heads to good use.
In short: they have 6000 because that's what leadership thought they could afford. Obviously a 10-year bull market leading up to the current lockdown situation puts them in a rough spot.
I once spoke (well, listened) to a retired old-school Silicon Valley hardware engineer once who told me that ~80% of the projects he worked on never saw the light of day, never became products. Eighty percent, of hardware. It put things in perspective for me as a software guy.
I don’t get why this question gets repeatedly upvoted in HN. I just responded to a similar question on Airbnb in another post. Do people not work for large corporations here ? Yelp’s business model is to sell ads to local businesses. And ads don’t sell themselves. For that you need to hire army of inside and outbound sales folks in every region, geo, market. This also means there is a whole account management team who is managing relationships with the thousands of advertisers. And then there is an ad tech team that is integrating these ads, but also reconciling payments and payouts in multiple currencies. I wouldn’t be surprised if majority of Yelp’s employees are in sales, sales ops, ad ops, and advertisement side of the business
Global companies employ regional sales and marketing people, since those are typically the most effective workers in those roles. Once you start layering on countries, there are also administrative roles that get added.
Same as in any other large company: empire building and pfiefdom staffing. That is what people do. I find it curious how this is allowed to be completely, completely absent in the standard narrative on private business, and yet so ridiculously obvious to anyone that has ever worked in one.
There is this canon dogma about 'market efficiency keeping things lean and fit', which is so obviously false and disproven by every single Corp out there, and yet is allowed to stand. Curious.
Let say there are 500k restaurants and businesses that pay for services on yelp. Let’s say an average sales person services 100 of these places. You’ll need 5000 sales people.
A lot of jobs exist to cover some broken process that could be fixed but costs way more or requires a lot change to actually fix versus throwing a body at the problem. Then things bloat a little bit, but in my opinion there's a lot of things that seem like waste to an outsider that are value added when you consider the system that they exist in.
Clearly they were doing nothing useful, because despite them being laid off, I can still open my Yelp app right now and browse around just fine. Most office jobs are "adult daycare", even in tech (blasphemy, I know).
A company like Yelp needs a lot of boots on the ground type staff to work with restaurants on the sales side. Their infra may scale but that function doesn't.
Sales reps without a clue, product marketing juniors (glorified blog post re-writers), partner channel manager (like an smtp server between companies but with less reliability), crm data cleansing specialists (all needed because of the former), etc
I wonder how many engineering hours they use to strip the mobile web version of features to force you into their app. That is one reason I'll never install their app and won't miss them when they're gone.
Wait till you see that AirBnB has 14,000 employees. That's fourteen thousand! For a site that's barely a step up (in complexity) from Craigslist (which has .... 50 employees).
This is exactly why I'm having a hard time mustering sympathy for the layoffs. If anything, they will use this as a stepping stone to a more ethical career choice. I do still feel for them on a human level though.
