But you ask how they can productively use the time of 10k people and I think this post is sort of evidence that they couldn't.
Software is supposed to scale almost for free, they don't need people to actually make the transactions and push the bits by hand, this is all automated.
My guess is they have a lot of sales and an enormous amount of overhead.
According to Price's Law about 100 people are doing half of the work, but of course it is difficult to guess which ones and they still need the other half to be there.
Sure, that may be true, but startups don't suffer for lacking of scaling ability.
Software does not scale with changing requirements for free. Full stop.
They must have changed something either on their product or on their procedures on those 5 years.
That's not overhead, it's business.
Software people think that they're crucial. They are in the sense that the thing has to be built.
But if nothing is bought, the business goes under and the software is scrapped.
"The overhead" makes the business work, makes people buy it and continue using it, helps them when they don't know which buttons to push, which integrations to use, etc.
I work for a 100k-employees company. According to the internet, a third of it are engineers.[1] I think I can explain.
First of all, I think the AAA game example is bad. Most of my acquaintances working in the gaming industry work long hours for a crappy salary compared to their skill, because most of them are passionate.
Most business software is written by overpaid engineers who see the whole thing as a 9to5 job. So you can already divide the amount of hour worked per employees by at least 1.5 if not 2.
Even then, if you take something which seems as simple as Shopify the system can be made complex for managers and directors to justify headcount.
It's an e-commerce website, right? So you can split 100 engineers over 5 teams. 10 "production engineers" (or SRE/DevOps/SysAdmins) and 10 software engineers for each team: - Product search team; - Payment team; - Authentication team; - Admin UI team; - CRM team.
Once you have 100 engineers, you can multiply your headcount by 10 by just splitting each of these teams into five more. If you take the Payment team, you can create a credit card team, a paypal team, an alipay team, … For product search, you can create a team to manage just the suggestions of the search bar, another team which optimizes term matching with products, another team which does the list of related products on the side bar, …
I just found jobs for 1,000 engineers, right at the top of my head! Now you have so many engineers and so many customers, you also need internal tools. You need an internal tool to manage customer refunds, customer support, etc… You need HR tools for vacations, performance review, …
Of course all of this comes with waste, but who cares as long as you're offsetting it with your revenue? ¯\_(ツ)_/¯
Anyway, this is why I will never be a business person :) .
[1] https://earthweb.com/how-many-software-engineers-does-google...
I just got laid off from a ~1.5k-employees private company that applied the same method to split up a large monolithic cash cow (crafted from scratch by a small clique of hackers who met early in life) into microservice and microfrontend internal products because it looked like a good long term plan in Q2 of 2020 and we thought we could scale that forever and start selling our dog food as a service.
Something went wrong, and we hit a ceiling very early. The amount of waste that was generated by the rigid management ecosystem that was created to sustain such a large scale up (for tracking purposes) became so strict that any and all attempts to use the scientific method to solve anything by the then-outnumbered engineering staff became impossible to justify to any non-engineering roles.
If the task didn't fit in a 2 week sprint, it couldn't be planned.
If it can't be planned to be shipped from scratch in a 2 week sprint, from analysis by both your BE and FE devs to both of them shipping at the same time by end of the sprint, it couldn't be done.
If you needed to solve for "what do people wish they could buy?" instead of optimizing for "what are the most humans currently using?", it couldn't be done.
We constantly regretted not sticking to our engineering principles.
The system collapsed. A lot of nice-to-have-but-working-at-a-distance positions were eliminated, as well as a few individual contributors that management hadn't realized were important to their core functions but were hired too recently and didn't have time to adjust to the point system.
I wish I could tell you what happened next, but the layoff happened. Most of us thought it would happen because management would finally realize the (human) system was designed poorly and without a good feedback loop while growth happened. But it turns out they might have only reverted to a previous commit of the organization structure and are still intent on trying again with the same rulebook.
Slower but infinite growth is still the objective, excessive tracking is still the norm.
Their marketing had been doing poorly in recent years, and the layoff wasn't even mentioned in the news, but it seemed like it affected a lot of devs in my neck of the woods despite the near complete lack of media coverage.
Does this happen often? Is this what scaling up always looks like?
Happy marriages are boring; They all look the same.
Whereas each unhappy marriage is uniquely unhappy.
See this video by Casey M. https://youtu.be/5IUj1EZwpJY
This is the problem. IDK about Shopify specificially, but a lot of these companies don't have revenue, or it's far from offsetting their expenses. That was OK as long as more venture funding was readily available; today that's not the case.
If you're looking at big tech, telco, banks and finance, there are a lot of companies where headcount waste is offset by revenue. Many of which are even making profits. According to wikipedia, shopify had a net income of ~$3B for ~$5B of revenue in 2021.
They're likely predicting eCommerce growth slowing a bit (combination of post-COVID & reduced consumer spending), so pushing for better fiscal discipline & improving net margins going forward.
I think the complexity demonstrated in your post is a reasonable explainer for why companies like Salesforce and SAS are so highly valued - it stops a lot of those teams needing to exist at companies for which proprietary tech isn't a competitive advantage.
The way the calculus works for Internet-based SaaS is: say you have revenues of $4B (like Shopify), and an engineer costs $400K. If the engineer works on a project that improves sales by 0.01%, it's profitable. If a team of 10 engineers works on a project that improves sales by 0.1%, or 100 engineers improving sales by 1%, it's profitable. How many 0.1% opportunities do you see in the product? How many 1% opportunities? What if you add risk? An engineer might fail to see any effect on 4 of their projects, but if they improve sales by 0.1% on the 5th, they've still made the company twice as much as they cost.
It's hill-climbing. There are usually lots of 0.1% opportunities available with a big worldwide SaaS. Things like localization and entering new markets will generate way more than that; even things like moving around CTAs and changing colors will usually generate more in profit than the engineer costs.
Also add to that diminishing marginal productivity of each engineer. In a team of 5 moving a button around takes an afternoon. In a team of 1000 it often takes a couple quarters, because you need to get sign-offs from all the teams that the code touches, run it through QA, and gather metrics to show you didn't regress anything. The engineer is still profitable, because the effect of their change multiplied across millions of users is way more than their salary costs. But they're not as profitable, because they work so slowly.
At Supercell, they have some old titles generating around 400K of revenue per day, with a minimal team working on new features, fixing bugs, looking after numbers and trends, managing ads... All of that with less than 15 people.
Of course this is not the same scale, but they have a LOT of daily users, and at their peak the company was about 200 people.
And I've been there, I can tell you that there is ample slack, most of them are barely working.
Probably lots of money could be made with better support.
Microsoft seems to do it thr correct way - I worked at a "boring" company that had a lot of licenses and we had highest tier support - we found a bug in Excel (!) and they fixed it.
If you are a small fish you wont get any support and often not give money. I wonder if this doesnt add up.
They took a big bet on global growth and this would've exploded HC related to sales, marketing, compliance, recruiting, etc. They pulled hiring forward on an expectation that the market advanced 5 years during COVID and now have to cull that new growth. Lots of late stage private companies and recent IPOs are going through the same thing.
More general, we had the 2008 financial crisis after one not too big investment bank went under. Covid did, despite all the real world damage from lost lives to the economy, not doing anything like it. I always wondered why, aparently more free money, on top of all the free money we had since 2008, helped. I just hope that the postponement of hitting a wall doesn't mean we ginna hit it much faster. We'll see...
I'm in a well run, immensely profitable, 100+ yo company, so big a country needs us to run, literaly, and a few others would be destroyed if we suddenly closed shop and ran with the money.
We are 60 000 and feel too fat. I cannot understand what frigging shopify is doing with 10k people. We make 5bn a year profit these days, is shopify close to 1?
Edit: waoh, they indeed were at 3 bn last year, 300mil the year before, -100 mil before, without reading the details. It's not regular profit but if it was, it'd just confirm we're too fat, not them :p
Microservices.
I haven't worked there, but I've worked at incredibly similar companies with the same scale.
Every single business function split into fine grained services, with teams of size 5-20 (larger teams have split services, oncall, etc.)
Auth, API gateway. Layers of devops teams. Traffic, monitoring, data store, many different analytics support teams. Kubernetes maintenance.
The payments platform is probably huge. The app teams too.
Infosec of various flavors. Vendor integrations...
Think about the sprawling functionality of a company at scale.
Anyone else is sales or support. And other business functions, like various legal departments.
10,000 is the right size for an org like Shopify.
The people on those teams undoubtedly have plenty to work on.
Sales and support basically scale arbitrarily large, as long as the market is there.
Scale is harder to manage as the userbase grows. A lot of popular services could run on one machine if you can live with 3 nines of reliability and never scale past 100,000 users.
When you reach that scale, you also start doing lots of product work that's either exploratory and unlikely to matter, or micro optimizations trying to move the needle 1%. If you hit a win on one of these, because of your scale, the win can be huge.
I've seen large companies and it's astonishing how little work and how much process they have for minuscole changes.
The only productive way of managing this is do what Google or Amazon do: split in sections and teams and get them to do something independently, with the hope that someone will struck gold. It's a bit like a venture incubator and - sometimes good things come out of it, most of the time dead products come out.
The company where I'm currently in is ~200 engs and a few companies ago with 50 engs was easily 10x more productive and had a way bigger codebase.
Management is either too useless to care / too attached to saying they have N underlings and the business makes so much money they can afford to spend x% on tech workers, just to be safe.
Let's say that each product dev team is about 80 engineers. Let's double that number for support, HR, admin, etc. Let's add a team of 10 people for sales ( not needed for internal products but hey)
Now let's round it up to 200 heads.
That would make 50 large software products, is that right?
I feel like most of you all are unaware of the complexity and scope of Shopify...
The former had some stressed principal engineers, the latter was terribly inefficient and people had 1% productivity.
There is a happy medium, but nobody can manage a large headcounts without splitting in a lot of tiny products.
The core product of shopify is not something that needs 10k engineers for maintenance, even if they can afford that.
I.e. a team that is working on only Facebook Messenger back-end, a team working on Facebook Messenger Front-end, a team working on Friend Recommendation, etc.
Each of these teams is let's say 10 Dev, 2-4 QA, 1 Product Documentation, then all the normal overhead of HR, etc.
From what I can see they are providing software and services.
Even the biggest software teams I have seen were rarely larger than 50-80 people.
And they were working on large complex codebase for AAA games.
Of course you need support, admin, HR, and sales, and R&D on new projects, but still.
How can they manage to productively use the time of 10000+ people?
What are they doing?