The promise of software at scale is that the marginal costs of selling one single additional unit are basically $0.00
As a result if your product sells for $500 you can spend $495 and still make money.
This leads to all sorts of adventures in driving that additional marginal unit sale such as:
- Localization - eg Microsoft Office is available in 102 languages! So now we need a local market product manager, sales team, distribution team, translator, QA, etc, etc.
- Enterprise - Huge swaths of money spent on conferences, thought leadership, any bullshit you can think of to potentially get a decision maker CTO to befriend somebody on your sales team.
- Government! - Selling to the gov't is extremely profitable but extremely long and complex sales cycle. Now we're hiring lobbyists, contract specialists, etc, etc.
- Support - Happy users are your mostly likely next buyers
> I can't think of a single large software company that doesn't regularly draw internet comments of the form “What do all the employees do?"
I also can't think of a single large software company that doesn't, in the long run, survive by either endlessly buying and extracting all the value out of smaller software companies, or creating a moat that makes it almost impossible for new competitors to emerge.
Having worked for a small software company that got acquired by a large one that used the former survival strategy, and therefore witnessed firsthand the subsequent doubling of headcount and simultaneous halving of overall productivity, I can offer one of what I assume are several possible answers: Paperwork. And lots of it.
I don't think large companies just "extract value" from the small ones. They prove that the small company had a great idea and make the idea successful by providing sales, marketing and support that the small.company wouldn't be able to provide (if for no other reason than reduced risk and existing customer relations).
It might depend. In the case I experienced, sales, marketing and support were already in place and quite successful beforehand, and the acquiring company did an admirable job of teaching all three how to do less with more.
To take the example of support, pre-acquisition, the support team had a reputation for being one of the best and most knowledgeable in the industry. That reputation went up in smoke rather quickly when the acquiring company decided to merge support into their existing support vertical and adopt its existing policies, including things like requiring the support and the product development teams to communicate through JIRA instead of using informal channels like instant messages or (in exceptional cases) pulling a developer into the call.
The end result was that the mean time to find a resolution for the non-routine issues went from hours to days. Ironically, while management claimed this would reduce disruption for the development team, it actually increased the time that developers had to spend on supporting the support team, since it made communication so much more difficult. Which, in turn, means that it slowed down both customer support and product development by bogging them both down with paperwork.
https://danluu.com/sounds-easy/
> I can't think of a single large software company that doesn't regularly draw internet comments of the form “What do all the employees do?"
Granted he's mostly talking about engineers, but I'm sure someone more knowledgable about marketing could write an almost identical essay.