4 ms·

> 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 ho

by 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!
- simonw 9y ago
  Snapchat was built on Google App Engine, so they're probably one of the best large scale examples of this.
  - stickfigure 9y ago
    This is true, and really one of the more mysterious things about the headcount. This should be an example of how to keep an organization lean as it scales. I wonder why it isn't.
- askafriend 9y ago
  Snapchat and Nextdoor are great examples. The former runs most infra on Google App Engine, and the latter runs primarily on AWS.
matthewmacleod 9y ago
Yeah, I think it's important to stress that. Building an application is easy. Maintaining it, adding features, scaling it, integrating with other services, building platforms… those activities all take a lot of other work. I work at a small company whose core product was developed primarily by one or two developers. We now have substantially the same functionality with an engineering team of ~13, but constantly have a huge amount of work we want to do. Things like scaling, refactoring legacy code, paying down technical debt, handling complex and tricky edge cases that could previously be glossed over, and building administration tools – these take up _phenomenal_ amounts of time, especially if you want to work at a sustainable pace. I can totally believe that larger software houses need a surprising number of engineers.
- twblalock 9y ago
  Not to mention that you just can't break things anymore once you have millions of users on your app. You have to move very carefully.
- john_moscow 9y ago
  I worked in teams maintaining large projects and I also built (and maintained) a few ones myself after starting my own business, so I can sort of compare. I'd say it's a matter of risk management. When 1 or 2 people are building a project, making decisions is easy. You consider the options, you pick a strategy and you're the one to blame if it fails. If that happens, you pick up the pieces and try to pivot, but you're still in charge. When you introduce more people to the process of decision making (even on low engineering levels), it creates a massive political overhead. People compete for visibility, so they will propose ideas even if they don't make much sense strategically. People have feelings, so they will often support ideas of their friends and dismiss the ideas of their enemies regardless of the business impact. People don't want to be responsible for failure, so they will often create lots of unnecessary low risk/low impact work instead of taking risks. So there will be indeed a lot of extra work, but in many cases the customers won't notice the difference. The upside of this is fault tolerance - if one of the 2 co-founders leaves a company, it is doomed. If the same work is done by a team of 13, you can fire and easily replace 1-4 of them without much impact and investors generally like that.
prklmn 9y ago
I think it’s important to remember that this is all happening in the context of easily raising huge amounts of VC money at incredibly high valuations. If a company was looking to raise money say 10 years ago when, all corporate metrics being equal, their valuation would have been half or even less than what it is today and it was much more difficult to secure funds, the mindset about headcount would likely be different.
justicezyx 9y ago
Unfortunately, the mindset of ordinary people is reflected clearly in OP's confusion.

by wand3r 9y ago

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!
simonw 9y ago
Snapchat was built on Google App Engine, so they're probably one of the best large scale examples of this.
- stickfigure 9y ago
  This is true, and really one of the more mysterious things about the headcount. This should be an example of how to keep an organization lean as it scales. I wonder why it isn't.
askafriend 9y ago
Snapchat and Nextdoor are great examples. The former runs most infra on Google App Engine, and the latter runs primarily on AWS.

matthewmacleod 9y ago

Yeah, I think it's important to stress that. Building an application is easy. Maintaining it, adding features, scaling it, integrating with other services, building platforms… those activities all take a lot of other work. I work at a small company whose core product was developed primarily by one or two developers. We now have substantially the same functionality with an engineering team of ~13, but constantly have a huge amount of work we want to do. Things like scaling, refactoring legacy code, paying down technical debt, handling complex and tricky edge cases that could previously be glossed over, and building administration tools – these take up _phenomenal_ amounts of time, especially if you want to work at a sustainable pace. I can totally believe that larger software houses need a surprising number of engineers.

twblalock 9y ago
Not to mention that you just can't break things anymore once you have millions of users on your app. You have to move very carefully.
john_moscow 9y ago
I worked in teams maintaining large projects and I also built (and maintained) a few ones myself after starting my own business, so I can sort of compare. I'd say it's a matter of risk management. When 1 or 2 people are building a project, making decisions is easy. You consider the options, you pick a strategy and you're the one to blame if it fails. If that happens, you pick up the pieces and try to pivot, but you're still in charge. When you introduce more people to the process of decision making (even on low engineering levels), it creates a massive political overhead. People compete for visibility, so they will propose ideas even if they don't make much sense strategically. People have feelings, so they will often support ideas of their friends and dismiss the ideas of their enemies regardless of the business impact. People don't want to be responsible for failure, so they will often create lots of unnecessary low risk/low impact work instead of taking risks. So there will be indeed a lot of extra work, but in many cases the customers won't notice the difference. The upside of this is fault tolerance - if one of the 2 co-founders leaves a company, it is doomed. If the same work is done by a team of 13, you can fire and easily replace 1-4 of them without much impact and investors generally like that.

prklmn 9y ago

I think it’s important to remember that this is all happening in the context of easily raising huge amounts of VC money at incredibly high valuations. If a company was looking to raise money say 10 years ago when, all corporate metrics being equal, their valuation would have been half or even less than what it is today and it was much more difficult to secure funds, the mindset about headcount would likely be different.

justicezyx 9y ago

Unfortunately, the mindset of ordinary people is reflected clearly in OP's confusion.