10 ms·

I'm honestly curious if the massive headcount of some of these companies is even necessary. I was taking a look at Bumble[0] the other day. They are the #2 dati

I'm honestly curious if the massive headcount of some of these companies is even necessary. I was taking a look at Bumble[0] the other day. They are the #2 dating app in the US, turning down acquisition offers, and are profitable with >$100mm in revenue, yet I have been unable to find a single engineering job listing or find anyone on LinkedIn that is on their technical staff. Plenty of Fish[1] was built and scaled to hundreds of millions of users by a single person. When all you're doing technically is recreating functionality that has existed for decades now (messaging), and using 100% cloud infrastructure, why build out a huge engineering org? [0] https://www.forbes.com/sites/clareoconnor/2017/08/23/women-first-app-bumble-turned-down-450-million-buyout-offer-from-dating-giant-match-group/ https://www.forbes.com/sites/clareoconnor/2017/08/23/women-f... [1] http://www.businessinsider.com/how-markus-frind-bootstrapped-plentyoffish-and-sold-it-for-575-million-2015-7 http://www.businessinsider.com/how-markus-frind-bootstrapped...

gizmo385 9y ago
What exactly do all of these engineers do at single-focus companies like Snap? I guess I don't understand where you could find enough work for hundreds of engineers on a product like that?
- zitterbewegung 9y ago
  Probably the Glasses and everything related to that? I don't think those were profitable so maybe it could be their hardware division.
- tedmiston 9y ago
  There are so many features in the Snapchat app. If you really dig in, there are teams dedicated to each portion of the app. I'm not sure if that means a bunch of separate PMs as well, but it is a big complex app once you account for all the features... DMs, group messages, Discover, Memories, Stories, the map, filters/lenses, integrations like Bitmoji, ...
  - overcast 9y ago
    Oh come on, 1800 employees!?
    - askafriend 9y ago
      Sales people, biz dev, PR, recruiting, legal, content creation, headcount from acquisitions like Bitmoji, support team, data team to make sense of the massive amount of data coming in, marketing team, etc etc etc. You need these things to run a global operation at scale. If you're not interested in running a global operation at scale, then you can be happy running a little self-serve application - but to create the phenomenon that is SnapChat requires a lot of coordinated effort. To think otherwise is just simply naive. Now I don't think we have enough information to judge if 1800 is the wrong number for SnapChat or not. They very well may be overstaffed.
      - pkaye 9y ago
        Instagram got pretty far with their initial 13 employees.
        askafriend 9y ago
        They got far but less than you think. They had 30mm users mostly in the US (versus nearly 1 billion today all over the world), no monetization operations in place, no biz dev deals, no data deals, not truly international, iPhone only, a far far more limited feature set, very little content moderation or community support in place, very little anti-spam measures, far less security, etc
      - overcast 9y ago
        Valve has 1/6th of that, develops games, and provides the entire worlds distribution of PC games. 1800+ is ridiculous, and clearly the wrong number, since they are laying off people.
        jonny_eh 9y ago
- jbob2000 9y ago
  If I had to hazard a guess, it would be that most engineers aren't that productive. It's easy to fill your day with non-important ditch-digging to look busy, and it takes a certain level of critical thinking to cut through the bullshit and get stuff done. So companies have to continue hiring until they find that magical person who manages to do the work of 10 people. Some companies get lucky and find 5 of these people right off the bat, others, not so much. It could also be the engineering culture. All it takes is a couple of lazy developers and the laziness culture beings to propagate to the rest of the company. One or two people being wishy-washy about delivery dates and meeting times will send the message to the rest of the team that it's ok for you to also be wishy-washy with these things. Management doesn't always think there's a culture problem, so they just increase headcount thinking that productivity directly correlates to headcount. It's not fair to fully blame engineering for this. If the company doesn't have a strong engineering voice, you will get handed ridiculous requirements and specifications and yes, you'll need 50 more developers so you can meet the needs of the picky lead designer who wants pixel perfect function on every device ever created for every language for any feature. All that being said, when a company is doing well, the executives and shareholders shout "Hire baby, hire" and so the machine brings on capacity with no real goal, other than expansion for its own sake.
  - ExactoKnight 9y ago
    To Snapchat's credit they did pull off some amazing features with that surge of investment money. The facial recognition/filters they built was truly innovative and very advanced. The engineers involved in that were undeniably exceptional. I think a better contrast is Twitter. Thousands of employees and it feels almost nothing in terms of new features to show for it, minus changing a star over to a heart... (which btw, reportedly took two years to implement once the idea came about...)
- runT1ME 9y ago
  I think there are two acceptable answers in addition from the obvious possibility of bad management. 1. Many engineers do not work on core products. Many of these companies operate like quasi accelerators at times: hire smart engineers since you can afford it, hire a few good PMs, see what happens, then market the most promising results. Twitter had Vine, Snap had Spectacles, and maybe one of the best examples of this is Amazon. They didn't need thousands of engineers to run an e-commerce site, but they did need them to build out a cloud, and Alexa, and a video streaming service, etc. Other companies want to replicate this model. 2. Scale is hard. As soon as you hit a limit of what off the shelf software or current open source offerings can do, you have a hard problem on your hands. There are certainly more 'web scale' products that exist now to make this process easier for startups, but it can still happen. It's also possible that even if there are products that can scale, it would end up being cheaper to spin up a large team of good engineers to replicate a commercial offering if you're optimistic about the companies growth.
  - aylmao 9y ago
    I agree with your points! Just thought I'd lyk though that Vine was an acquisition, not a Twitter-born project. There's tonnes of examples backing up your first point though, 100% accurate.
  - guy_c 9y ago
    Also as a codebase grows the complexity grows. Adding or changing code has a lot more impact and is much harder. If I remember correctly Shopify is something like 400k lines of Ruby on Rails code and 400 developers (i.e. one developer per 1000 LOC). Whereas I guess a 5k LOC codebase could be handled by a single developer.
    - mattmanser 9y ago
      Ooooo, not 1000 LOC. That's a couple of weeks work. EDIT: I'm being flippant, but to me a 400k code base is something 2 devs can put out in a few years. I'm pretty certain the present main code base I'm working on must be close to 400k and it's only ever had 2 devs working on it at any one time. And we're always adding massive chunks of new functionality, and are regularly integrating with new third parties. And we total overhauled it last year to support i18n and it's now being regularly used in 3 languages and we can add more in literally a couple of days. Ok it only handles hundreds of thousands of users, but I expect it to be millions within a couple of years and we're not even trying to load balance or anything yet.
- dmode 9y ago
  Once you introduce advertising, you have to hire an army of engineers, biz devs, ad ops, revenue folks, accounting, finance, sales folks to manage that business. The ad business seems so complex with so many players.
- jxub 9y ago
  Maybe on features that get aborted on each change of corporate strategy (my supposition)? It's also really easy to knock out a MVP that replicates 80% of snapchat features, but the real problem is getting the scale right, as conventional social networks are worthless without a huge pool of eyeballs for precisely targeted ads. While I'm at it, I'd like to plant the thought that Social might be a perfect place for disruption again, but now with a non-profit/public strategy. Maybe with a huge initial donation it's more than enough as incremental user costs are minimal if we don't spend money optimizing for engagement and ads and use some decentralized tech lime swarm/ipfs, but that's for another time. Also the weird corner cases in different platforms and the huge technical debt in most startups seem to sap a lot of energy.
- nunez 9y ago
  Definitely not core dev. Mostly IP harvesting/research and "ops"
- austincheney 9y ago
  My previous employer had way more than 10000 software developers. There was some justification for many engineers given the size of the business in that they did business in many different countries, owned many different brands, and had a major division that was completely divested. Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers. The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive. Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it. Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers. The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse. By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks. That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed. Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers. Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people. Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees. People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics. Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work. I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.
bootloop 9y ago
In comparison, Valve has 360 people (2016) and they do a lot. [0] [0] https://www.pcgamer.com/valve-misses-deadline-to-respond-to-washington-state-gambling-regulator-but-says-its-coming-soon/ https://www.pcgamer.com/valve-misses-deadline-to-respond-to-...
- rosstex 9y ago
  They don't do Half-Life.
  - PopsiclePete 9y ago
    :-/
- walls 9y ago
  > and they do a lot That's extremely generous. They update the client in imperceptible ways every few hours, and they push CS:GO patches every few months. Not sure what everyone's doing over there, but it's not "a lot".
  - ac29 9y ago
    Steam does several billion dollars in sales each year. Just maintaining that alone must take a significant portion of their 300+ employees.
    - bootloop 9y ago
      Steam team size is apparently 10. [0] (2017) [0] https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be&t=1h33m13s https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be... Took me around 20 min to find this reference again... I don't think they only talk about a content management team here as the organization is quite flat at Valve and a lot of people do a lot of different things.
  - empath75 9y ago
    Releasing a VR headset seems like a thing.
TaylorGood 9y ago
Agreed. Baffling for an app that makes substantial iteration maybe once or twice a year. My theory is these companies like to hoard Dev talent in prime locations.
- johnvanommen 9y ago
  I've worked for a couple of companies that have IPO'd. One thing I've noticed is that the people who are investing in the companies want the companies to be a specific size. For instance, let's say you have a company that's making an app. Your company is ten people. The venture capitalists will often throw money at your company to grow it to a larger size. I can only speculate on why this is, but I would guess that it's easier for them to sell the company for a large price if the company itself is relatively large. For instance, HPE paid $1.1 billion for Nimble Storage. They have 1100 employees. If Nimble only had 30 employees would they be able to justify that valuation? Probably not.
  - stctgion 9y ago
    A company is only people after all. Once a small start up is taken over there will be a clock ticking for a lot of the engineers who will leave when they can sell their shares. Having a larger number of people involved, including newer people (with no shares) mitigates this.
  - TaylorGood 9y ago
    At dinner last night with a VC, company sizes came up. One of the most appealing business models, which I shared is DNVB's(1). For example, NATIVE, the deodorant brand I use. Had four employees, 1m customers, in business for 2.5 years and just sold for $100m to P&G(2). Yes please. (1) https://medium.com/@dunn/the-future-of-brands-6682841bd4 https://medium.com/@dunn/the-future-of-brands-6682841bd4 (2) https://www.racked.com/2018/1/19/16905724/natural-deodorant-schmidts-native https://www.racked.com/2018/1/19/16905724/natural-deodorant-...
    - daxorid 9y ago
      Interesting. My primary business happens to be a (bootstrapped) DNVB with comparable customer count. And despite stories such as Bonobos, etc, we have seen virtually zero interest from outside investors. I suspect your contention is accurate only for founders who are previously "connected" to the Silicon Valley world.
wand3r 9y ago
> I'm honestly curious if the massive headcount of some of these companies is even necessary. Patrick Collison (Stripe) talks about this in Blitzscaling and how this is often severely underestimated. He says it takes a lot less engineering to build the original product/service than to maintain it and operate it at scale. There is value in running a lean operation and there is probably some level of bloat in human resources across organizations; but dismissing the reality of necessity within these organizations should only be done carefully. I think the context PC was talking about was speed of feature creation/product shipping but conceptually the same thing holds for the size of the company. [0] https://www.youtube.com/watch?v=qrDZhAxpKrQ https://www.youtube.com/watch?v=qrDZhAxpKrQ
- jxub 9y ago
  Is there an example of a million-user/big B2B company built entirely on top of FAAS like AWS Lambda and some lind of database with auto scaling, sharding et al. (maybe Spanner or CockroachDB [0])? I suspect once somethink like that happens we could have companies that have almost Google scale while just employing a couple of engineers. [0] As a side note, I'm sure a blueprint for handling the common DB scaling problem. I suppose we could train a ML model to read some logs/usage stats and handle the remainder of edge cases. But making such a model will probably require hundreds of engineers so I guess we're safe at the moment.
  - deleted 9y ago
    [deleted]
  - eitally 9y ago
    The scaling isn't the problem that requires large engineering teams. It's partner integrations, compliance work, and all sorts of things that are extremely non-core.
    - warrenm 9y ago
      this 100x!
  - 9y ago
ww520 9y ago
Without the headcount, how do you build empire?
- jxub 9y ago
  Use Erlang and sell to FB. All the benefits and none of the headaches. Also, aim for talent, not warm bodies that passed the fizzbuzz test. Caveat: worked only once, no guarantees provided...
draw_down 9y ago
Yes, everyone on HN says this all the time about every company. Anything can be built in a weekend, you know.
adventured 9y ago
> why build out a huge engineering org? If the projection you buy into is that you're going to have a billion users, and a business doing $8 billion in sales, you might be less inclined to worry about the cost of those 100 extra engineers and are likely to assume they'll be necessary. Snapchat probably built out based on old projections that indicated a lot more growth, conceived at a time when they were in the midst of hyper growth. Twitter did the exact same thing, substantially overstaffing for growth that never arrived. The initially fast growing social network trap.
tangue 9y ago
Added to that : Snap is running on Google App Engine which closes the door for certain kind of jobs
- sjg007 9y ago
  In the long run building their own datacenter and backend would save money.
  - kgilpin 9y ago
    They are not paying list price for App Engine.
    - sjg007 9y ago
      Yes but they aren't paying at cost either.
enieslobby 9y ago
Dan Luu has a good post on this - http://danluu.com/sounds-easy/ http://danluu.com/sounds-easy/
fullshark 9y ago
Ssshhh what's wrong with you?
maxxxxx 9y ago
In a company I worked at the mode was pretty much to take new investment and immediately hire a bunch of new people. Later they would figure out what these people should do. It almost seemed required by the VCs. I can imagine a similar thing happening at Snap.
- deleted 9y ago
  [deleted]
- aylmao 9y ago
  Yik Yak comes to mind; the product died but they got acquired by Square for the engineering talent. I can see VC's seeing a solid team of engineers as an asset that's potentially more valuable than the actual product.
  - maxxxxx 9y ago
    At the company I worked they seemed mostly concerned with the number of engineers, not quality. We pretty much had the marching order to hire 30 engineers ASAP without knowing what they would do.
220V_USKettle 9y ago
I wonder this about TrueCar.com, too.
acchow 9y ago
Building a product isn't that hard. But you also want: - A product upon which you can build on more features while maintaining 100% uptime and remain mostly bug-free - Build up ad infrastructure with real-time data and bidding - Instrument everything - Consume all that instrumentation to make product/business decisions - Feed all that instrumentation into your ad infrastructure - Optimize all of the above - Have all of the above secure Or you could do none of that, but then you won't be the next Facebook.
throwaway84742 9y ago
Two reasons why startups amass huge numbers of people: 1. CEO is a shithead who doesn’t know what to do, so hiring is a futile attempt to do everything at once 2. Huge number of employees looks better when coming up with valuation for a round. The two tend to be self reinforcing. And #1 survives and blossoms after IPO.
twhb 9y ago
The question isn't whether it's necessary, but whether it's profitable. Many programmers have an effect that's a % of existing metrics, for example a performance improvement that increases subscription renewals by 5%. As volume increases, it becomes profitable to hire people who have a smaller and smaller impact.
pbh101 9y ago
Dan Luu wrote a good post on this back in 2016: https://danluu.com/sounds-easy/ https://danluu.com/sounds-easy/

gizmo385 9y ago

What exactly do all of these engineers do at single-focus companies like Snap? I guess I don't understand where you could find enough work for hundreds of engineers on a product like that?

zitterbewegung 9y ago
Probably the Glasses and everything related to that? I don't think those were profitable so maybe it could be their hardware division.
tedmiston 9y ago
There are so many features in the Snapchat app. If you really dig in, there are teams dedicated to each portion of the app. I'm not sure if that means a bunch of separate PMs as well, but it is a big complex app once you account for all the features... DMs, group messages, Discover, Memories, Stories, the map, filters/lenses, integrations like Bitmoji, ...
- overcast 9y ago
  Oh come on, 1800 employees!?
  - askafriend 9y ago
    Sales people, biz dev, PR, recruiting, legal, content creation, headcount from acquisitions like Bitmoji, support team, data team to make sense of the massive amount of data coming in, marketing team, etc etc etc. You need these things to run a global operation at scale. If you're not interested in running a global operation at scale, then you can be happy running a little self-serve application - but to create the phenomenon that is SnapChat requires a lot of coordinated effort. To think otherwise is just simply naive. Now I don't think we have enough information to judge if 1800 is the wrong number for SnapChat or not. They very well may be overstaffed.
    - pkaye 9y ago
      Instagram got pretty far with their initial 13 employees.
      - askafriend 9y ago
        They got far but less than you think. They had 30mm users mostly in the US (versus nearly 1 billion today all over the world), no monetization operations in place, no biz dev deals, no data deals, not truly international, iPhone only, a far far more limited feature set, very little content moderation or community support in place, very little anti-spam measures, far less security, etc
    - overcast 9y ago
      Valve has 1/6th of that, develops games, and provides the entire worlds distribution of PC games. 1800+ is ridiculous, and clearly the wrong number, since they are laying off people.
      - jonny_eh 9y ago
jbob2000 9y ago
If I had to hazard a guess, it would be that most engineers aren't that productive. It's easy to fill your day with non-important ditch-digging to look busy, and it takes a certain level of critical thinking to cut through the bullshit and get stuff done. So companies have to continue hiring until they find that magical person who manages to do the work of 10 people. Some companies get lucky and find 5 of these people right off the bat, others, not so much. It could also be the engineering culture. All it takes is a couple of lazy developers and the laziness culture beings to propagate to the rest of the company. One or two people being wishy-washy about delivery dates and meeting times will send the message to the rest of the team that it's ok for you to also be wishy-washy with these things. Management doesn't always think there's a culture problem, so they just increase headcount thinking that productivity directly correlates to headcount. It's not fair to fully blame engineering for this. If the company doesn't have a strong engineering voice, you will get handed ridiculous requirements and specifications and yes, you'll need 50 more developers so you can meet the needs of the picky lead designer who wants pixel perfect function on every device ever created for every language for any feature. All that being said, when a company is doing well, the executives and shareholders shout "Hire baby, hire" and so the machine brings on capacity with no real goal, other than expansion for its own sake.
- ExactoKnight 9y ago
  To Snapchat's credit they did pull off some amazing features with that surge of investment money. The facial recognition/filters they built was truly innovative and very advanced. The engineers involved in that were undeniably exceptional. I think a better contrast is Twitter. Thousands of employees and it feels almost nothing in terms of new features to show for it, minus changing a star over to a heart... (which btw, reportedly took two years to implement once the idea came about...)
runT1ME 9y ago
I think there are two acceptable answers in addition from the obvious possibility of bad management. 1. Many engineers do not work on core products. Many of these companies operate like quasi accelerators at times: hire smart engineers since you can afford it, hire a few good PMs, see what happens, then market the most promising results. Twitter had Vine, Snap had Spectacles, and maybe one of the best examples of this is Amazon. They didn't need thousands of engineers to run an e-commerce site, but they did need them to build out a cloud, and Alexa, and a video streaming service, etc. Other companies want to replicate this model. 2. Scale is hard. As soon as you hit a limit of what off the shelf software or current open source offerings can do, you have a hard problem on your hands. There are certainly more 'web scale' products that exist now to make this process easier for startups, but it can still happen. It's also possible that even if there are products that can scale, it would end up being cheaper to spin up a large team of good engineers to replicate a commercial offering if you're optimistic about the companies growth.
- aylmao 9y ago
  I agree with your points! Just thought I'd lyk though that Vine was an acquisition, not a Twitter-born project. There's tonnes of examples backing up your first point though, 100% accurate.
- guy_c 9y ago
  Also as a codebase grows the complexity grows. Adding or changing code has a lot more impact and is much harder. If I remember correctly Shopify is something like 400k lines of Ruby on Rails code and 400 developers (i.e. one developer per 1000 LOC). Whereas I guess a 5k LOC codebase could be handled by a single developer.
  - mattmanser 9y ago
    Ooooo, not 1000 LOC. That's a couple of weeks work. EDIT: I'm being flippant, but to me a 400k code base is something 2 devs can put out in a few years. I'm pretty certain the present main code base I'm working on must be close to 400k and it's only ever had 2 devs working on it at any one time. And we're always adding massive chunks of new functionality, and are regularly integrating with new third parties. And we total overhauled it last year to support i18n and it's now being regularly used in 3 languages and we can add more in literally a couple of days. Ok it only handles hundreds of thousands of users, but I expect it to be millions within a couple of years and we're not even trying to load balance or anything yet.
dmode 9y ago
Once you introduce advertising, you have to hire an army of engineers, biz devs, ad ops, revenue folks, accounting, finance, sales folks to manage that business. The ad business seems so complex with so many players.
jxub 9y ago
Maybe on features that get aborted on each change of corporate strategy (my supposition)? It's also really easy to knock out a MVP that replicates 80% of snapchat features, but the real problem is getting the scale right, as conventional social networks are worthless without a huge pool of eyeballs for precisely targeted ads. While I'm at it, I'd like to plant the thought that Social might be a perfect place for disruption again, but now with a non-profit/public strategy. Maybe with a huge initial donation it's more than enough as incremental user costs are minimal if we don't spend money optimizing for engagement and ads and use some decentralized tech lime swarm/ipfs, but that's for another time. Also the weird corner cases in different platforms and the huge technical debt in most startups seem to sap a lot of energy.
nunez 9y ago
Definitely not core dev. Mostly IP harvesting/research and "ops"
austincheney 9y ago
My previous employer had way more than 10000 software developers. There was some justification for many engineers given the size of the business in that they did business in many different countries, owned many different brands, and had a major division that was completely divested. Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers. The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive. Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it. Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers. The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse. By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks. That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed. Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers. Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people. Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees. People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics. Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work. I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.

bootloop 9y ago

In comparison, Valve has 360 people (2016) and they do a lot. [0] [0] https://www.pcgamer.com/valve-misses-deadline-to-respond-to-washington-state-gambling-regulator-but-says-its-coming-soon/ https://www.pcgamer.com/valve-misses-deadline-to-respond-to-...

rosstex 9y ago
They don't do Half-Life.
- PopsiclePete 9y ago
  :-/
walls 9y ago
> and they do a lot That's extremely generous. They update the client in imperceptible ways every few hours, and they push CS:GO patches every few months. Not sure what everyone's doing over there, but it's not "a lot".
- ac29 9y ago
  Steam does several billion dollars in sales each year. Just maintaining that alone must take a significant portion of their 300+ employees.
  - bootloop 9y ago
    Steam team size is apparently 10. [0] (2017) [0] https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be&t=1h33m13s https://www.youtube.com/watch?v=d3bQpF16vnE&feature=youtu.be... Took me around 20 min to find this reference again... I don't think they only talk about a content management team here as the organization is quite flat at Valve and a lot of people do a lot of different things.
- empath75 9y ago
  Releasing a VR headset seems like a thing.

TaylorGood 9y ago

Agreed. Baffling for an app that makes substantial iteration maybe once or twice a year. My theory is these companies like to hoard Dev talent in prime locations.

johnvanommen 9y ago
I've worked for a couple of companies that have IPO'd. One thing I've noticed is that the people who are investing in the companies want the companies to be a specific size. For instance, let's say you have a company that's making an app. Your company is ten people. The venture capitalists will often throw money at your company to grow it to a larger size. I can only speculate on why this is, but I would guess that it's easier for them to sell the company for a large price if the company itself is relatively large. For instance, HPE paid $1.1 billion for Nimble Storage. They have 1100 employees. If Nimble only had 30 employees would they be able to justify that valuation? Probably not.
- stctgion 9y ago
  A company is only people after all. Once a small start up is taken over there will be a clock ticking for a lot of the engineers who will leave when they can sell their shares. Having a larger number of people involved, including newer people (with no shares) mitigates this.
- TaylorGood 9y ago
  At dinner last night with a VC, company sizes came up. One of the most appealing business models, which I shared is DNVB's(1). For example, NATIVE, the deodorant brand I use. Had four employees, 1m customers, in business for 2.5 years and just sold for $100m to P&G(2). Yes please. (1) https://medium.com/@dunn/the-future-of-brands-6682841bd4 https://medium.com/@dunn/the-future-of-brands-6682841bd4 (2) https://www.racked.com/2018/1/19/16905724/natural-deodorant-schmidts-native https://www.racked.com/2018/1/19/16905724/natural-deodorant-...
  - daxorid 9y ago
    Interesting. My primary business happens to be a (bootstrapped) DNVB with comparable customer count. And despite stories such as Bonobos, etc, we have seen virtually zero interest from outside investors. I suspect your contention is accurate only for founders who are previously "connected" to the Silicon Valley world.

wand3r 9y ago

> I'm honestly curious if the massive headcount of some of these companies is even necessary. Patrick Collison (Stripe) talks about this in Blitzscaling and how this is often severely underestimated. He says it takes a lot less engineering to build the original product/service than to maintain it and operate it at scale. There is value in running a lean operation and there is probably some level of bloat in human resources across organizations; but dismissing the reality of necessity within these organizations should only be done carefully. I think the context PC was talking about was speed of feature creation/product shipping but conceptually the same thing holds for the size of the company. [0] https://www.youtube.com/watch?v=qrDZhAxpKrQ https://www.youtube.com/watch?v=qrDZhAxpKrQ

jxub 9y ago
Is there an example of a million-user/big B2B company built entirely on top of FAAS like AWS Lambda and some lind of database with auto scaling, sharding et al. (maybe Spanner or CockroachDB [0])? I suspect once somethink like that happens we could have companies that have almost Google scale while just employing a couple of engineers. [0] As a side note, I'm sure a blueprint for handling the common DB scaling problem. I suppose we could train a ML model to read some logs/usage stats and handle the remainder of edge cases. But making such a model will probably require hundreds of engineers so I guess we're safe at the moment.
- deleted 9y ago
  [deleted]
- eitally 9y ago
  The scaling isn't the problem that requires large engineering teams. It's partner integrations, compliance work, and all sorts of things that are extremely non-core.
  - warrenm 9y ago
    this 100x!
- 9y ago

ww520 9y ago

Without the headcount, how do you build empire?

jxub 9y ago
Use Erlang and sell to FB. All the benefits and none of the headaches. Also, aim for talent, not warm bodies that passed the fizzbuzz test. Caveat: worked only once, no guarantees provided...

draw_down 9y ago

Yes, everyone on HN says this all the time about every company. Anything can be built in a weekend, you know.

adventured 9y ago

> why build out a huge engineering org? If the projection you buy into is that you're going to have a billion users, and a business doing $8 billion in sales, you might be less inclined to worry about the cost of those 100 extra engineers and are likely to assume they'll be necessary. Snapchat probably built out based on old projections that indicated a lot more growth, conceived at a time when they were in the midst of hyper growth. Twitter did the exact same thing, substantially overstaffing for growth that never arrived. The initially fast growing social network trap.

tangue 9y ago

Added to that : Snap is running on Google App Engine which closes the door for certain kind of jobs

sjg007 9y ago
In the long run building their own datacenter and backend would save money.
- kgilpin 9y ago
  They are not paying list price for App Engine.
  - sjg007 9y ago
    Yes but they aren't paying at cost either.

enieslobby 9y ago

Dan Luu has a good post on this - http://danluu.com/sounds-easy/ http://danluu.com/sounds-easy/

fullshark 9y ago

Ssshhh what's wrong with you?

maxxxxx 9y ago

In a company I worked at the mode was pretty much to take new investment and immediately hire a bunch of new people. Later they would figure out what these people should do. It almost seemed required by the VCs. I can imagine a similar thing happening at Snap.

deleted 9y ago
[deleted]
aylmao 9y ago
Yik Yak comes to mind; the product died but they got acquired by Square for the engineering talent. I can see VC's seeing a solid team of engineers as an asset that's potentially more valuable than the actual product.
- maxxxxx 9y ago
  At the company I worked they seemed mostly concerned with the number of engineers, not quality. We pretty much had the marching order to hire 30 engineers ASAP without knowing what they would do.

220V_USKettle 9y ago

I wonder this about TrueCar.com, too.

acchow 9y ago

Building a product isn't that hard. But you also want: - A product upon which you can build on more features while maintaining 100% uptime and remain mostly bug-free - Build up ad infrastructure with real-time data and bidding - Instrument everything - Consume all that instrumentation to make product/business decisions - Feed all that instrumentation into your ad infrastructure - Optimize all of the above - Have all of the above secure Or you could do none of that, but then you won't be the next Facebook.

throwaway84742 9y ago

Two reasons why startups amass huge numbers of people: 1. CEO is a shithead who doesn’t know what to do, so hiring is a futile attempt to do everything at once 2. Huge number of employees looks better when coming up with valuation for a round. The two tend to be self reinforcing. And #1 survives and blossoms after IPO.

twhb 9y ago

The question isn't whether it's necessary, but whether it's profitable. Many programmers have an effect that's a % of existing metrics, for example a performance improvement that increases subscription renewals by 5%. As volume increases, it becomes profitable to hire people who have a smaller and smaller impact.

pbh101 9y ago

Dan Luu wrote a good post on this back in 2016: https://danluu.com/sounds-easy/ https://danluu.com/sounds-easy/