Ask HN: Startup acquired by a large company and it sucks. What to do?

It is obviously easy (and perhaps often true) that many problems in corporations are due to inefficiency and job creation but there is something important that is also implied from the fact that they have got to the stage of large corporate that dictates many things and that is reputation.

If you are a young startup, you get the luxury of making bold changes in production because people are probably paying a good price and getting lots of funtionality and most people can live with the odd bug, as long as it gets fixed quickly.

If you are e.g. IBM, you have massive codebase(s) developed over many years that are fragile as a spiders web. Sure you can dive in and attempt a fix but that is both more risky than your much younger and consistent startup codebase but also affect not just lots of customers but also your reputation. Any problems with the software and your customers are suddenly asking, "why are we paying a premium for IBM when we keep getting these bugs?"

Someone also mentioned compliance. The bigger you are, the more likely someone will pre-emptively prove your compliance (or not). Why? Because they are also corporations and don't want their reputation to suffer.

Personally, I think those that thrive in startups never do in corporates and vice-versa.

If you are satisfied with your pay, consider enjoying the time that has been freed up for you.

> Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order.

How can OP, as an engineer, or anyone else, that just joined a much bigger organisation, have any clue that a company is doing work that they shouldn't be doing AND they are doing it in a wrong order?!

Yes, but I'll be the first to admit it's a lot of fun to be able to work like that... from time to time.

Context is important also, a lot of young companies are still trying to figure out their optimal business model, so agility really is more important; adapt or die (kind of).

Lastly, you have to consider why anyone would ever work for a startup; they often pay less, more stress, less security, unpredictable environment, etc... but you get to do ridiculous experiments in production and try to build something cool. It's part of the incentive structure.

This happened to me when the small company that I worked at was acquired by a large company, too. Smallco's engineering definitely had some dysfunction that I was trying to work on: speeding up information from CI, increasing developer confidence, empowering juniors to make the smaller decisions independently, that sort of thing. Then on the acquisition we were told that the most important priority was to switch over to the largeco's infrastructure. Our product was a Linux desktop app, largeco didn't support desktop Linux. Smallco was on mercurial, largeco needed us to switch to git. Our CI would be switched off entirely on a given date.

I left to join another smallco (I admit that I was among the earliest smallco employees to leave post acquisition, but wasn't among the last). From what I hear, they did eventually finish the migration but didn't do anything about the other engineering problems, with the result that they took a significant hit on their already slow rate of executing on the roadmap and a competitor that was previously thought to be moribund is now at feature parity, and has gained enough share that bigco have to list it as a key part of the ecosystem that they support, right alongside the smallco software.

I do not know what lessons have been learned inside bigco about this situation. I do know that I was quite a dick about showing that we were focusing on the wrong problems and slowing the organisation down, and that this meant I wasn't effective in getting higher-up support for the necessary changes.