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

> * There is no compliance reason why OP couldn't have read access to look at the source.*

At a guess, I would say you have never worked with DRM integration. Getting access even to the binary SDK's can take months, and if you ever need the special license to work with the thing on source code level, prepare for a delay of several quarters.

Long time ago, Nokia was integrating Microsoft's DRM. I got to witness first hand the red tape needed to allow a new person to even see the source code the team worked with. And this was thanks to requirement MS imposes on their licensees.

The other code I know of that was heavily siloed were Nokia's DSP codecs. Pretty sure there were other corners with similarly absurd external restrictions but at least I was never exposed to them.

Definitely second the idea of taking it as a learning experience!

It might be possible that the large company is completely disfuctional (but... they grew to be large enough to acquire the startup, so must be doing something right).

But when the OP says they've only ever worked on startups... that tells me this is almost certainly about OPs lack of experience working in a company that values product quality and stability over "move fast and break things".

So I'd suggest to work there for a while (at least a year or three) to learn how stable organizations operate and why. It's a different skillset that OP doesn't have (by virtue of having only worked in startups).

Some people can only deal with the startup phase, that's ok too. But it's nice to decide that from a position of experience.

Everything in the story is quite reasonable! The engineers can't be taking requests from every rando that walks by, that works in a "No response after two days"? At a largish company where I had such a request queue, we'd only read and triage them once a week. Anything more frequent would be too distracting. So two days is quite a good response time.

"end of Q1 in 2022": That's a pretty quick turnaround I'd say. Surely the engineering team isn't sitting around waiting for OPs requests, they have many weeks/months of work already in the queue.

"I tell him I'm happy to fix the issue myself" - That can't work at all in a large company. Just imagine if again any rando can go and push changes into any codebase they don't know anything about. Are you taking responsibility for all consequences? Even if you say yes, you can't because you don't have the authority to do so. If your change breaks some customer somewhere, the management chain who owns that codebase will be in trouble for allowing such an out of band change to get merged.

I've been in 5 startups, a couple of them ground-up with just a few people. But have also spent well over ten years in 50K+ and even 100K+ people organizations. Different needs, different processes, different skillsets. It's nice to try them all.

This is normal.

I'm a lead developer of one of codebases which is heavily reliant on atleast 6 different apps. Apart from my projects own milestones, I also have its own bugs/fixes. Then every other day some one wants a feature. The requests are so overwhelming that I do , "please speak to my manager". Because thats the only valid way of getting things done on a agreeable time, the time at which both me and the person expecting the feature can reasonably expect.

Yeah that's what you get for working at a large company.

The good thing: they pay is pretty good, and you can reasonably get away with doing absolutely nothing and get paid awesomely.

The bad thing: nothing gets done and there are 4 layers of management, and you will end up frustrated.

The job market for IT is great now. You won't "change the company from the inside". You won't be "a startup within an org". This will only get worse.

Look at what you are doing, and if you don't like it now, and can afford the instability of a start-up, leave.