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

> 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 the onerous Google Docs process to gate requests because they get so many!

When they do start working on your request, maybe it will only take a few days -- or maybe you underestimate the level of effort required because you are new to the company and you don't understand the complexity of the systems you are dealing with.

Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. Instead, assume that people are dealing with a lot of other requests, from a lot of other people. Learn how the system works, and learn how to be effective within that system.

I know for sure that it's possible to be highly productive at a large company with a lot of bureaucracy -- but I also know for sure that new employees who try to bypass process and question the priorities of other teams, before they learn the ropes and build credibility and trust with other people, do not succeed.

>Is this how it's like at all large companies?

Not all, but a lot.

>What should I do?

Short term: Mentally check out. Embrace the Zen of just doing what's asked of you. It's not your job to be a go-getter anymore. Half because of institutional complexity/inertia, and half because in a tall organization hierarchy the middle managers don't want anyone below them swimming outside their lane (even if it would be to their unit's benefit and they can take every ounce of credit).

You'll notice that many people in this thread explaining why you shouldn't expect this or that from other teams. And they're not wrong, but none of them are acknowledging or explaining why those reasons weren't automatically communicated in your conversation with those teams. You're not only not seen as a problem solver anymore, you're also too low on the totem pole to be owed an explanation.

So follow the official processes to adapt their system to your product, and your product to their system. Keep your management in the loop about the time cost of both options, it's their problem to fix, not yours. Pour your mental energy into something outside work.

Long term: Decide if you like being checked out or want a new job.

A lot of people have talked about the issues with this post, but I wanted to call out one specific thing:

    The first engineer I talk to doesn't even attempt to answer my question but redirects me to their manager. Ok, that's odd, I think, but whatever.

This is definitely not odd. The whole point of managers is that they're there to protect their engineers from getting off track with every random request that comes up. I understand that it may feel bureaucratic, but as an engineer, someone who insists on talking to me directly without going through my manager is always going to mark themselves as someone who doesn't respect my time and doesn't understand that they're not the center of my universe.

This feels like a rant of someone who isn't willing to put themselves in the shoes of the other team and understand the real complexity of deploying and maintaining large infrastructure systems over long periods of time. Any "small option" that the deploy team adds today is most likely going to be an option that they're still maintaining 5, 10 years down the line. As the saying goes—"an ounce of prevention is worth a pound of cure". In the best case, taking a few days to get the requirements right up front is (hopefully!) going to save months and months of cumulative man-hours down the road for maintaining the system later, or making future changes. In your case, if I understand right, your work got approved within *two days*—hardly an onerous wait time.

I'll admit that the "for compliance reasons, you can't see our codebase" thing is kind of odd, and it would strike me as a bit of a red flag, but I'll also admit that, personally, if I was in that manager's shoes, I wouldn't want you anywhere near my codebase either. Just purely based on the way that you treat other engineers' time as worthless & fail to consider the possibility that the business has broader priorities that extend outside of your own personal tasks.

I 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 to run..

And then the team has to fix bugs that also pile up. Every fix makes the code base uglier.

And then people come along and want direct access to your repository to "help".

You see where I am going?

Long story short: it's not as simple as you think it is. If it really bothers you that much and you cannot understand "the other side", you should probably find another startup to work at. And I am not snarky.. this is my honest recommendation.

> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does not work for our app), they quote us a delivery timeline of end of Q1 in 2022.

This is where your manager (and if necessary their manager) needs to get involved. Is this actually important and urgent work? If so, they need to work with this other team’s management to get this done. If not, it can wait.

What you’re describing sounds like a particularly dysfunctional and bureaucratic corporation, but dealing with politics like this (and that’s exactly what this is) is part of being in a large company. Cynical people will say that everyone is just trying to protect their fiefdom, but most people are just trying to do the most important work.

That team you’re asking for work probably has hundreds of feature requests every quarter. The process is intended to protect the engineers from being randomized constantly by low value requests. But yeah, the trade off, especially if taken to extremes like this, is that it can slow collaboration to a crawl.

You wanted something done, you explained why it should be done, they agreed and will implement it.

I would quit that job immediately! I'm not even being sarcastic. If it bothers you that much that people like to plan things and that takes too much time according to you then yes, just quit. I've been on the other end of things where someone said: "Oh, I can implement this in 5 minutes". The first few persons I would happily explain why this isn't the case, but after that.. thank you managers for isolating me from this crap.

> 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.

One thing you should consider (not an infra eng myself, but I know a lot at the FAANG where I work) is that the infra team gets a lot of requests for stuff like that.

There's a general dislike of special-casing all build deploy run pipelines for some team's snowflake needs, since once you put a feature in, you have to support it forever. So one suggestion is that you look really closely at your own service and ask: can you change that to fit the framework? The majority of times an infra eng gets a request that amounts to "we can't use the framework until it does X", the answer is actually, "you should not want to do X, for reasons Y".

This might not be your specific issue, but if you want the thing soon, work on the parts of the codebase you do have control over.

And in general, yes. This is how big companies tend to work. Teams plan out effort far in advance. I have an ask to a sister team right now for 2022 planning, and I would be delighted if they came back and said "Q1". There's a million things all going on at once.

Echoing others who have gone through the startup -> $LARGE_CORPORATION acquisition, and having been there myself: just leave. It won't get better. On the contrary, it'll get worse as those worth their salt see the writing on the wall and head for greener pastures. Before you know it, all the people you love working with will have moved on, you'll be the only one fighting for progress, and worst of all, the burden of responsibility will fall increasingly on your shoulders as one of the remaining few with domain knowledge.

Consider it mission accomplished, startup acquired, check the box, journey over, on to the next one. The market for software developers is on fire right now. You'll have no problem finding a new startup to join, and you'll be instantly relieved.

Those 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, then your manager should be doing a better job getting other teams to be ready to support you.

Not what you asked, but stories like this are why competition is critical to the economy.

All large human systems, government, academia, business, whatever, converge to this. Everybody's comfortable, nobody's working too hard, sure, we'll get to it in a couple months...maybe. The paychecks will keep on coming, we can all go home at 5, everything's great.

Then, all of a sudden, some small startup "cuts corners", doesn't fill out the paperwork, kind of ignores all this "compliance" a bit, and somehow...out-executes you with 1/10th the staff, at half the price.

The immediate reaction is always disbelief, and rationalization. "They don't have feature X". "They aren't PCI-DSS compliant." Yet somehow, the customers are lining up and can't get enough. Someone figured out precisely what mattered and what didn't (what people were willing to pay for), and delivered it.

Single-payer healthcare, the DMV, and private equity-created monopolies are what happens when there's no competition. There lies the world of consistently higher prices, "waiting rooms", we can't do that because "it's never been done that way before", etc.

This is pretty typical example of culture change when moving from a small organisation to a large one. The thing that makes this sort of culture change so emotionally challenging is that involves a fairly dramatic change in values. This can lead to a lot of feelings of underappreciation and frustration, which can be overcome only by recognizing that values are not immutable and universal, but are instead highly context dependent.

Massively overgeneralizing of course, we can observe the following tendencies: Small organizations tend to value people who are highly responsive and who can work independently in a fairly unstructured and unconstrained operating environment. They tend to value people who can do "whatever is technically necessary" to rapidly solve problems and move the business forward towards it's goals.

As organizations grow, such forward progress is easily stymied and halted by interruptions and context switches from colleagues, and velocity becomes largely a function of how much such "frictions" can be reduced or eliminated. Behaviours and traits which were highly valued and rewarded in a small-organization context (e.g. highly independent problem solving and proactivity) can, under many circumstances, become liabilities in large organizations if they interfere with the smooth running of established processes, or cause disruption and confusion to large numbers of people. Reliability (and above all predictability) become far more important than responsiveness or (sometimes) raw velocity.

Needless to say, being able to adapt behaviours and attitudes depending on context is an exceedingly useful skill, and just because you were rewarded for acting in a particular way in a small organization does not mean that you will continue to be rewarded for acting in a particular way in a big organization. The two are completely different beasts, and it's the communications structure that drives the shift in values.

First off, how badly does the parent company need you to be on their VMs? It's probably necessary work, but not important. Everyone will still have jobs if it doesn't finish for a couple quarters. In the meantime, let your boss know you're blocked, start tracking this as a dependency, and go work on something else.

In my experience, it helps a lot to imagine the motivations behind each process in an uncynical light. Everyone is trying to solve their own problems, which aren't necessarily the same as your problems or the organization's as a whole. You went from an environment where whatever you were working on was a huge part of the overall organization to another environment where, proportionately, it simply isn't as important. If your startup had kept going, it would've ended up looking very similar as it got bigger.

Large companies are just startups that've learned more hard lessons. Every one of those processes were put in place in order to protect something or someone from the harms of doing what you're doing. They didn't emerge from nothing. You don't have to like it, but I encourge you to respect it.

Assuming 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.

I'm probably not going to add a whole lot more than what's already been written here, but pragmatically; if the deploy tooling isn't compatible with your app, and that tooling needs to support other apps as well, why not make changes at your end? It's a simple task right? Is it somehow enormously complex at your end?

What you should do, is realise you are no longer alone. You're not a small team at the fore-front anymore, you're part of a whole company of teams now and like it or not, these teams, whatever divisions they fall under and the company as a whole have deadlines and budgets. Someone looked at your request and plotted time. Does that not work? Find another solution. Don't complain about how its a small feature and you could fix it yourself easily, it isn't and you won't. Instead of arguing, being shocked and complaining about how insane it is, take a step back, talk to these people and try to understand how and why this company works the way it does. If after that it still doesn't work for you, you can always leave, but I'd honestly suggest you try to find a few people who can guide you around a bit instead of acting like the mistreated outsider, the only one who suffers there is you.

What you describe is a quite normal way to do it. It is not like they do not care about your task or too protective about their code base. It is that you are just one of the many stakeholders they have to deal with and they very likely have a huge backlog that does require prioritization. Apparently, your task is not a top priority one.

Besides, they may have a certain delivery process with quality assurance that was designed for their scale, which prevents them from a real quick fix. Deviating from this process usually does not worth it - one small exception will become a rule once noticed by others.

Leaving the company for that reason is an extreme. Adapting to this pace may make things more comfortable. So you were told to migrate your app to their platform, but you have a dependency and cannot proceed before infra team resolves your ticket. Just describe the problem to your manager and take the next task from your backlog. It is as simple as that. Maybe your manager will discuss priorities again with infra team and they will do it faster. Maybe it is not that important to migrate and you can work on some new feature instead - you will know about it soon.

The one thing that you really need to know about big corps is that the world is not circling around you and your needs. There is usually a lot of hidden complexity in the organization, that you do not see and may even never discover. This is why building good relationships with your peers is important: you can call it politics, but what really matters is that you should trust in the decisions of your peers and make sure that your process is good and your interfaces with other teams are transparent enough.

Many years ago, during the dot com crash, so not exactly by choice, I went from a startup to a government department.

I found it utterly soul destroying at first, but it was one of the best things to ever happen to me. I learned how to operate in a large organisation on much bigger and more impactful things.

It is very slow, and you may find that it really isn't for you, but I'd advise you to give it a go. There's a lot of good advice in this thread.

You have a task to do, which you said yourself is simple. Yet you've not been able to complete it. Someone could look at you and say "why hasn't lopkeny12ko completed the migration, I could do it in a couple of days".

Sure, you're blocked by that other team. But they are probably blocked by some other team, or by process put in place by some other function.

You aren't stuck in traffic, you are traffic.

I 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.

I've been in this situation (acquisition 2, below). You will eventually move on to another small company.

Acquisition 1: This was a quite insane dotcom acquisition. The VP Marketing loved us and bought us. The VP Engineering hated us, and dumped all our software first chance she got. Oh, by the way, those two VPs were married to each other.

Acquisition 2: Much smoother. I stayed around for a few years, enjoying coasting after the intensity of the startup. I continued to tinker on the product, and add incremental improvements, but the days of innovation were over. I also enjoyed the huge money they threw at us (raises, bonuses) to keep people around. They really needed to do that because interesting work ceased, and the amount of stupid process and politics was off the charts. (Example: they issued us windows laptops. We promptly wiped them and installed Linux. If service was required, we would have to reinstall windows, get the laptop repaired, and then again wipe and install windows.) I eventually left for another startup.

I did some work for a Large Company. One Monday I try and log in, and my hyper-secure laptop won't let me do anything. Try a few more times and then call my immediate manager, wondering if they've let me go or something. Nope, they're aware of the glitch and are working on it. I hang out and wait. Call again before lunch. Nothing. Still nothing at the end of the day. I call again the next morning. "Still working on it". I go for a nice bike ride at lunch time but otherwise hang out hoping it'll get fixed and I can continue doing my work.

In the end, it took them an entire week to fix it, and since none of it was my fault, of course I got paid. No one seemed to really mind that a week's worth of senior engineer salary was just gone. Except for me, I guess - I like coding and building stuff and fixing bugs and making things work.

I prefer startups, although I'd love to find a small stable company - one that's doing well but growing a bit at a time via revenue. Those are some of the best places I've worked.

This is not uncommon. Two things come to mind that might help: 1) Decide if you really care if this migration is on hold for several months. Your stuff presumably works fine still, right? If so, why do you care that the migration is delayed? Really take time to think it through. In the meantime, just report the delay back to whoever told you to do the migration and, if they have a problem with it, they can go fight battles for you while you do something else.

2) Recognize that $LARGE_CORP values != startup values. This can be really hard - you likely came from an environment in which getting things done quickly, efficiently, and sometimes really creatively, was highly valued, almost above all else. Those are good things, but now you are in an environment in which things like stability and predictability are possibly even more important, and a plodding, "inefficient" bureaucracy can actually work in favor of those values.

I found the above helpful while I endured a commitment to stay for a certain amount of time after the acquisition, but ultimately I missed the startup environment and returned as soon as I could. :)

I have been through this before. I don't think all big companies are like this, but there is a bias at large enterprises towards moving slowly and more carefully. Honestly, this is one of the main reasons why big companies buy startups in the first place. It is also a key reason for why many of these acquisitions fail.

There are really two considerations.

1) Do you have any financial interest in sticking around? A lot of times when there is an acquisition, the acquirer offers employees a bonus to stick around for some period of time and hit certain goals. Or the salary might be a lot better. It could be in your interest to stick around even though the work situation isn't great.

2) How crazy is this making you? One option is to adjust your expectations and get used to things moving a lot slower. If you really can't put up with this, then there are a lot of other jobs out there. The bright side of this gridlock is that you probably have plenty of time to look for a new job.

In my case, I lasted about 4 months before I left. Within about two years, the product had been shut down and everyone involved with the acquisition had left.

> I'm working on migrating our apps to the parent company's VM launching and deploy platform. Should be fairly straightforward, I think. Unfortunately, the deploy tooling isn't entirely compatible with our app so I ask the team if they can implement $X feature to support our app.

That's your problem right there. That VM launching platform is most likely supporting dozens of other applications. They team handling it want to be doubleplussure that your request won't break any of the other applications.

And there are at least 42 "quick two hour tasks" in the queue before you.

As others have said already: you have two choices. 1) Embrace the zen of working inside a bureaucracy 2) Find a new fast-moving startup to work in.

I worked for a company for a decade that grew through acquisition. Their business model was slow moving, risk averse, and lean staff. And they made a ton of money.

They bought troubled companies that were agile, over-staffed, and most importantly unprofitable and our job was to integrate them and then gut the staff to bare bones. Typically those unprofitable companies were profitable within 12 months. The existing staff at these acquisitions hated it because they had only ever known their unsustainable unprofitable way of doing things.

"I used to call X and he could do this right away".

"Interesting. Is that why your company was bleeding money and the owners came to us begging to have someone buy their sinking ship?"

You were bought. If you don't like the new company, you can leave. You can try to tilt at windmills, or you can stay and open your mind and maybe you will learn the real reason things work the way they do at the new company. Finally, maybe you are right about all of this. I would quit and start your own company and crush your current employer's inefficiency in the market.

Here is a blunt question: Why do you care about being able to migrate your apps before the end of Q1 2022?

Is your management expecting you to do it faster? Then you need to put your management in touch with the managers you're talking to.

Do you think your own longevity at the company / bonus / performance review will be impacted? Then you need to talk to your management and make them aware of what's going on and that you have gone above and beyond to try to make this work but are still hitting a brick wall.

Do you have nothing else to do at work and you're stuck? Then find something - either by talking to your management, again, or by asking around.

Do you just want to feel the pride of a job well done in making some company's VM deployments slightly more compliant with policies set by people you clearly already dislike for good reason? Then take a step back because you've spent too much of your life living for this startup and not for yourself.

This happened to me too.

Small company, very fast paced, learned new tech very quickly for two years and actually pumped out awesome products (in addition to other small company perks).

After the acquisition, the way we worked completely changed for the worse. I ended up leaving and so did about 50% of the developers.

Promotions became much more difficult to achieve, raises were below or only matched inflation, and pretty much every aspect of work became more bureaucratic. This was exactly why I had left my previous company, and I ended up leaving this one as well after giving it a shot. Stagnating my career was not worth it especially in a hot job market.

I’ve been there before.

It’s all going to come down to your manager. You shouldn’t be out there fighting for resources from other teams and arguing their relative priority. Your manager needs to be working within the new company to establish priorities and get the appropriate time, money, headcount, and resources in place to make these things happen. The platform team won’t automatically know your situation and it’s not really your place to drive it. Get your manager involved.

However, you have to watch closely to see how your management chain is handling the acquisition the great energy and enthusiasm they had for the startup might be completely gone now that they’ve been acquired. If they’re only sticking around long enough to cash in their earn-out provision, they may be completely uninterested in helping out. If this is the case, you probably aren’t going to get any happier in your current role.

End of Q1 2022 for a significant feature sounds reasonable for a large company (a few days to implement means a few weeks once you include design, documentation, review, implement, test, deploy).

It's annoying, but everything takes longer in a big company because every change you make can affect many teams/customers, and it's very hard to get unscheduled project work done quickly unless it's a real emergency.

Your best response is to make porting your apps to their platform dependent on that change, so you can't do it before end of 2022Q1, escalate the dependency to your manager so he/she can either elevate the priority of the feature you need, or just live with the timeline.

It's annoying for sure, I work at a growing company that used to be a small startup and am often dismayed at how long it takes to do even trivial changes, but am also reminded of the time that we accidentally caused a full outage for all of our customers with a config change that was deployed everywhere before we discovered a problem. We didn't bake it fully in the QA system (where we would have discovered the problem) because everyone "knew" it was a harmless change similar to others that we make all the time. We esentially applied it to QA to verify the syntax, then rolled it out globally, where it ran fine for a few days before filling up some temp space. So now it takes at least 2 weeks to roll out those "simple" changes due to mandatory documentation and testing.

You're clearly a startup person, and won't be happy at $LARGE_CORPORATION.

You should probably accept this as a fact, and figure out what your next startup will be. Join an existing one, start something with some equally frustrated coworkers?

You have some time to figure it out. Just like it takes them 6 months to do your simple code change, it'll take them as long to fire you if you stop working.

I worked at Citi for a while and this pain sounds familiar. It once took me 6 months of hounding an MD to get approval for my app to connect to a particular database.

It sounds like you're very motivated and presumably talented, but the organizational friction doesn't really allow for your blessings to shine.

On the other hand, this is the reality for many many people and many many dollars. It's a great opportunity to both develop empathy for a kind of user you never imagined (all those people trapped in these processes for life) and to learn new ways to excel, within the context you're currently in.

When I was at Citi I learned a lot about communicating with stakeholders and fostering internal relationships which has been very useful in my career. Maybe you can find the same there ?

> 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.

Have you never worked on a team that had work planned out months in advance? Usually IME the team will only plan out the next quarter in any detail since things always change. But the product team and managers often have a roadmap (high level plan) extending out a year or more.

Most likely this team has already planned their Q1 and has given commitments to stakeholders, etc. For your work to jump to the head of the queue it would need to be more important than what they've already planned. Yes, maybe your request only takes a few days, but odds are that the team has dozens of requests on their backlog that are just a few days worth of work. If you want to try to get them to prioritize this work then someone from your team (typically PO, PM, or manager) needs to reach out to the other team and communicate what the impact to the company will be if your team is blocked for the entire quarter.

P.S. - Sort of a tangent, but this scenario is one where a good scrum master is worth their weight in gold. Once you communicate to the team that your work is blocked the SM can take on figuring out who needs to talk to who to try to prioritize the work, and will stay on those people to follow through so that you know when you'll be unblocked and the team can adjust plans accordingly. It may sound like a small thing, but it's wonderful not having to deal with it yourself as an engineer.

I 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.

[1] https://twitter.com/ncweaver/status/1473084555976273924

I worked at a startup that was acquired by a larger corporation. This echoes my experience as well, everything became so clogged up with processes, documentation, responsibilities so distributed that there were times it became unclear who was responsible for what. I had a bunch of arguments with other departments and upper management over processes that were directly impacting my team of engineers, but eventually just caved in. Meeting glut, passing of responsibilities, nobody stepping up to get stuff done, and a bunch of other things that made me unhappy. They at least treated me well enough all things considered and I had multiple promotions, but eventually I got so burnt out I just left.

I don't think it's necessarily like this at all large companies. I had worked at a much, much, much larger company before and never had to deal with anything like that. It really comes down to the company that acquires the smaller one.

I mean look at Blizzard, who inevitably just became Activision despite years of claiming they would not. The process / culture of the company that acquires the smaller one almost inevitably wins out.

You have to realize that the company you worked for no longer exists. It was acquired and is something else entirely. If you're unhappy, I would suggest to consider looking around for different opportunities.

Your story lacks all the details that makes it interesting. Which company? What's your app? Why is it so different from existing apps that you cannot work out how to adapt on the current deployment system?

Nevertheless, yes it's very similar to my experience of bigger corporations.

First of all, you should understand your local political landscape, find allies, build your network and trade favors.

Second, things are going to take longer, there is no workaround for this. Wait until you discover you need approval from the security or ops teams for your app, you'll understand what I mean.

Then, you should also understand that you won't be able to get access to things and ship patches in projects on which you don't have responsibilities. That's expected, what do you think would happen if everyone would do the same ? On the same topic, respect your fellow engineers' time, always ask your and their managers first.

Last, you might have to talk to consultants, now (hi, it's me). It doesn't matter if they are strategy, management or AI consultancy. What does matter is that they have MUCH MORE political power than you. So, if you don't like their ideas or their approach, remember to always be nice and helpful or you will be shunted, demoted and removed from valuable teams and projects.

Welcome aboard.

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.

This is normal. You need to fill out all that stuff because the other team has a huge backlog of work. They could probably do it in a couple of days if they had nothing else to do.

Absolute shock? Q1/2022 isn't that far away in "big company" terms. It's probably easier to keep running your app the way you're doing now anyway, so what's the big deal?

Don't worry about it and move on.

https://komoroske.com/slime-mold/

You're welcome.

Based on only what you have posted you should leave in a controlled manner. No matter how you feel, you should avoid doing things that burn bridges. If something catastrophic happens, I've seen large companies be incredibly generous, either by opening up roles to take folks back, or offering long-term contract jobs where the person gets back eventually. Smaller organizations rarely have the flexibility to make that happen.

However, there are good reasons not to leave immediately, including vesting, the opportunity that being acquired by $LARGE_CORPORATION may present (you aren't solely responsible, but you've helped build something that was acquired, which is experience worth something to some people), and expending perks that $LARGE_CORPORATION may offer (often these aren't all made visible to you.) If you have trusted peers that have left, or are potentially leaving, you may want to check-in with them.

At large companies, I've always been in the habit of expecting one thing I need per quarter. That means that if I need something this quarter, I put it on the other team's roadmap for next quarter, and then do my integration the quarter after that. (My experience was an organization where OKRs were the root of all planning. If you are working with teams that do bug triage / prioritization / sprint planning every two weeks, then obviously the latency can be decreased. But quarters seem like an artificial boundary that people love for whatever reason.)

This sounds terrible, but it worked pretty well for larger things. I was a TL and was in the habit of meeting with my internal customers before quarterly planning, to make sure that we could add their requests to our todos for that quarter, and then make sure we always executed on them. (We did do the things we promised, so people could make accurate plans. I remember many quarters of people sounding mildly shocked that we did stuff they asked for, but after a track record of execution, we got trust without any pushback like "can you do that right now instead of next quarter?")

Obviously, this doesn't help you very much if you want to get your thing done today and move on to your next task. Your product and your integration is going to look like the org structure that your company has. If you need deep integration with the product but are a separate team, well, I've simply never seen that work. The teams need to be much closer together in the org for that to happen.

Edit: oh, I'll add one other thing. Once planning starts to work, you can kind of dial up or dial back how quickly you want to react to one-off tasks or special requests. For example, if your team has a track record of completing 100 story points worth of work per sprint, you could only take on 80 story points and use that capacity for special requests. Planning sounds like a drag, but the discipline is actually very useful.

This kind of thing is more or less how large companies work. These specifics sound pretty bad, but inability to do work that isn't on the roadmap and a roadmap that's written in stone once a year (maybe twice if you're lucky) is very common. The way to be able to get things done is to reduce dependencies on other groups, especially other groups that are impossible to work with; but that might not fit with corporate policies.

If your retention compensation is good, try to learn to accept it and just keep getting things done, even though it takes longer and you can't get as many things done, until the retention runs out or you can't take it anymore or whatever. If the compensation isn't good, then it's time to look for something else.

One of my coworkers left rather than be part of an acquired team. He had been acquired before and wasn't willing to deal with it again.

The redirect to a $LARGE_COMPANY/process is best understood as what everyone who does not have $THE_WIRE/suction deals with to get anything done. No one that matters at a $LARGE_COMPANY is impeded by the process unless they want to be impeded by the process. (eg: delaying tactic, turf war!, pass for political reasons, don't think it matters and so can't be bothered, think that the request is wrong for reasons, and so on.)

Large companies view your day-to-day activities through a very different lens than a startup, and they want you to use a very different lens as well, and you'd need to get the right combination of manager and mentor and team and teammates and yourself to get the payoff.

I'd roll into another startup; since you haven't, I'd assume you have reasons for not rolling into another startup, but it's getting kind of abstract at this point.

If you can't change your Company, change your Company.

You have two choices:

1 - Get a new job (at higher pay) in this hot market

2 - Wait for your remaining equity to vest / meet the acquisition's earn out milestone, then execute option 1.

It's simply a "two cultures" question (look up the book if you care). If you're a startup person, you'll hate big companies. (And good, effective big company people frequently flail when they join a startup). I'm not claiming one is better than they other (there are things one can do that the other cannot, and vice versa).

My gf is a big company person and she tried to get me to switch, but through interviewing it was clear to me that I wouldn't enjoy it, and often clear to the interviewers that I probably wouldn't work out, even when I'd previously done precisely what they were hiring for.

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.

I'd suggest you leave and find something else. It doesn't sound like you are cut out to handle the corporation structure politics.

> 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.

This was probably career ending at your company, I expect you have been added to a layoff shortlist somewhere for the next round of downsizing.

Go find something else sooner rather than later.

I went through a similar situation 2.5 years ago and had a pretty similar reaction. Reflecting back on this experience, here's what I'd tell myself knowing what I know now.

1. Accept that you are now in a Rest & Vest position. The days of "all hands on deck" are now behind you. Nothing is a fire drill anymore and no one really cares (nor is incentivized) to just do things quickly.

2. Do a problem audit of the biggest challenges you faced/solved for pre-acquisition.

3. Start making an exit plan based on your vest schedule & any other financial incentive schedules you may be on (ESPP, 401k, etc)

4. Start working on solving one of the problems you uncovered in your problem audit. Do your best to pre-sell the solution before you code anything.

5. Leave after you've been able to successfully presell your solution to atleast 10 paying customers.

OR

LEAVE and find a new job at another startup

Some people thrive in a process-oriented engineering culture. I don't, and it seems you don't either. Be true to yourself: find other work. When an interviewer asks, "why did you leave", answer "I learn more and do better work in smaller organizations," or even "that big-company stuff is not for me."

It's an important step in the development of your career to understand this about yourself. And, you've been lucky to learn it relatively painlessly by going through this acquisition.

When you go to work at this place, put on your anthropologist hat. Observe what you see happening, and observe your reactions. By all means talk to your supervisors and colleagues about it. But don't gripe, learn. Think like a visitor to a strange land.

> you told us to migrate to your platform, and it literally does not work for our app

You were told to migrate to their platform.

They were not told to change their platform to support your app.

That the request has come from you, an individual engineer, means that it is going to be prioritized far below a request that has come from, say, their skip level's skip level.

You are being told, politely and indirectly, to mind your own business.

Yes, this is how a lot of large companies work - I've worked at several like that.

As far as what to do, it depends on your comp. If you're still vesting, mentally check out and rest/vest until you make enough to feel comfortable. Depending on the company, it's pretty easy to get by doing nothing, and/or you can work on your own stuff on the side.

If you're not vesting anymore, the vesting amount is not worth it, or you prefer to move faster / do something, quit and get out.

Alternatively if you want to stay, a large company is a different game. Again depending on the company, but it's more about image, strategy, politics, and non technical sort of work.

>What should I do?

You should take a moment, and try to understand the other side of your request.

Read this response from /r/antiwork, it's about a new manager having to get his team to understand work life balance: https://www.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...

Also, this issue goes beyond you. If you need something done, with a different org, that is now on your boss to figure out how to get that done, not you.

It's really simple. Remember how it was in school? There was nobody in your class like you. In your year? One or two you could actually talk to. Now, in a big corp, it's basically like in school again. Just get out of there.

And the people telling you, that's just the way it is, and the managers have their reasons? Of course they have their reasons, but they are not yours. They have families they need to take care of, they got used to their big pay checks, and all of these things make it impossible to do certain things anymore, although they might seem simple.

Don’t think of it as one company, imagine every team is a company. What you’re experiencing is no different from when I use a SaaS product and I would love them to implement a feature in their API, but it’s not their priority.

Imagine if I asked that SaaS company for access to their codebase so I could submit a patch.

Large companies spend more time on coordination, risk management and the mythical “alignment” than smaller companies, who spend more time doing. If done right, this creates economies of scale, as well as the predictability that Wall Street asks for.

But… To thrive you have to focus on a lot of less fun things. And excellence at the expense of the things listed above isn’t valued.

If you love the small company work environment more than your specific product, then you should consider an exit. If the value of your golden handcuffs is too high, then play along.

The solution to this, as to so many work problems is: move on.

I promise they will get along fine without you, you will get along fine without them, and new adventures are in store.

If the new posting doesn't work out, after a few months, it is a problem with the posting, not with you or with moving on. Move on. Nobody will think ill of you for it.

Almost all my career mistakes were not moving on when I should have. You don't owe them anything, and you cannot prove anything to them. Somebody else will be better equipped to appreciate your contribution than they are.

I’m a consultant. This is my experience at most large companies, at least in legacy industries.

Different large companies have different cultures, which mostly is about how much the employees like each other. But they’re all giant, kafkaesque bureaucracies that our government red tape to shame, in my experience.

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.

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.

There is missing information. Presumably you have some retention bonus or stock. If not, start looking yesterday.

If you do then you start calculating what it’s worth to you, is it a private company? Is there 401k matching? If you can keep your mind occupied, you rest and vest and plan the next chapter. It’s also worth considering what you can learn, they aren’t stupid, these processes usually have a reason. It’s a reason that startup folks are immune to, it doesn’t mean it is invalid. Life changing money isn’t always life changing money, I couldn’t retire on $500k, but it did change our lifestyle, we paid off a house and had enough to save a good chunk and put a down payment on our ski condo. It was easily worth 3 years of not fun job.

The last one? I got about $75k in stock in a private company, they will have a liquidity event at some time but it might not have been worth 2.5 years. I don’t regret it but it was particularly unfun and had some toxic elements.

Also worth considering, I did the same drill and ported and built new tech on “their platform.” Punched it through, fought uphill battles every day, and got it done. Turns out, they didn’t expect it so I became a made man in their org, I could do stuff. I got a reasonable promotion from it and some more pay and whatnot. It felt good, might not have been the best financial choice but it wasn’t bad.

I have seen this happen many times - the only way to get other teams to prioritize your work is to convince your leaderships its important so they can talk to the leadership of those team that it is important. Sometimes, even after leadership pressure, teams refuse to move priorities or don't deliver on time - always account for those as well.

No matter what you do, the slow pace & politics of large companies will hinder your growth. There would be some features/projects that would be absolutely unfeasible - not because they are technically harder but because you won't be able to reach alignment.

Smarter thing to do in these situations is to move on to something else that can deliver impact. If you keep delivering impactful features on your own (even if it means some duplication of effort), you will notice a lot of other team's manager would be interested in integrating with you as they now think of your feature/product as a potential cash cow & the cycle turn the other way - you product grow way faster than you predicted because now the company is working to enhance it & in doing so, they will bring customers from different touch points the company has resulting in a stronger moat.

Ofc, all this requires patience, vision, strategy, politics & luck. Its different ball game from startup where you throw N things to the wall and expect K things to stick. Here you can only throw maybe N/2 things to the wall and maybe K-x things will stick but if your strategy is correct, those K-x things will be far valuable in a big company.

So, the cost to the company becoming large is that politics exist. There are too many stakeholders and they want to pull things in different directions and you have to be politically savvy in order to balance between them.

This is not everyone's vibe and it is why a lot of Open Source software does better with a benevolent dictator than with a democratic process. For instance it's the reason that I don't contribute to Wikipedia.

Once you realize that you're particular situation is a political problem the solution becomes obvious. You stop working on the “required upgrade”, citing that you are blocked on this other team. If possible, track your onboarding feature in the big company's issue tracker, and link the two bugs as blockers. The political side is, if somebody actually needed you doing this VM migration work, they need to escalate to this other team. Or, they need to give you a big juicy high-profile project to refactor your code, to not do whatever it was.. and this gives you plenty of space to also do all sorts of other things that you never get to budget refactoring time for. Your call whether you like the game once you know how to play, or whether you nope out like I did with Wikipedia.

Wait to vest, and then leave. Don't put too much of your identity into who you work for and things that are out of your control. Start some cool side-projects or whatever it is that makes you happy. Basically, don't leave in a huff and sacrifice some financial gain that you might get by sticking around for say 1-2 years. Time flies. Maybe none of this applies to you, but I'm counseling against flipping the table.

I love how this thread is full of startup lovers complaining about how big companies don't just spend all day scrambling to do whatever the nearest tech lead mentioned at lunch.

Meanwhile, these same people are complaining about how AWS has a minor outage in one region that is preventing them from getting their work done or hurting their business.

Take a moment to reflect.

To sift through all of the noise, the answer that makes the most sense is 1 word: quit

In your own words it “sucks”. If you don’t want it to, your only real options are to accept the new normal, or find a new job. In organizations of that size it will be a grinding multi-year (decade?) marathon to make any company-wide change.

If you’re an engineer, and have an acquired startup on your resume, you should have no issues finding a new role at another company that has your ideal employee size & culture.

Edit: I don’t mean quit today and walk out. But rather, have a new job be your new primary goal and start the search. This will help you get through the days you have left (you’ll be amazed how much mental relief is provided when dealing with a stressful situation, but then realizing - I don’t have to deal with any of this much longer), while being responsible and not leaving until you have a new gig lined up

Just leave, seriously. I spent way too much time in the same situation waiting for things to get better and they never did. I did this twice; once for 6 years and one for 2. It won't get better, but it will make you worse at your craft. The only regret I had was I should have done it sooner.

> Is this how it's like at all large companies?

Pretty much. Hearing about a large company that moves at any appreciable velocity is the exception, not the rule.

> What should I do?

If you have stock, it's probably worth it. But maybe not -- you're the only one who can decide. What do you value more, money or happiness?

You just moved from a family to an organisation.

I was part of a small company that grew agressively. When you're small, you're a family - you know everyone else, you know each other's strengths and weaknesses, you help each other out, and things get done fast.

At a certain level, this breaks down - someone drops the ball and management decides that they need documented processes and systems for everything. Then you need more managers to make sure everyone is following the the processes and systems, and then you need meetings with those managers. Productivity drops by half, the number of forms you need to fill in multiplies by ten, and you get really frustrated.

I'm with you - I hate the inefficiency of larger organisations. Leave for another small startup, or even better, start your own.

As others have pointed out, the software department is overbooked. And acquiring companies always underestimate the cost to clean up and integrate the software of the acquired company.

Try to get yourself transferred into the silo'd department if possible. You're not going to change corporate life. If you can stand corporate life, you might as well move into the most valued department that you can get into. If you can't stand corporate life, well, your options are the same either way. But you can use the transfer as a way to evaluate and update your skills.

Are you free to leave or is there some hold on you like options, stock, or earn out? Then leave, flee, run away as fast as you can. Your startup was bought, and if your old leadership is no longer in a position to handle the transition, then you are a man without a country. You have no advocate, no support, no network.

This is not about culture or change or Big Corp vs startup. You are on your own working for a company where no one has a vested interest in your career or happiness.

Leave. Leave now. Start interviews on company time and get out. Leave and do not look back.

Perfectly normal; a lot of big companies are broken - but... sometimes you can find an interesting/sane part of a big company; you could try and get yourself internally transferred to a sane part. I've seen whole teams from a startup move inside the big company away from the part that organised their purchase since they were so broken. Or just leave; the big company owes you nothing [or if it does at given specific dates, just hang in for those and plan your escape]

Since they are so concerned with compliance and documentation, it sounds like a health or banking firm? If they do it in a quarter it's fast.

One reason acquisitions fail is the differing planning cycles of the two companies. If a company that does annual planning buys a company that does things at a faster rate, then they often run the acquisition into the ground, as waiting a full year to shift directions can be far too long in many industries.

This is honestly why so many of the large megatech company products are slowly grinding themselves into feature decay, automated and algorithmic decision making with very little human oversight, and just so much away from what people expect of tech "innovation" companies. Every day the tech industry is looking like the old Ma Bells and bloated companies that ask so much and deliver so little but keep us all so captive.

> have always worked at startups

If you want that invariant to remain true, it is logically necessary to leave.

> Unfortunately, the deploy tooling isn't entirely compatible with our app

I'd say that apps have to adapt to existing deploy tooling, not vice versa.

Platforms are historically slow to adapt to applications not written for those platforms; almost invariably, the motivation to work on some platform, and the subsequent porting, comes from the application side.

> Is this how it's like at all large companies? What should I do?

I'd say that it's a bit of a Dilbert caricature of how it is, but in some aspects it is representative. In a big company, there are other divisions and teams which have entirely different priorities from yours. They have their own work items and milestones; and it is a fact that managers protect engineers from taking on work from side channels. This can be a good thing: in a big company you can take advantage of that to reduce distractions and stay focused on something.

Just because your idea is approved and scheduled for sometime in 2022 doesn't mean they are just twiddling their thumbs, but it does seem as if they don't share your view of how urgent the feature is.

Source code repos not all being open company-wide is also not unheard of. The ownership boundaries tend to be clear.

If you were to work on that software to submit a patch, one of two things would happen: it would be something like a customer request, where an engineer has to be assigned to that patch and be responsible for integrating it: getting it to pass all reviews, and do additional work on it like test cases, documentation and whatever. Or else, you would have to effectively be joined to their team to particpate in all that: get the associated ticket assigned to you, have access to all their systems (repos, bug databases, code review, documentation, ...).

Probably best to just let them own it.

Any sort of priority shift (your application A being an important payload for their delivery platform D) will have to take place at the management level. Your management convinces some higher management (that is above both of you) that this is important, and then that comes down as a mandate to their team: please give your cycles to A.

This is how it almost always is.

It's the bureaucratic horror of large companies (for me, even HP when it was a Fortune 20 company, had it's irritations) that drove me to entrepreneurship. Being bought always means you have to return to that in some ways.

Here's the trick: plan for your "exit from your exit" when you are planning your current startup. I sold my recent company in 2018 and we already had plans for our next startup long before our exit appeared on the horizon. Thus we had our attorneys write our acquisition contract such that nothing in our future plans would be outside of the SPECIFIC purchase contract would ever be included or be on the table. At the same time we've used our post-tax purchase revenue, salaries, bonuses and commissions to provide seed money and investment in our next ventures.

The key thing: we "knew", and still know, we have multiple startups in us. Some are "singles", some are "doubles" and we have only one that might be a "home run". But all are on the table.

This sounds more like a misalign of interests. You primary interest is getting things done asap. The VM team's interests is fuck up things as little as possible. They don't care about your primary interest.

The whole structure of big corporation is structured in this way. Different apartments have different interests in concern. If you could align, fine. If you can't, then it sucks.

I hate to say it, but, in agreement with many others here, this isn't all that unusual. It's probably on the worse end of normal, but isn't abnormal.

What do you do? Well, I assume you have some sort of retention bonus or stock lockup that requires you to stay for a while if you want the money, so decide if it's worth it to you to stay, and quit if not.

If you decide to stay, you'll have to find a way to remove yourself emotionally from this work for a while. Stop caring about how long things take, and coast for a bit. Rearrange your time so you front-load things that you can do on your own, without onerous process or others' permission. Try to anticipate things you'll need to get done that will require coordination or help from other teams, and start that process as soon as you can.

I agree it's frustrating, and not what you're used to, but if the money is good enough such that you want to stick around for a bit, you'll have to adapt both your attitude and how you organize your work.

Many large companies are like this. Personally, I find it very frustrating. At one place I worked that was acquired, the teams decided to silo themselves off (no outside patches) with SOC2 or something or the other determined to be the reason. There were many parts of the system that I knew better than the teams themselves and I didn't have the commit bit. It was a nightmare and through lots of work I managed to get commit. It was successful for a bit but ultimately I was expending a lot of social capital and even if I took on full ownership for maintenance and delivered on it, the standards people hold for their own team are usually lower than what they hold for someone like that.

I left to go on to other things. The company was successful without me and I was eventually successful without them. I would have been unhappy there and they would have been overpaying me for what I provided considering their constraints.

Yes this is how it is at almost all large companies,

No, you don’t have to stay, that part is optional. Lots of startups are hiring.

I work in a $VERY_LARGE_COMPANY (over 100,000) and this is how it works. The best way to solve problems are:

1. If you really have to do something with a different team, escalate. If you are not ranking high enough, ask your manager or second up manager to talk to their manager or second up manager. I am in lower management, so I can solve some stuff directly, for some I ask my director to help, once in a while we need a VP to help.

2. If that is not really needed, drop it. But tell your line management that you are dropping it, document it in writing, get their confirmation.

Large companies are all about priorities and focusing only on what is big. If you understand that, use that information properly. In a very small company with very little complexity and overhead you can have great flexibility, not with a huge construction. Ants are agile, elephants not really.

Completely agree with what everyone else has said about working at a large company, and how past a certain point your changes are not just your changes - they affect the organization as a whole.

The good news is, you can fix it diplomatically (I used to see red, too, when I got stonewalled like this).

The magic words are “risk” and “escalate”. If your project will be at risk, you bring it up to your direct manager and PM and ask him to escalate the issue. Once a request goes up and comes back down, I find there is usually extra motivation and bandwidth on another team to help with the issue. And if it doesn’t get escalated? Well, then, that work might not be important enough to address at this moment, which means there are higher priorities. So, ask your manager for other work since you’re blocked on this one piece.

People here are quite caught up in why things are this way and whether it's right. But I 5hink that is irrelevant to OPs question.

OP cannot change the organisation he is part of. He lacks the authority and even if he had authority (was say CEO) changing organisation culture is really hard.

So OP must either put up or leave.

Whether, How and When to leave are the questions.

These depend on OPs circumstances:

* What other opportunities does OP have? Are there interesting startups hiring in his area (geography and expertise)? Could he start his own business? Would the mega corp let him start a separate business unit with some autonomy?

* What are ops finance's like? Can he afford to quit without another job, go to an insecure job, become an entrepreneur? Will he get a nice big bonus or stock vestment if he stays another X months?

* Does OP really care?

twblalock's response in https://news.ycombinator.com/item?id=29641795 is very well and I support that view.

However I want to add an important aspect: The company acquired the company and the deeper they integrate you the more the corporate culture will take over.

If you don't like corporate culture with all it's ups and downs you don't have to have a false sense of loyalty, especially not to the past company. The past company is gone as the owners gave it away.

Thus either accept the change and use the benefits of structure, some saftey and predictability a corporation can give or seek a challenge more to your liking.

It took me nine months once to get a 3 -line change into production at Amazon (and this was in the early 00s) Yeah. Large corporations are crazy. It was change to a naughty words filter and that triggered all sorts of reviews.

> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does not work for our app), they quote us a delivery timeline of end of Q1 in 2022.

Get this documented and stall your own work. When management asks for status report, point them to this delay by the other team.

Management is paid big bucks to handle resources. If your manager cannot get you the resources by negotiating with another manager, IT IS NOT YOUR PROBLEM.

Welcome to large company politics. Your actual output is not important. Hold your management accountable.

This is what I did. Worked there for another year. Enjoyed the options payout (it wasn't much but it was something).

However, slight regret was the larger company's stock was worth WAAAAY more 5 year later. Like 5x.

Sadly this is usually the case in big beasts. The measure of performance, success and efficiency is very different.

You have 3 choices:

1) You either accept this is how it is, collect a paycheck, and live with it.

2) You try to change it. But you are 1 against 100's or more. Not likely to happen.

3) You quit and find a new gig.

I have tried all 3 multiple times but now skip 1 and 2 and just go right to 3 as soon as any retention bonuses expire.

I have been through a total of 11 startups being acquired, 3 of those as a (co)founder, 6 of them an advisor to the process.

The recipe to get acquired is simple once you realize what these big companies are looking for.

You have huge misunderstanding about the relationship with the parent company. You think you are a valued customer, however them think you are a burden that does not help their bottom line. Get it?

If I were you, I would ask myself this question first: What is the motivation to migrate to their platform? Is it from your team, or is it from some requirement of the parent company? If it is the former, I would retrofit my app to fit their platform, even if it would take 5X or 10X the effort. If it is the latter, just sit back and let them drive the process.

Having worked at startups for last half a decade this would be my dream place.

> Is this how it's like at all large companies?

No.

> What should I do?

Find another (startup?) job.

Because it doesn’t look like that place will change and I’m pretty sure they have good reasons.

You just simply escalate to whoever is asking you to the parent company's platform. And lay out the consequences of it not happening - it's as simple as that.

When your manager asks "why isn't this done yet" you document what you've said here, and say you're blocked. Any sane manager would escalate and see why it isn't done. If it truly is a company priority, it'll get unblocked. If it's not a company priority, it'll continue to be blocked, and you'll work on something else.

Short answer to your question is: yes. As a general rule, as the corporation gets larger, the work becomes more process-oriented, until it reaches a point where the process is the work.

Working in a startup is very different from working in a corporation, as you found out. As a single developer, you can not change the big corporation in its ways, how ever wrong they are. I think you have three options:

1) keep trying - and burn out in a few years

2) Adjust to the corporate life style stop caring, make do, and find something else important in your life. A hobby, a side project, something to burn for.

3) Get the fuck out of there, find (or start) another small company where you can feel at home and do meaningful work.

Good luck, what ever you choose!

> This should take no more than a few days to implement

I have many of these it "just takes a few days requests". There probably aren't many people that can actually implement these changes and the ones that do have other stuff on their tables. The company I work for isn't even that large, but I mostly have 2022 planned in advance.

Understand that you are annoyed, but you should just explain to your manager that the migration will not happen before mid 2022 because requirements aren't met yet.

"Is this how it's like at all large companies?" Short answer is probably yes. Depending on where you are located, but with large corps you may end up with SOX among other things.

Over time all the tools will fine tune to all the new processes and the overhead will hopefully be reduced. If there is ambition for this.

Also, have in mind that many large security breaches happens when large corporations acquisition smaller companies and tries to incorporate them too fast.

Do not be too quick to switch job is my general advice.

My 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.

Count yourself lucky you had the necessary kit to actually interact with the codebase at all.

I've seen large corporations dragging their heels getting basic laptops, database access or repo permissions out to devs, even when there's some critical fix required.

Accept there's little you can do in these situations except play their game. You're now going to have to figure out whether the financial gain is worth the loss of agency, simple as that.

Reminds me of a multinational where I had to "purchase" infrastructure from the team in the next workspace to deploy our new application. Literally all the paperwork and requirement gathering you'd expect from getting external providers/contracts, run through an internal system with all sorts of forms and people being brought "in the loop", yet the infra team was literally a few desks over... '

This is completely normal. As companies grow larger, systems grow more complex. There are more moving parts serving more users, so for any given change you are more likely to encounter unexpected problems and those problems will take longer to fix and present more financial risk to the company.

If it weren't for this sort of diseconomy of scale, there wouldn't be any small companies; large companies would control everything.

Welcome to the wonderful world of large_corps. Yes this is normal. The crazy part is it sounds like you are in a good one, since you didnt have to sit in three seperate four hour meetings with a project manager for this request. The good thing is now you are work free till sometime q1 2022. Get a part time job and double dip. Take long walks and level up skills. Learn the corp structure and internals.

The market is saying you should go solo and work on Web3 because it wont take you a quarter to launch something useful and you can make way more money

I know, tough idea to swallow, especially when thinking that it sounds like “just launch a web 2.0 startup with a mobile app” after knowing how few people make any money. But I think you’ll be able to look back at this and see it was an accurate suggestion.

Let me guess, someone at some point said Sarbanes-Oxley? Under that restriction, the team running the app must not have access to the app's codebase. And the team writing the app must not have access to the production configuration (and tooling for production).

There's a whole bunch of other things that go into SOX compliance and is something that one should only pursue if required.

If you are Brazilian, this is how i felt working at TOTVS, it's absolutely a living hell to get anything done, you have to spend days trying to figure out managers, convince people that have no incentive to be efficient, and just like OP i tryied to do my job on my own and was denied for compliance reasons, i just cant understand this type of behavior

The bottom line is that mergers and acquisitions destroy companies. Removing the founder and reducing the power of key executives destroys the soul of a startup. Almost every company I have seen be acquired by a larger company has died.

Founders, don't sell your companies. An exit is not the goal. Your business is our baby, what monster would sell his baby?

Hi!

I have engineer's background and very much still feel like an engineer, but for over 10 years I have been managing a team of up to 50 developers within an organization with several hundreds of staff. Let me try to explain the "whys" below. Once you see the wider picture you might look at all this with less negativity, but it's also fine if you find it unacceptable - there are valid reasons why people leave corporations to work on something in smaller scale and what you describe fits a lot of these reasons.

Larger companies focus much more on avoiding the risk of breaking something than on the speed of implementing new features. The painful process you are going through is probably a result of earlier experiences of having requirements dropped into the backlog by random people. In your relatively small startup team you did not experience it, but in large corporations just by pure chance you can get hundreds of requests from all over the place. Each of them has costs associated with it: implementation, testing, change management (in order to keep track of stuff for a chance of a team resigning en masse) and the virtual cost of the risk of breaking stuff in production. Especially in a project which seems to be widely used by other teams.

The 4 pages long form is there to make sure that you really need the stuff done - otherwise you would not waste your time to write all that.

The two managers approving the change are there to prevent stupid stuff from being worked on just because somebody sits next to the developers and has various "ideas" and "needs". They are not there to discuss your idea with you, but rather to make sure it does not go against the project's priorities, which are unknown to you.

The lack of R/W access to the repo is to keep control over what happens in the project. It's not that they don't trust you, it's that you have no idea what they need outside of your small feature. After few months they need to be able to know (more or less) why something is present in the code, regardless of you being there or not.

You are not allowed to speak to the engineers, because they will be working on your feature around the end of Q1 2020, so you'd be wasting their time now. They have a backlog of other stuff to do and won't remember your input after few months anyway.

What can you do? Notify your manager about there being a blocker for your task and find something else useful to be busy with in case your blocker will land below a hundred of other blockers from other people. Remember that your personal efficiency is not equivalent to organization's efficiency and learn to handle several tasks at the same time while waiting for blockers for most of them to be resolved. Do not mistake it with multitasking (actually working on multiple things simultaneously), it's just an efficient scheduling of available resource - yourself - in the context of an organization working in unison.

PS. For most of the my time managing developers I've been working really hard to make sure people from across the organization do not interrupt them in their work. Once you put yourself in the skin of the engineers you are not allowed to talk to you will understand that at least some of the stupid mechanisms you've encountered are there for exacly that reason. You should respect that as an engineer.

Basically, you have two options:

- learn to embrace the dysfunction while resting and vesting. Note that this is easier to do for founders (vs team members)

- avoid the urge to fix the big broken company and quit - there’s lots of interesting work out there these days

Sorry you have to go through this - I think most big companies are on some spectrum of this, but the spread is pretty significant.

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...

Do you have share that need to vest or something? If not leave with a big middle finger.

Or tell them to smarten the fuck up, and tell them your team works in Agile, or whatever your project management scheme was at the startup. They bough you for a reason, probably because you guys did something they couldn't, don't be afraid to remind them.

> What should I do?

The obvious solution: if it drives you nuts, quit.

If you don't plan to go that route, do two things you:

1) tell your direct superior (in writing)

2) whenever you get asked "why aren't you done with this migration", answer "we're blocked by $X" with a reference to their issue tracker / ticket system / whatever.

... and then work on something else.

Tell me you never ran a large code base in production, without telling me.

Past a certain point there are no "simple code changes" anymore. Automation and functional QA needs to ensure zero regressions, internal and external docs need to be considered, it all needs to be bundled in with many other code changes (feature and fixes), etc. There is no shortcut. Even FB had to dial back their "break shit in prod" mantra.

Of course startup devs hate this, real men fuck around in production, which is great. Running and maintaining a large code base is very grown up sport, more like running a country than building a house. For those on the other side, who inherit startup code and have to fold it in ... the hatred is mutual.

Is there any value in you learning how to effectively work in a place where things take weeks instead of days? If not, that's okay. Though do appreciate that as that 50 person company scales, it too will need to take a longer time to align all the moving pieces.

Moving slow isn't inherently bad, it just might not be.. your thing.

Sound about right. Another option is to see if you can get approval to stay on your current infrastructure, and maybe get your codebase and environments up to the required standards. Reduce your dependency on the large company, reduce your headaches, this will be the first of many. If the product works it works.

Is it possible that there might be a code freeze at the end of the year so that engineers that are on call don't have to work through the holidays?

Without knowing the codebase, can you accurately assess that the fix you want can truly be completed within a few days? Does that cover testing and documentation?

I worked at a startup with three employees (and six C-levels that were too busy suing former clients to sell the current product) that tried to start acting corporate at that scale. It was an atrocious experience and I'm glad I left.

Sounds like it's time to jump ship and find something new.

Enjoy working in a sclerotic bureaucracy where you will never be held accountable for failing to deliver much because some other team is blocking you, giving you plenty of free time to practice Leetcode or whatever, wait for your earnout period to elapse, and then jump to a new company.

Just leave and get a job at another startup. Some people are desk jockeys and some people are field agents

Honestly, give it a chance, learn what you can (not just the "how" but the "why"), and if it's not for you, move on. People thrive in different environments and cultures and you'll not be happy if you're continually swimming against the tide.

I worked and work with large corporations. It takes years to implement things, be patient:) I started thinking that people who work at corporations believe in reincarnation. If a feature is not implemented in this life it will for sure be implemented in their next life.

Yes, large companies work this way. I think you are person who does not want to waste your time for the sake of slow process. Staying longer will make you feel less confident of yourself. If it was me I would look for another fast paced startup or medium sized company.

Having been _exactly_ where you've been a couple different times I can assure you that things can & will get better, if you let them. It's really up to you to learn and work within the system or to begrudge it. No judgement either way, bigco's aren't for everyone.

   I'm working on migrating our apps to the parent company's VM launching and deploy platform. Should be fairly straightforward, I think. Unfortunately, the deploy tooling isn't entirely compatible with our app so I ask the team if they can implement $X feature to support our app.

> The actual fix is rarely the long pole in the tent for implementation. In the other team's mind this translates to: "Can you support a completely unfamiliar platform in your app from now until eternity?"

  The first engineer I talk to doesn't even attempt to answer my question but redirects me to their manager. Ok, that's odd, I think, but whatever.

> Engineers being hit up directly by other teams is the first thing a manager stops in bigco. It's good for their team but not necessarily outside teams or for moving fast.

  Manager says sure, just fill out this feature request doc. [...] delivery timeline of end of Q1 in 2022.

> This is about prioritization and ROI. They need to document the feature, compare against other company and team priorities, and get approval to move on it. Bigco is a cruiseliner not a speedboat. It takes a lot to turn it so it naturally wants to be sure that it's headed in the right direction before turning.

  At this point I am in absolute shock. This should take no more than a few days to implement.

  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.

> Again, the code isn't the hard part.

  I tell him I'm happy to fix the issue myself [...] and that only members of his team have R/W on that repo. What???

> CYA, get used to it. What happens WHEN your patch breaks and deletes customer data? Who takes the fall? Probably not the guy who submitted a PR one time to help the team out.

  This is insane. And this entire time I was only alllowed to interact with managers and have not spoken to a single engineer about the actual technical details. It is impossible to get anything done here now.

> Sounds like you also need to update your team structure for the realities of bigco. In bigco, there are people (scrum master, eng mgr, product owner, product managers, etc) that deal with all the things in this post and shield your eng team from having to deal with bigco's mess.

  Is this how it's like at all large companies? What should I do?

> You should adapt. Or not. It's up to you. Some people like it, some people don't. Personally, I've come to terms with it and have tried to carve out a "smallco team" within the bigco structures. It's not perfect but it helps scratch my "get things done" itch. Also keep in mind, there are benefits to bigco. Work/life balance, etc etc etc.

You could hire with leverage. I for one would be interested in working with some vested stock. Or just add me to slack. Either way I need a web app (node python next react) job or something in machine learning. The most basic foot-in-the-door role would suffice.

It sounds like you should work four hour weeks or whatever it is you must to satisfy your new employer and ride it out until your retention pay vests, using the copious free time you have to either grow your skill set or otherwise enrich your life.

Yes, 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

If you have options, I'd suggest to move to another startup that fits your style.

Sad but true: that company will only kill your startup culture in the favor of their boring enterprise corporate model, and you (rightfully) don't want that.

Quit, obviously. You like startups and this isn't one. What's the dilemma?

Time to travel the well trodden path of leaving to start your own company that beats the pants off $LARGE_CORPORATION. I am certain your customers feel exactly the same way and are seeking alternatives.

My favorite $LargeCompany move was a few years ago, when my friends highly compensated (6 figure equivalent) summer intern class didn't get IT's permission for internet access at the company, for 2 weeks.

There is always a ramp up time when joining a large co, get your requests in as soon as possible, after 6 months of project planning and logging requests with other teams that you rely on you can get a flow going.

Work on something else, and launch this change in Q2.

Instead of launching one change fast, switch to doing many changes slowly, and pipeline them so some are always waiting and others are always ready for you to do work.

oh i've done this before. the trick is to make changes in your app to suit theirs, not the other way around. it's not impossible, just hard in the meantime get acquainted with their politics

Try be nice and friendly to these peple who are giving you grief, see if you can explain the issues you're having and ask them if there is something more you can do to help expedite the process.

I don't think the issue is the task's perceived complexity; the issue is that it is simply not considered to be the most important task in their likely very long backlog of tasks.

As a graybeard who's gone through this a few times, here's my advice: start looking for another job that suits you better. This isn't as situation you can "fix."

Yes. What you should do is not quit and get two or three more jobs at large companies, perhaps even 5, if you’re a 10x’er maybe even 20.

Then use all the money you’re making to be an angel investor.

Thank you for your story. Covid has done some damage to my bottom line this year, but stories like yours just again cheer me up and prove to me why I decided to work for myself.

The thing you need to adjust to is this unfortunate truth:

At large companies, NO ONE makes decisions anymore.

It's the PROCESS that makes the decisions.

And the Process takes a lot more time than you are accustomed to.

This will not change.

> Is this how it's like at all large companies? What should I do?

The answer is easy: make bank. You are making a lot more money at a large company for much less work, right? Enjoy it!

Why not move to $ANOTHER_STARTUP? Start fresh. This happens. Larger organisations have "larger" processes. Your skills are in demand. Just take them elsewhere...

Completely normal phenomenon, I'd say. That's how big organisations survive. "I quickly do it myself" spawns chaos down the road or outright desaster.

That's the way it is, policies get put in place to protect the organization and tech stack as a whole. Documentation and separation of concerns is the norm.

Not feeling great after an acquisition isn't uncommon! These articles might help

Examples of things going wrong after acquisition: https://sifted.eu/articles/gopuff-dija-acquisition-dilemma/

What staff actually need during mergers and acquisitions: https://sifted.eu/articles/employees-mergers-acquisitions/

Welcome to big company fun! Also your "small task" is probably very low priority. Get used to being the least important people for awhile.

Just work on some cool open source project and enjoy the lack of startup pace for a bit. These situations tend not to last long in my experience.

That sucks.

What's your equity like? Is it worth >100k? Is it >1m?

Unless you have significant equity in your work there's no reason to care so much. It's work.

"Is this how it's like at all large companies?"

Maybe your example is a little more extreme than my experience, but yeah, pretty much how it works.

You're assuming that they really wanted your startup and not just removing a competitor. They may just be waiting for you to leave.

Kick back, enjoy the ride and always have a list of reasons that are not tied directly to you for why your assigned project is delayed.

> Recently we were acquired by $LARGE_CORPORATION

You didn't mention retention bonuses, so: start looking for another job. Your old job is gone.

The middle managers need to manage their serfdoms and prove their value. It seems like the less value someone actually adds, the more territorial they are-- typically blaming arbitrary "established processes" or something of the same nature. For non-tech companies it seems like burecracy starts to become an issue at like $500mm/yr. Any academia or government org will be the same. You can't really fight the system and win, so it is easiest to just find another job.

I mean, I've done this dance.

Unless you have some handcuff$ in play here, it's time to go. You will not be happy with the New Normal.

Perhaps you are not their highest priority.

I’m amazed that this startup had 50 people given the clear lack of apparent structure anywhere on the product team

Just leave, everybody’s hiring right now.

No, this is not how large companies work. That's how over-regulated companies work, no matter the size.

Leave

Do not do things that you hate, they will break you and diminish your passion for your work.

Better use your creative energy elsewhere.

>Is this how it's like at all large companies?

Not good ones or at least good team's within big companies.

You should change your app to match their infra instead of changing their infra. Why can’t you?

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

Work on side projects or get a second dev gig while you wait for upstream to do things.

> I'm working on migrating our apps to the parent company's VM launching and deploy platform. Should be fairly straightforward, I think. Unfortunately, the deploy tooling isn't entirely compatible with our app so I ask the team if they can implement $X feature to support our app.

It's probably easier and quicker to change the app to work with their platform. If nothing else, it's going to be much easier to staff the project; your team knows the app.

> The first engineer I talk to doesn't even attempt to answer my question but redirects me to their manager. Ok, that's odd, I think, but whatever.

That's not an unusual response (https://devblogs.microsoft.com/oldnewthing/20070522-00/?p=26...).

> Manager says sure, just fill out this feature request doc. It's a Google Docs template with 4 (!) pages of required documentation to just explain why I want this feature implemented. It asks for my team name, the motivation, why I can't solve the problem some other way, yada yada...ok, I guess it's good to document your work, so sure. I fill it out and submit it.

This strongly suggests that ad hoc feature requests are or have been an issue for the team. It's also a good way to weed out requests that the requester isn't serious about or has an available alternative.

> No response after two days. Then I get an automated email that their skip level manager has approved the work. Huh? This is followed by an email that the team's eng manager approved the work. Why do two layers of management need to approve work on something they have no knowledge about?

These managers are running interference for their team so they can get work done.

> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does not work for our app), they quote us a delivery timeline of end of Q1 in 2022.

Most development teams have a backlog; I'd be concerned about the work quality of one that didn't.

> At this point I am in absolute shock. This should take no more than a few days to implement.

The change might take a few days but the team already has a backlog of WIP (work in progress) (http://www.leanmanufacture.net/leanterms/wip.aspx). The time to completion is based on the other tasks in the queue. If the migration needs to happen sooner then that's between your manager and the manager of the other team.

> 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.

Every task is simple when you aren't the one doing it.

This was a bad move tactically; calling him out is not going to get you the results you want.

> I tell him I'm happy to fix the issue myself, if they link me to the relevant codebase. "It shouldn't be too hard to dig in and submit a patch," I think to myself. He says he cannot give me access to the codebase for compliance reasons, and that only members of his team have R/W on that repo. What???

Maybe they don't want to support bespoke features for your app. You can check in the code and be done but they're stuck supporting the change forever.

I'm in a similar boat. I feel your pain.

I was an engineer and very early employee at a startup. I helped grow it from four clients to many millions in revenue and a successful exit. I nurtured a team of amazing engineers. I felt like I needed to stick around to see the product off to a good start and my team thriving at their new home. I was also excited because I hadn't worked at a large company since I was just out of college and I was interested in the unknown challenges that awaited.

Our parent company isn't quite as bureaucratic as yours sounds, but it's more bureaucratic than our original company, for sure. But they said all of the right things. More resources. More opportunities for personal and team growth. But things wouldn't change and we'd be left alone to continue our success but with more fuel and maybe a slight shift to integrating more smoothly with the rest of the company's products.

I also found myself in a leadership position, so I thought I could change what few small things I noticed as a bit inefficient in the the culture to be a bit more responsive.

Long story short: I'm looking for another growth stage startup to join. I probably should have done so right away.

First warning -- the new company was obsessed with what title I should have. The startup didn't put much weight in titles. We did what needed to be done. My official title was Director of Engineering -- mostly to make clients happy when I talked to them, but they definitely could not have that...that tier was full. I ended up a Solutions Architect and Technical Manager. Ok, cool. Similar responsibilities and team.

Second warning -- lots of leadership changes at the home office. We've had three CEOs since we've been acquired. We're just the right size to be a stepping stone for ambitious leaders. It's kind of amazing that we have CEOs step into a very complex organization selling very complex solutions and they expect to learn enough to make an impact in a month. Then they start to pursue their agenda with verve! So...they inherit the broad brushstrokes of the previous administration, add a few of their own, and the organization is off on a new adventure. Unfortunately, it's a recipe for a lot of stuff to be ignored. The previous agendas that might have been the first step in a fine program of ideas that would lead to wonderful things becomes The Agenda. Predictably, the first step isn't enough to see a whole lot of fruit so...yeah.

Third warning -- we weren't allowed to even talk about creating new products. We're an acquisition company, now. We buy winners. We don't risk creating losers. Not so fun for someone who Really Loves Creating New Things.

So...here I am envying your early clarity. Large companies are just different. I am starting to believe innovation at scale is rare, if it exists at all. If I were you, or me two years ago, I'd start looking for a better fit.

Let the MBAs run these companies through the motions of the terminal stages of the business lifecycle. I'm ready to get back to bringing new things to life. It sounds like you are, too.

have you ever considered working on other startups on the side, while $LARGE_CORPORATION decides when you should start doing actual work?

Get out. There’s zero chance things will improve in foreseeable future.

Big companies love unfinished projects. As long as the money’s flowing, there’s not much motivation to actually finish and risk a change.

This is your moment of clarity: start interviewing.

This is why I don't work for large companies

Yes. Quit. Join a startup (we're hiring).

"The Trial" by Kafka.

Corporate BS is quite enough to turn one into a cynic within a year. Its the daily lying and gaslighting I think.

I have an allergy to the environment.

Quit, get a job at a startup again.

Sounds like Wells Fargo :grin:

Yep. Either suck it or leave

Vest and walk. Congrats

Welcome to Google!

This is normal.

r/antiwork

Leave.

Welcome to megacorp hell.

Is this how it's like at all large companies?

Yup, for a large portion of them.

What should I do?

Quit.

And pat yourself on the back for finally getting a chance to learn, up-close and first-hand, what this industry is actually like.

> Is this how it's like at all large companies?

Pretty much, yes. There are lots of reasons why all that crap that happened to you was necessary, and it's directly a factor of it being a big-ass company. Large systems are inefficient and complex.

> What should I do?

What do you want to do?

Large companies may kill your soul and make you lose all interest in your career, because you are reduced to an ungreased cog in an extremely rickety, rusted, pointless wheel. If you would rather ship cool new stuff quickly, you should quit and go find more engaging work.

But if you have a family and just need to pay the bills, there are much worse things than decades of steady employment. You can also often move laterally throughout the company, play with new technology, or be exposed to new products/services, without having to have actually gotten any real work done. Some people even get side gigs and double up their income. Working in large companies can also teach you more "professional" ways to do work. Working within large orgs is a skill in itself - the problems you describe can often be trivially worked around by building relationships outside your team. Most "restrictions" imposed by "managers" are actually just bullshit politics that you can route around if you learn the reasons for it all.

By the way: if you leave, try to tweak your benefits so that they pay out all the 401K or HSA money at the beginning of the year (front-loading). When you quit you won't have to have waited all year to contribute tax-deferred benefits to your retirement accounts.

Try to play the game, maximise material benefit and spend enough time there to get another nice line in your resume, if indeed the name of this company carry some credibility. If you also got a lot of free time bring your own laptop or connect out to some virtual machine and work on your own idea or projects, nobody is going to care as long as you do your job. Then at some stage switch company or start your own, it is a blessing in disguise, your anxiety derives from too much ego, you felt important before and now you are not, don't let it blind you from the benefit you can derive from this situation.

Nice real-life example to demonstrate those who blindly conclude that "government is inefficient and private companies are efficient" without the full context are generally wrong.

Did you fill out the TPS reports?

>a living hell for all of us

Put all these grievances to paper, have every worker sign it, and submit it to every member of the board of directors.

Sounds like the author's startup used to develop a real product and was then being acquired by an enterprise shop merely needing the original product to fulfill a business need. Welcome to cost center IT!

You should send this write up directly to the CEO.

You can either quit because working a big company can suck, or you can get moved up the chain of command if you are the type of person who actually cares about this problem and wants to fix it.

Yep, you are screwed and fighting assimilation is futile. I'm currently at startup that was acquired by a fortune 50 and they are actually allowing us to stay separate and they aren't mucking about with us. All of my previous jobs where I stayed on after the acquisition (3) were all soul crushing. Abandon ship.

Personal advice: setup a workers coop with some people you trust you can work with. Equal pay for everyone, flexible schedule. And you get to choose who to work for as a client.

If you people have some crazy ideas worth researching, a coop is the perfect setup. You can find some contract to pay the bills then liberate time to work as a team on something free-software that actually matters to you.

You may even end up with leftover money to donate to other amazing projects you'd like to support.

When the Dilbert comics become all too real. While you may find it difficult to get things done, the bureaucracy will leave you with a lot of time on your hands. With that time, either:

1. Pour the energy you would have put into work into side projects, starting your own company, etc. Good route to take if you are vesting.

2. Interview at other companies where you can actually make an impact. Luckily the job market is insanely hot right now, so your comp package should be bumped accordingly.