Hacker News Reader

Comment by ericmcer | Hacker News Reader

It always seemed common sense to me that once a piece of software became stable and profitable you would need a much smaller engineering staff than when it was being built. The opposite seems to happens and orgs 10X their engineer headcount once they start making money.

It makes sense to keep some high performers and a few redundancies to stabilize/modernize it and make small improvements, but it feels like tech got really bloated with these massive corps who were trying to burn as much as they could to keep all the VC money flowing. Take like Uber having a team that built and maintained a chat app just for internal use, and every single big org having a bunch of teams responsible for various "some_dumb_name" that is the "custom X for 'Y'" where smaller teams just use the OS solutions to those problems.

View on HN

> once a piece of software became stable and profitable you would need a much smaller engineering staff than when it was being built

This is not generally the case, except in monopoly situations.

Your software product generally has a competitor, and they're busy trying to make theirs better than yours -- whether with more features, better integrations, whatever it is.

So your staff size generally stays about the same in order to build more features desired by customers to prevent customers from switching to your competitor and you go out of business. And certain features, by themselves, can be more complex than the entire v1 of a product. And/or involve massive refactoring, etc.

The companies that get to reduce their team size are often because they're in a monopoly position, and then customers suffer because the software gets stagnant and the features they need don't get built. That's capitalism failing.

Also, something like an internal chat app isn't always a bad decision. If your company is above a certain size headcount, it can literally be cheaper to build small tools than to license them. Especially when you can more deeply customize and integrate them, which you often simply can't with off-the-shelf software.

> Your software product generally has a competitor, and they're busy trying to make theirs better than yours

Unless you are selling a commodity. There is a good case to be made that what Dropbox sells is a commodity.

> That's capitalism failing.

That's government failing.

1. You can't dig the moats necessary to establish a monopoly without regulation to support it.

2. If/when the government screws up, the onus is on it to fix the problem before the situation gets out of hand.

>There is a good case to be made that what Dropbox sells is a commodity.

Is there? I argue Drive and OneDrive surpassed Dropbox a while ago. Box is dirt cheap if you came in early as well (I still have some 50 GB forever deal from like, 2012). And there's a dozen others if you look into it. It's not very hard to drop any one cloud storage solution (or all of them if you invest in a NAS setup).

Is there not? This is a pretty good description of a commoditized environment:

> It's not very hard to drop any one cloud storage solution (or all of them if you invest in a NAS setup).

The present value of your org is your old products, all futures gains are from new products. The tech industry is littered with tombstones of companies that sat coasted on the success of an older product. Conversely there's a fascinating habit of really smart people in the right environment (Google, Bell Labs, Xerox PARC etc) to create things of enormous value. Things that were just a side project include AWS, Slack, the transistor and transformer architecture. All these companies are really trying to be incubators for the next 100x thing.

What you are talking of is only possible in companies where the founder didn't take VC investment. Once you take VC money, you get on the treadmill of infinite growth to satisfy investors. That makes companies do strange things in pursuit of this impossible goal. Like hiring for the sake of showing growth in headcount, hiring people to branch into unrelated verticals, hiring people with big resumes just to say you have them on the team etc

For real, at some point running development and product teams cracking on features for no reason is a real negative

software can generally be 'done' in the same way building a skyscraper can be

Reply on news.ycombinator.com