I wonder if the team in question has had an experience like this: https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...
Ask HN: Startup acquired by a large company and it sucks. What to do?
71–80 of 464 posts
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#72Assuming every coworker who doesn't do what you want is an irrational idiot acting in bad faith seems like a shortsighted and unpleasant way to go about your career. Stick around long enough and you'll most likely find out why what looks like red tape is actually holding everything together.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#73Yes, this is all big corps, pretty much. Hopefully you get equity and job security to make up for it. Before we were acquired i put in 10 hour days at least. Now a good 4 hours and I've gotten more done than most. So that's also a benefit
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#74Those feature request intakes occur because otherwise infra teams become bombarded with multiple requests per day. In isolation they're not much work, but the cumulative requests could take years and truly need prioritization. Being a recently acquisition, I recommend scheduling time with their manager to talk directly about your situation and trying to get on as part of their primary priorities. If that doesn't work…
Agree 100%.
However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling.
Now, if they don't have a roadmap, and their prioritization sucks, that's another matter, and entirely possible, of course.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#75> ahem: you told us to migrate to your platform
_Someone_ at $LARGE_CORPORATION told you to migrate, but clearly this team didn't. They have no idea who you are, what you're working on, what your timelines are, what the priority of this work is relative to other things happening at the company, or whether there's other things you can be doing in the meantime. Yet they actually did some diligence, got it approved (after 2 days even), and got it on their roadmap. As others have mentioned, you need to invest in figuring out how to get things done at $LARGE_CORPORATION. Acquisitions are a dime a dozen and certainly do not pre-empt things like security or compliance. This could be a great opportunity to dig in and develop a better understanding.
At large companies communication and alignment is generally more difficult to solve than any of the actual technical challenges. You may not like it and choose to leave, but at least try to develop an understanding so you can take that lesson with you.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#76I understand your frustration because I work in a large company and stuff can take forever. And this is the case for 99.9% of large companies. However one thing you should consider is this: there are probably 50 other people like you demanding to just have feature xy implemented. They are all totally simple etc.. until you have seen a large enterprise code base with lots of legacy cruft. Test suites that take hours t…
Quoted post unavailable.
>Is this how military's organize themselves, or do they just get shi*t done?
If you think the military isn't a large government bureaucracy with mountains of paper work, I recommend you talk to a veteran.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#77My recommendation:
When you're young, find dynamic startups to work on, there is a good chance you'll find the work interesting, learn a lot and get to have a larger proportional impact, and potentially have a decent exit.
When you're on the back side of your career, find a nice big company where you can hide in the cracks long enough to collect a paycheck before they question what it actually is ya do here. You'll have plenty of time for outside hobbies with little stress.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#78I think the difference is that you've been used to an environment where internal needs for improvements are addressed by a team you have close communication with, and a internal tools team (if you even have one), that services 50 people, instead of thousands.
Think of yourself less like a teammate of those team members, and more like a customer. If a customer wrote about your product like "I made a feature request, and they said it would take a quarter to implement!? I could implement it myself in a few days!", that would be unreasonable, right? You have a lot of customers, and you can't just directly implement every feature request without thinking about how it applies to other customers, not to mention that you have other work to do. That's closer to what your relationship with this team is going to be like.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#79I used to question the decisions of engineering leadership (in a small company of 50). When I was promoted to engineering leadership, I found myself making the same decisions that I had complained about.
You have entered a world of which you have no experience. You are simply not qualified to evaluate the performance or methods of the people around you.
You can take this as a learning opportunity, or you can run screaming back to the world of startups. Both are utterly valid and rational decisions. I did startups for thirty years, and now I'm in an enterprise. Part of me wants to run screaming every day, and then there's the part that gets shit done in an insanely complex environment.
If you stay, I recommend that you are the one that bends. Change your deployment system to work with their framework, not the other way around. Be pragmatic.
If you leave, do so quickly.
Either way, make a choice and act.
Now, if you stay, you may learn that, in fact, yes, the managers at this company are byzantine managers [1], or you may learn that this is an effective organization. If the former, get out.
I always chose the startup option until recently, and while my stock was never worth anything, I'd do the same if I was young again. Do so knowingly.
Re: Ask HN: Startup acquired by a large company and it sucks. What to do?
#80> So I reach out to the manager and ask what is going on. This is a simple task, I said. Why does it take an entire quarter for your team to deliver? He doesn't have an answer. Your simple task, which you think would only take a few days to implement, is probably one request in a long queue of requests that team is dealing with. That means they won't be able to start on it for a long time. That team probably set up t…
That sounds about right. I'd also note to the OP that in might help to treat the acquiring company like the Borg: they acquired you , and now it's on you to serve their needs, not necessarily the other way around. If your app isn't quite compatible with their infrastructure, the right move is probably to modify your app, not ask them to modify their infrastructure. That might be annoying, but it's probably also the r…
> If your app isn't quite compatible with their infrastructure, the right move is probably to modify your app, not ask them to modify their infrastructure.
This is my thought as well. The claim is that the fix on the infrastructure side should be a few days at most, but also that the infrastructure does not work for the app. If it’s only a few days for an infrastructure change, why is it so untenable to modify the app?
As an engineer (and manager) who owns infrastructure components, these “little” requests are death by a thousand cuts. They typically aren’t actually little, but even when they are, they forever add additional maintenance cost and complexity.
I’ve seen one deployment infrastructure/hardware management team take all of these little requests to make their customers happy and the end result was an entire team who basically did nothing except service requests from one final customer. They made the system fully customized for the one use case. I’ve seen another deployment infrastructure/hardware management team essentially refuse and tell their customers to fit into the supported model or find another solution. They provided a few standard hooks and said figure it out.
The former team died when their last customer moved to the later solution because it was actually supportable.