To expand on https://danluu.com/sounds-easy/, 10k people aren't required per se, they're there to make more money than they cost. Specifically:
- sales & billing for linkedin premium, lynda, and other paid products
- billing fraud detection, to cut the cost of chargebacks
- security, to prevent that one leak from happening again, to keep PCI compliance, etc.
- spam filtering, tuned to balance keeping paying customers (recruiters) happy with keeping suppliers (candidates with a resume) happy
- Writing new features, to keep engagement and signups up
- fixing things that keep breaking, like the email contact scraper
- testing code for new features to make sure they, IDK, don't break the signup page
- a/b testing the hell out of any and every thing
- collecting and storing the massive analytics datasets they generate daily
- analyzing daily datasets to determine which a/bs to promote
- coming up with new features
- testing anything at all
- deploying corporate networking in all the offices buildings and such
- optimizing infra costs
- deploying actual physical datacenters because the cost is cheaper than paying the profit margins of AWS
- moving back to cloud (azure) because after you were acquired, the markup dropped and the calculus on on-prem vs cloud flipped
- managing all the projects associated with above
- recruiting staff to handle all the above
- managing all the staff associated with above
- acquistions (lynda, fliptop, glint, drawbridge)
Yes, I feel like developers tend to evaluate tech businesses from the perspective of the tech that they generate, since that is the goal of a developer. It's sometimes hard to remember that making tech is simply the means to an end.
IME, you are over estimating how quickly this happens.
For me, I was well past my 10th year into the profession when this realization struck. And now, as a hiring manager, I frequently interview senior developers who are not able to explain the business goals of their software. I consider it an important part of my job to coach engineers in my org to understand the business context of their work - a benefit I got only well into my career.
Totally anecdotal, but the second I embraced business objectives and commercial thinking is when my career exploded. 3 jobs in 2 years, and my income grew over 110% in that timeframe.
A lot of my colleagues seem to get stuck in a position of being very tech focused where JIRA tickets go in, and code comes out (and not much else goes on).
I highly recommend other developers try to sharpen their business and commercial skills, even if you don't want to be a leader. You'll be able to sell your skills and influence technical decisions way easier.
Agree. I think the general shift in perspective and how the world works ( with respect to money, business, economy and people ) happens somewhere around 8 - 12 years into the society.
So for those who joined the Work force or has some work experience earlier in age that tends to happen sooner / younger.
To pull in a side topic on this very idea -- it's crazy that Congress chooses to defund and target the IRS, their own tool for revenue generation. Can you imagine how much money each IRS employee can bring in? I know there's stealth doctrinal reasons for engaging in the shenanigans, but at a practical level, cmon, we're shooting ourselves in the foot.
But it's not like the IRS is having sales people cold call Americans and convince them to send more money. Even if you take the most charitable interpretation of what taxes are (ie. you think they are legitimate and necessary at their current level), it still makes most sense to automate as much of the IRS process as possible. Otherwise those IRS employees are eating up tax resources that could be applied to other things.
You may not know there is a huge job the IRS needs people to do: audits and reviews, which are not automated. And take cases to court.
Every IRS employee who is available to review tax filings can probably bring in multiple (probably dozens of) millions of $ of incorrectly or improperly filed taxes. Tell me that's not worth paying a person's annual salary for?
Congresspeople aren't paid a commission on tax revenue. The have no particular incentive to raise funds via text enforcement vs raising rates vs raising debt.
I'm a bit rusty with my corporate finance, but internal rate of return (IRR) and weighted average cost of capital (WACC) can dictate that even if an employee is making more than what they cost, the money could still be better allocated elsewhere.
Sure, it's a simplification, but the point kind of stands -- if you have a net positive outcome after adjust for cost of capital, you should seek that capital out to make it happen. Or maybe decrease a dividend or buyback program.
The metric that tends to matter in this is ROIC, but since software/internet companies tend to be pretty "capital light", they generally already have a very high ROIC. Unless the company can deploy that money in new growth projects that they aren't already going after, or in accretive acquisitions (hard to do when tech valuations are so high), it probably makes sense to do what they are doing.
This question comes up on every post about a big tech company. LinkedIn in a global company operating commercially in probably almost every country. The "social network for work" part is easy but when you start talking about things like job listings across the world and then the sales and account management and local office management and compliance and the internal tools and billing and everything else, it's quite easy to get to 10k.
I wouldn't be surprised if they have 1000 people in the US just dedicated to sales & account management for the job listings.
>This question comes up on every post about a big tech company.
And in turn, there are always replies that justify these head counts in ways that I still have a hard time buying into.
All I have to go off is on my own experience, but I worked at a large retailer/wholesaler that had:
- 1500 retail store locations.
- Probably a half dozen warehouses.
- A couple high volume ecommerce sites (not at LinkedIn scale, but scale was a concern).
To support those operations, they employed people for:
- Staffing the retail stores and warehouses.
- Call centers for customer support.
- Sales for the wholesale division.
- Advertising/marketing for the retail division, all run internally.
- Logistics/shipping.
- Real estate.
- Merchandising.
- Inventory management.
- Product design.
- Sourcing product manufacture.
- All of the boilerplate corporate crap (HR, recruiting, accounting, etc.)
Almost all of the above had software to support it that was written and maintained in-house, including a custom built ecommerce stack.
All of the above took roughly the same headcount LinkedIn now has. The technology team writing and running all that custom software was maybe 200-300 people.
So even after I hear all the reasons LinkedIn has to be so huge (sales, support, scale, etc), I'm still left scratching my head.
>The technology team writing and running all that custom software was maybe 200-300 people.
> So even after I hear all the reasons LinkedIn has to be so huge (sales, support, scale, etc), I'm still left scratching my head.
Bear in mind that organizations, by default, scale superlinearly. If you add a team of 5 engineers, you need to add a manager. If you do that 5 times, you need to add a manager-of-managers. So to double the amount of labor to be done, you need to more than double headcount.
Beyond that, most of the big tech companies have a fleet of engineers building a product and a team 10x that for analyzing the customer experience. They're building streaming processing tools to move the data warehouse batch processing jobs into, so that an a/b experiment start and have statistically valid results within hours. Your retail operation likely can't build and deploy a planogram experiment that quickly, so there's no need to make the analysis pipeline faster.
Or they're analyzing page load times to shrink them down -- over and over again I've seen experiments proving that customers love fast UI, and hate waiting. The smaller the perf opportunity, the more effort it takes to find and fix. Where you dial in at depends on part in how big your customer base is; a 10ms perf fix is more valuable when you have 10million customers a day versus 100k.
And LinkedIn does this on like 3 platforms: web, iOS and Android. Then there's the web properties they bought like Slideshare and Lynda.com.
This can be summarized as, "I can tell you what it is, but I cannot understand it for you".
In such cases I've invariably found that the failure is on part of the person who is telling the thing - they are simply failing to communicate effectively.
They are not emphasizing the important points, they are not working backwards from the result that they want to achieve and merely listing steps to get to the result, they don't empathize with the audience so they cannot customize their narrative in a way that resonates with the audience.
This is exactly why in your 16 or more years of education with dozens of teachers, you can only name a handful that actually were good teachers.
> All of the above took roughly the same headcount LinkedIn now has. The technology team writing and running all that custom software was maybe 200-300 people.
> So even after I hear all the reasons LinkedIn has to be so huge (sales, support, scale, etc), I'm still left scratching my head.
The reason for your head-scratching is unclear. Your previous company had about the same headcount as LinkedIn.
LinkedIn, being an international company even before Microsoft’s acquisition, probably has a similar level of necessary personnel, including internal and external software development teams.
I don’t see the reason for your confusion from what you’ve written. Perhaps explicitly stating a point of difference between your previous company and LinkedIn would clarify?
My apologies, you are correct. I took some things for granted in terms of why I made the comparison, and on further reflection it probably isn't a fair comparison.
For example, I took it for granted that when I said there were 1500 retail locations that readers would realize that meant probably close to 10,000 out of the 13,000 were just dedicated to running those retail locations (that's going by back of the envelope math, as well as hazy memories of actual numbers).
Add to that probably another 1000 for the warehouses and associated logistics, and you're looking at a pool of maybe 2000 actual knowledge workers split among all of the functions listed above (sales, marketing, support, legal, real estate, merchandising, development, IT, etc, etc).
I also made perhaps an invalid assumption that the software being written to manage and optimize the: 1) design of a product 2) sending it off to China for manufacture 3) shipping it back to the states 4) storing it in a warehouse 5) letting it be found, ordered and paid for online by anyone in the world 6) and finally shipped to the end consumer.... is all somehow more complicated than the development being done by LinkedIn, and being done by only a couple hundred dev and infrastructure people.
In my mind, that felt like evidence LinkedIn might be bloated. But as others have pointed out, I'm sure there are dev challenges I'm taking for granted. And of course you need a healthy headcount to deal with the legal, support and sales operations of a company with the international footprint of LinkedIn.
I am not surprise, just amazed that a site which is mostly self service and runs on UGC needs anywhere near this many people to operate. But then again, most of the people are probably hold-overs from acquisitions. As an ex VP of Ad Sales, I dont see how they'd need this many people in sales. Its almost all automated self-serve and partner driven. Even with a large US based team to manage the big spends, you're still not needing a large staff... But then again, these types of orgs tend to be filled with a lot of mediocre talent and suffer from BigDumbCompany syndrome...
I think we’ve seen that UGC is and always has been a bit of a myth. Social media companies have always quietly employed armies of people to moderate user posts, persuade famous people and Companies to post, to actually do the posting and “media strategy” for those VIPs and companies, and then of course to sell the ads and pro services that come with it all.
I've interviewed for roles at several top tech companies and what surprised me was that there were entire teams dedicated to working on what seemed like a tiny feature or functionality. In some cases, two entire teams - one for frontend, one for backend.
Granted, I understand there is a HUGE mind boggling level of scale involved.
But still, after going on such interviews, and talking with friends who work at FAANG, etc. it sounds like my boring mediocre job as a bank SWE is more involved and exciting than some of these FAANG jobs.
But I'd still jump through flaming hoops to jump ship to a FAANG or similar tech company.
A lot of FAANG and FAANG-adjacent dev jobs are not any more glamorous than other dev jobs. A lot of the day to day looks the same, just keeping the lights on. Sometimes a really interesting technical problem does come up, but a lot of the complexity of the job is working within a huge complicated environment, both technically and organizationally.
I will say, completely anecdotally, that the average bar for competency and work ethic is higher. Day to day stuff just gets done faster and more thoroughly with more accountability. But that's just personal experience, YMMV.
I worked on cooler and more diverse stuff at various start ups and contract gigs, but I get paid literally double (or more) in big tech sooooo yeah riding it out for a bit. I don't see doing this for 20 more years, though.
Yeah, I imagine day to day work isn't profoundly different wherever you go, but rather it's intangibles like culture and work environment and working mentality that make the difference.
Most of my coworkers are simply there to collect a paycheck. Not that there's anything strictly wrong with that, but there is distinctly a lack of interest in doing anything beyond the bare minimum to satisfy technical requirements. Grass is greener on the other side, but my interactions with employees of tech companies has given me the impression that they're just a lot more enthusiastic about their work than many equivalent SWEs at companies where tech is a cost center.
The features may have limited scope but if they have an entire team dedicated to them they usually deal with large enough scale that it's worth it.
When you're dealing with distributed systems at large scale you can no longer have services be down for longer periods of time because it's a lot of money you're losing.
The business decision for employing an engineer or engineering team should be made at the margin -- that is, if the marginal revenue increase is higher than the cost of employing that team you should definitely employ them.
At large scale, a sub 1% increase in revenue or decrease in revenue lost can be multiple $M, so it would be worth having a team that only increases productivity across the company by an average of <1%.
FAANG companies can't move fast and break things like startups. If their services go down, it might be mentioned on the evening news, and it would certainly cost a lot of money. FAANGs have huge existing revenues to protect, large customer bases to keep happy, and laws to obey in all of the countries where they operate.
A "simple" feature change is not so simple for companies with those concerns.
Can't you say the same about banks and finance? Hospitals and medical tech? Software in say, cars, aircraft, ships? If anything, even more so?
I could be naive, but what is the most societal impact that could happen if say, Instagram goes down or gets a major bug? Or if something went wrong at Netflix?
Vs. software going wrong at a major bank or on an airliner?
They used that motto when they were a startup and changed it a while ago.
> On May 2, 2014, Zuckerberg announced that the company would be changing its internal motto from "Move fast and break things" to "Move fast with stable infrastructure"
I think it's also that the economics are just different. If you're evaluating a CICD tool at a small company, you're going to find something affordable and bend your process to how it works. A mid-size company might invest a bit into customizing Jenkins hoping that it will pay off in the long run. A giant company might spend millions building a fully custom system from the ground up because gaining 1% more efficiency in developer effort or even build times makes it worth it. And more than that, they may be willing to invest in experiments knowing that some will fail because the chance of success is still worth it.
From what I have seen, the internal tooling is usually worse than what is publicly available. Often times it is only used because it was built before there was anything publically available, and now all of their tooling and workflow depend on it and they can’t easily change. Plus no one wants to rock the boat and suggest throwing out a tool that likely employs a bunch of people.
And the return of investment for the change is low plus it's an extremely hard sell for management ("we'll work 2 years to get roughly where we are now and maybe get 3 minor features plus the promise of lower maintenance in the future").
I don't think that's limited to FAANG. My company needlessly reinvents the wheel, but I get the impression the reinvented wheel is more competently reinvented at FAANG than at my bank.
This might sound naive, but I would like to advocate for more employment than less. Optimizing jobs from 10k to 500 as some people in the thread are advocating seems horrific to me.
The ideal is that you would have 500 people that are efficient enough to perform 20x the work, and optimize the work efficiency, and automate some things.
What I have seen personally is that employers just overload staff. They reach a crisis point and have to hire more people. That just hurts employees and there families.
I do not want to make baseless assumptions on who was laid off. People could be laid off for something as trivial as a site consolidation and the person could not relocate, or an acquisition where multiple people had the similar roles. Using laid off status as a scarlet letter is a worrisome trend and only serves to harm all of us in the long term.
I personally do not want to live in a zero sum economy.
If you now think that all business divisions have more work to perform due to scale, and that for development, you want to have more parallel streams of work, this should give you an approximate idea of what an order of magnitude larger company uses 10k people for.
you can start to understand how crucial pricing could be to a large organization that they could dedicate a person(and a whole team underneath!) solely to pricing goods and services.
EDIT: At the same time you wonder if pretty much all jobs follow Parkinson's role: job filling up to fill up the time.
You have a whole team of talented front end guys at Youtube (or Gmail or Dropbox or ..) and front-end will change and features will be added or dropped because well something needs to be done.
So wouldn't this same principle apply to other jobs? Pricing Manager would keep fiddling with prices if there is nothing else to do. Obviously there would be justifications to higher ups.
Last year LinkedIn made $6.8B in revenue. If they hire someone who can make a process .01% more efficient, they would save $680,000. If they pay that person even $400,000/yr plus benefits, they are coming out ahead.
If you find someone who can make things .002% more efficient and pay them $100,000 a year, you've still come out ahead.
At that revenue, it doesn't take much to get an ROI on a new employee.
Making "a" process .01% more efficient is not sufficient in your example. You need (the weighted average of) everything to become that much more effective.
Somebody improving e.g. the build speed by that amount will not be paying back their salary in improved productivity of other developers. While a person who increases the click through rate on ads by 0.02% probably does.
> I can't think of a single large software company that doesn't regularly draw internet comments of the form “What do all the employees do? I could build their product myself.” Benjamin Pollack and Jeff Atwood called out people who do that with Stack Overflow. But Stack Overflow is relatively obviously lean, so the general response is something like “oh, sure maybe Stack Overflow is lean, but FooCorp must really be bloated”. And since most people have relatively little visibility into FooCorp, for any given value of FooCorp, that sounds like a plausible statement. After all, what product could possible require hundreds, or even thousands of engineers?
> ...
> Businesses that actually care about turning a profit will spend a lot of time (hence, a lot of engineers) working on optimizing systems, even if an MVP for the system could have been built in a weekend. There's also a wide body of research that's found that decreasing latency has a signifiacnt effect on revenue over a pretty wide range of latencies for some businesses. Increasing performance also has the benefit of reducing costs. Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize.
> And that's just performance. Features also matter: when I talk to engineers working on basically any product at any company, they'll often find that there are seemingly trivial individual features that can add integer percentage points to revenue. Just as with performance, people underestimate how many engineers you can add to a product before engineers stop paying for themselves.
> Additionally, features are often much more complex than outsiders realize. If we look at search, how do we make sure that different forms of dates and phone numbers give the same results? How about internationalization? Each language has unique quirks that have to be accounted for. In french, “l'foo” should often match “un foo” and vice versa, but American search engines from the 90s didn't actually handle that correctly. How about tokenizing Chinese queries, where words don't have spaces between them, and sentences don't have unique tokenizations? How about Japanese, where queries can easily contain four different alphabets? How about handling Arabic, which is mostly read right-to-left, except for the bits that are read left-to-right? And that's not even the most complicated part of handling Arabic! It's fine to ignore this stuff for a weekend-project MVP, but ignoring it in a real business means ignoring the majority of the market! Some of these are handled ok by open source projects, but many of the problems involve open research problems.
> There's also security! If you don't “bloat” your company by hiring security people, you'll end up like hotmail or yahoo, where your product is better known for how often it's hacked than for any of its other features.
> Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years1. When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever. But when doing the math on how many employees a company “should” have, people usually assume that the company is an efficient organization.
This is the same fallacious statement in reverse. You couldn't build LinkedIn in a weekend because they do a lot of things you don't see. Also, when they fire a bunch of people, it will affect a lot of things you also don't see.
Could someone compare today's and yesterday's Wayback Machine results for your company's website and demonstrate the value everyone at your company generated today?
The GP post was a wall of text basically explaining how you can't run a large website without tens thousands of staff. Surely it would fall apart if you suddenly cull 10% one fine Friday?
I've worked at lots of companies where the product isn't optimized, it didn't handle Chinese or Arabic queries, or there were organizational issues. These things don't make a company fall apart suddenly, although they could be impediments for growth.
Don't know what consequences you specifically mean here, but some projects won't get done, some sales won't be made, some research won't pan out. Some institutional knowledge will be lost so the next rev won't go as quickly.
There will be many consequences, just perhaps not obvious for those on the outside looking in.
Except the original comment wasn't that. At all. It was a genuine question because a lot of us aren't familiar with these tech giants and how they're structured.
To me LI is a tower of Jenga. Years of growth, mutliple acquisitions, M&A and almost no downward market pressure put them into this position of bloat. But your points are good, very very good. It take a lot of people to run a large org. But that's not always the best way...
Delivering the part of LinkedIn which provides value to end users is relatively trivial. A small number of engineers (20-30) could do that. The problem is ironically how much profit they make.
Look at ad-blocking for example. You as the user won't see how this affects LinkIn, but they likely devote dozens (hundreds?) of employees to fighting ad-blockers and optimizing the site so people don't notice how their anti-ad-blocker solution completely destroys performance. But as a company that kind of investment in staff is profitable because the cost of those engineers is vastly lower than the cost of losing 1% of their advertising revenue.
Likewise, ad fraud, and a dozen other issues which might impact LinkedIn's revenue flows. When you hire your 4000th developer, they aren't providing as much value to the company as engineer #50, but they are providing enough value to cover the cost of employing them (at least net, it's likely 50% of them at that point are dead weight but hard to identify).
Multiply this kind of decision making over 500 other decisions and engineering "Bloat" makes a lot more sense.
And that's before you start adding in things like sales, HR, marketing, etc. Remember, each additional person doesn't need to provide as much value as the first 50, they just need to provide $100-500k worth of value.
I know that one of my friends got a swag box (card, candle, and a metal water bottle) from LinkedIn when he got hired at a company that used LinkedIn's recruiting services. I'd imagine there's a lot of other random things they do at low scale to excite their customers.
They didn't say anything about whether it merits 10k people, they were curious what all those 10k people are doing. I'm curious about that as well - clearly LinkedIn is doing much more than I was aware of.
Neither craigslist nor POF generates 7 billion in revenue. Latest number I can find for craigslist is around 700m in 2016, let’s assume it’s 1b now. And let’s assume they have 1 employee. You don’t think hiring an additional 10k employees to get an extra 6b in revenue is worth it?
CL has approx 50 employees, operate around the globe and are on track to do in excess of 1b in revenue this year... So I disagree with your assessment.
There are many businesses that operate in the 10figure range that dont require 10's of thousands of employees.
To me LI is more indicative of bloat. Especially since they are owned by MSFT.
Yes but can they scale to 7B with 50 employees? And specifically can they run a business like LinkedIn with 50 (or 500 or whatever small number) employees.
I would argue the answer is no. If CL has a way to scale to that kind of revenue you'd think they would be doing it. One possible answer is the business they run just doesn't scale like that regardless of how many employees they have so it's better to keep things lean.
I'm all for running a lean business, and there are certainly plenty of examples. CL, Stack overflow, POF etc, and they have impressive revenue to employee ratios. But they don't necessarily scale linearly, and they don't have to. CL has 20m revenue per employee, that's impressive. But they likely won't be able to carry that ratio up to 10b in revenue. They also don't need to. The additional employee just need to bring more revenue than they cost.
If someone knows how to run a multi billion dollar global business with 50 people (and more specifically if they know how to do it with linkedin), there will be plenty of people lining up to talk with them and giving them money to do it.
I a medium size vertical software company I worked at no more than 20% were software engineers when it reached the mature stage. Some were software support people like program managers, testers, technical writers, Training. Some were company support like executive, HR, sales, IT. And then were services side of People who used the software embedded within customer companies because the customers wanted to outsource that role.
Besides the usual, LinkedIn is running an e-learning operation for business these days (LinkedIn Learning), and generally trying to be another vehicle through which Microsoft expands its offerings — moving away from simply being the "recruiting" social network and instead moving to be the social network for every phase of your life as an employee.
Its mostly self-service and partner driven (programmatic). As an ex VP of Ad Sales, I just dont see the need... My guess is that they have several thousand offshore devs and a lot of fat from acquisitions.
