4 ms·

> 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. […] How can t

> 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. […] How can they manage to productively use the time of 10000+ people? 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-have/ https://earthweb.com/how-many-software-engineers-does-google...

rekrsiv 4y ago
I like this perspective a lot. 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?
- specialist 4y ago
  Paraphrasing, from memory: Happy marriages are boring; They all look the same. Whereas each unhappy marriage is uniquely unhappy.
SoftTalker 4y ago
> as you're offsetting it with your revenue 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.
- acatton 4y ago
  I believe that you're biased by HN, since a lot of the discussion here revolve around over-valued VC-money-roided-up startups burning millions of dollar per months. 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.
- beambot 4y ago
  SHOP: $4.8B in trailing 12-month revenue, growing 70%+ YoY for last few years and $250M in positive free cashflow. 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. https://finance.yahoo.com/quote/SHOP/financials?p=SHOP https://finance.yahoo.com/quote/SHOP/financials?p=SHOP
hoten 4y ago
Not even to mention the impact Conway's Law suggests! As a company grows in number of specialized teams, you'd expect to see magnifying difficulty in having efficient communication, eventually impacting what the product looks like (or at least, how robust the code is and how easy it is to augment). Seems like it could be a bad feedback loop - code got more complex indirectly because of number of teams, so naturally you hire more people to maintain the same output. See this video by Casey M. https://youtu.be/5IUj1EZwpJY https://youtu.be/5IUj1EZwpJY
petercooper 4y ago
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, … 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.

rekrsiv 4y ago

I like this perspective a lot. 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?

specialist 4y ago
Paraphrasing, from memory: Happy marriages are boring; They all look the same. Whereas each unhappy marriage is uniquely unhappy.

SoftTalker 4y ago

> as you're offsetting it with your revenue 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.

acatton 4y ago
I believe that you're biased by HN, since a lot of the discussion here revolve around over-valued VC-money-roided-up startups burning millions of dollar per months. 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.
beambot 4y ago
SHOP: $4.8B in trailing 12-month revenue, growing 70%+ YoY for last few years and $250M in positive free cashflow. 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. https://finance.yahoo.com/quote/SHOP/financials?p=SHOP https://finance.yahoo.com/quote/SHOP/financials?p=SHOP

hoten 4y ago

Not even to mention the impact Conway's Law suggests! As a company grows in number of specialized teams, you'd expect to see magnifying difficulty in having efficient communication, eventually impacting what the product looks like (or at least, how robust the code is and how easy it is to augment). Seems like it could be a bad feedback loop - code got more complex indirectly because of number of teams, so naturally you hire more people to maintain the same output. See this video by Casey M. https://youtu.be/5IUj1EZwpJY https://youtu.be/5IUj1EZwpJY

petercooper 4y ago

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, … 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.