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 w

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.