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

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

454 pointslopkeny12ko444 comments

I work at a startup with ~50 employees (and have always worked at startups). Love the work and the people. Recently we were acquired by $LARGE_CORPORATION and the experience has been a living hell for all of us. Things that should take a few days take a few weeks. Things that should take a few weeks take a few quarters. It's slowly driving me insane.

The experience is best shared as a story.

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

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.

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?

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.

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.

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

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.

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

View on HN

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

That sounds about right.

I'd also note to the OP that in might help to treat the acquiring company like the Borg: they acquired you, and now it's on you to serve their needs, not necessarily the other way around. If your app isn't quite compatible with their infrastructure, the right move is probably to modify your app, not ask them to modify their infrastructure. That might be annoying, but it's probably also the reality of your situation for the the time being.

And with acquisition you are likely a very small fish in a big pond, whatever used to be high priority in a company of 50 is probably more of a mild annoyance at a company of 5-10k people.

> If your app isn't quite compatible with their infrastructure, the right move is probably to modify your app, not ask them to modify their infrastructure.

This is my thought as well. The claim is that the fix on the infrastructure side should be a few days at most, but also that the infrastructure does not work for the app. If it’s only a few days for an infrastructure change, why is it so untenable to modify the app?

As an engineer (and manager) who owns infrastructure components, these “little” requests are death by a thousand cuts. They typically aren’t actually little, but even when they are, they forever add additional maintenance cost and complexity.

I’ve seen one deployment infrastructure/hardware management team take all of these little requests to make their customers happy and the end result was an entire team who basically did nothing except service requests from one final customer. They made the system fully customized for the one use case. I’ve seen another deployment infrastructure/hardware management team essentially refuse and tell their customers to fit into the supported model or find another solution. They provided a few standard hooks and said figure it out.

The former team died when their last customer moved to the later solution because it was actually supportable.

> If it’s only a few days for an infrastructure change, why is it so untenable to modify the app?

It could be an incompatibility with a core requirement e.g. application used webrtc or websocket, bundling / deployment system can’t handle them (will reject / close on upgrade requests or long connections), you’d have to rearch the entire product, probably detrimentally to the system / experience.

Certainly something like that is possible, but I don’t think so given the way OP wrote about it. Especially lines this this: “the deploy tooling isn't entirely compatible”.

That doesn’t sound like a critical missing feature (which would somehow be cheap to add). It sounds like a fairly minor roadblock that he expected the other team to solve for him. My guess is that it’s one of those things that might take the other team a week and would take OP 2-3 weeks, so in a little start-up, the other team would obviously do it because it’s more efficient. But in a big corp, asking the other team to make the change is kind of like asking AWS to make the change. (Which could be the case if Amazon is the big corp in this story.)

> As an engineer (and manager) who owns infrastructure components, these “little” requests are death by a thousand cuts. They typically aren’t actually little, but even when they are, they forever add additional maintenance cost and complexity.

As a former SRE and tech lead for some OPS teams, I agree.

Sometimes they are actually little but will create divergent states for your code/infrastructure, increasing complexity and cognitive load on the team maintaining infra, slowly but surely.

In my experience with infrastructure on larger organisations it will require, at some point, to standardise practices and processes, and it will be painful for teams that don't fit squarely with the standard. You always aim to embrace 80-90% of the components in the organisation (or at least 80-90% of the most profitable/important ones) and take the hit that 20% will require modifications, as extensive and costly as they might be.

It's always a juggling act, engineers with the mindset of building whatever/however they want will feel less empowered when their favourite set of tools, tools that they might be using for a while, isn't supported by the standard. Some teams will take a lot of the load to adapt to whatever was agreed as a standard, churn will inevitably happen in those teams so it requires a long time deliberating what is acceptable or not. The job is always to strive making everyone as equally unhappy as possible because it's impossible to please everyone.

Those little requests might also have impacts and implications much larger than what the requester thinks about, when your infrastructure system is supporting 200+ teams any change is bound to cause ripple effects so you have to be deliberate.

Exactly this. It's not too hard to think about the intake of random requests a popular team may receive. Even code reviewing a patch from a separate team carries its own set of eyes, which is still work for the team. There's a ton of context OP is probably not familiar with and walking them through all of that baggage is not worth the effort. While this may seem annoying from an outside team's perspective, it's the only way to really focus on their roadmap and be able to commit to scheduled work.

It's pretty interesting to contrast OP's experience with this recent /r/bestof that describes in detail why things might be the way you're describing:

https://www.reddit.com/r/bestof/comments/rkru22/uloosesignif...

I immediately thought of this as well. Great minds etc.

Direct link

https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...

for everyone else having a hard time figuring out how to find the actual comment.

Really worth a read and absolutely puts OPs story into perspective.

Yeah that story is total bullshit. It's someone's fantasy. The equivalent of me telling the story of my epic comeback in the Superbowl.

I can buy the part about putting up fences between business people at the tech team. Been there, done that, modernized project management. But the "thank you"s, bonuses and all that? Complete fantasy. :)

I 100% guarantee it's someone who has recently read "The Phoenix Project" and made it up based on that.

He even referenced the Phoenix Project ;)

Now you understand modern book marketing. :-)

Wait...are you suggesting that whole comment is actually just an ad?

While I have no evidence in this particular case, if I wanted to promote a book, I could imagine making up a related, positive story, which just happens to mention the book positively, and posting it on a popular social media site (I put the book in my cart). Then one could follow up with a softball opposing story on another site to get some controversy and thus visibility.

Probably someone will cross link for you (I thought about doing that when I saw the headline). If not, a sock puppet can point out the link, and the book, again.

TBH these two stories have the exaggerated perfection that characterizes fake stories. And the fact that they arrived so close together makes me very suspicious.

I mean I read it and thought about looking up the book and getting it

I did like the book, back when I was completely new to DevOps. It's also a fictional story in the same vein as the one on reddit basically same template, but more mystic. Explaining DevOps through a story.

Now I'd suggest to just read the state of Devops reports by Google, they are excellent.

This is not an ad and I doubt it is fake. Click on the user profile and read some of his other comments. This guy is real.

Completely agree. I knew they'd link to the Phoenix Project at the end

If so, I’m even more impressed.

When I first encountered the Phoenix Project, I was expecting it to be some kind of satire. It wasn't, it was played straight all the way through and ends with "a win".

It blows my mind that someone could write a novel about work and NOT have it be a satire or dark comedy. This book is used in project management courses, by the way.

Why? Maybe it’s that you’ve never worked for a boss that fought that hard for your free time?

Great bosses like this exist

The manager maybe, but you don't change the culture of the company like that. A low level manager has very little influence on that, they'd be replaced the moment other VPs started complaining.

Depends on the on the exact political arrangements. I’ve seen a “low” level manager get the ear of a senior leader and get protection/empowerment that ended them to do something on par with this. It sounds like the author got the appropriate buy in, and I suspect that not all ad hoc work got prioritized in a FILO manner.

It sounded implausible to me. Admittedly I don’t work for a large corporation but this sounded like a socially challenged persons dream of how they’d convince large groups of opposing people to their side. Hostile interactions with shelter from an all powerful HR and the vague threat of a lawsuit.

I've explicitly asked for strong barriers from external leads and developers from my manager before and gotten them. My current boss aggressively puts barriers in place to keep us from being bothered or distracted.

Why? I do this stuff all the time as a manager. It really goes exactly that way. Notice that the reddit commenter started with getting buy-in from the higher-up in their org. He didn't unilaterally start changing process.

This is honestly basic management technique. It is called the "Auntie/Uncle" problem.

I’m having a bit of trouble what “Auntie/Uncle problem” is in reference to. My Google search are just a bit too generic to narrow in. Any chance you know of an article on the subject I can read through?

You might consider providing a link, since Google returns absolutely nothing about management relating to “Auntie / Uncle” as a search term.

I could see it happening where I work (Large Multinational in the Energy Industry). HR are removed enough that they would back this up, yet have the authority. Teams often report by function, therefore there isn't a local manager worried about the missed deadline. Combined with the companies image as attempting to be a leader in social responsibility (at least as much as an Oil and Gas company can). I can see it happen however I don't think I could see it in any of the smaller companies I have worked for as the results of missing deadline were frequently too significant.

That being said my current employer is exactly like the one mentioned by OP here. You basically need to build credibility internally to deliver.

Reddit is 90% LARPing when it comes to situations like this - it's obvious once you see it, and once you see it you can't unsee it ever again. It's like getting vaccinated against a sickness.

It's pretty hard to imagine HR intervening in business operations to protect a single department's work-life balance - couldn't really track it from there.

odd that most in this thread think this story is fiction, some even suggest it might be a marketing ploy to peddle a book. Is really the whole world like this or is there a difference depending on jurisdiction (e.g. comments reflect values of US?).

While I can't prove a negative, this story is highly plausible in Europe where legal/HR will be on your ass and even fire the CEO if it turns out they had knowledge.

In 2020 I was in a similar situation with an IoT "startup" (70 people) in Austria where some of the original founding team worked their employees in a brutal manner (made fun of the engineering providers that invented the product in a "low-cost" neighboring country, and being total f-heads all around).

My superior even made fun of one intern for "stuttering" in front of the whole team, scolding him for "sloppy thinking" and being "too slow in his head" (fact was he wasn't used to speaking English, was a bit insecure because he was still very young). People regularly cried.

That was just the internal stuff. In my first weekend in this firm I was given new tasks on Friday 16:00 to finish until Monday 08:00 (tasks so complex that it would normally take a whole week to finish and required multiple rounds of input). I had no free weekend in my first month and 12/hrs per day was the norm. In my first client meeting 2 days into the job I learned that my company lost all their data 3 months before ... genuinely curious I started probing the client to get a better picture of how we were perceived. The client talked himself into such a rage that he ended up screaming at me (and a day later apologizing for doing so).

2 weeks after I joined, I wrote a long letter to HR with a list of all the communication that happened, e.g. who said what to me when, and even smtp headers of communication received in an appendix. After the CEO asked me to lie on a revenue forecast that served as input to the business plan (and where I was told "to make up numbers" !!) I looped in the Holding company into my ongoing conversation with HR (the holding was where my employer got all their funding and who would be the audience for that pitch in the presentation/Excel I was asked to make).

It was the first time that I ended up (literally) screaming with my own superior in a meeting for abusing his own team, and spelling out immediately why his behavior was abuse. 2/3 of my team left that very month since they were fed up and I like to think it was me that spelled out for everyone what they already knew but hadn't ever thought to verbalize themselves.

I also handed in my resignation a week afterwards since it looked like some people would be able to get away with it. The Holding Company brought in an external consulting / auditing team and fired the CEO and 2 others. Alas ... not for mistreating or overworking employees but for lying on the business plan. This October (2 quarters later) the same company filed for bankruptcy.

I don't know if I would be able to bring down an equally rotten place in a different jurisdiction. YMMV sadly and I am sure many people try in other places but all they ever achieve is that those responsible get a "stern warning". But I totally believe the linked article to be plausible

EDIT: rediability

> Alas ... not for mistreating or overworking employees but for lying on the business plan.

Business plan can be easily marked a “mistake out of sloppiness” if you don’t want to fire people.

Abuse is bad for the image and evidence collection takes ages (and hence is expensive).

Lying to the board works much better to get rid of people fast. I would bet you weren’t the first startup to do a bisserl of Zahlen frisieren.

The disbelief and learned helplessness in this thread is a really disheartening view into the state of modern american work

Reddit in particular is infected by this kind of toxic thinking. One on the one had, I think individuals hate being fooled, and so there’s a rush to decry any remarkable or interesting anecdotes as “bullshit”. In this case in particular, I suspect the disbelievers are stuck in soul-sucking jobs they hate, and one way they cope with that is by truly believing that everyone else in the world is in a similar situation.

Its such a strange, depressing way to approach content imo. Did the story happen? Maybe, maybe not, we can’t know for sure. Do I want to believe it happened? Yes. Are there valuable aspects in the story that I can learn from and potentially use in future? Yes, absolutely. Is there any harm in me choosing to believe his anecdote is real and it’s actually made up? No, I don’t think so.

There’s actually a whole subreddit on this topic https://reddit.com/r/nothingeverhappens

Also, don’t get me wrong — there is plenty of fake content, or implausible content, that is worthy of skepticism because it has a nefarious agenda, fosters misinformation, etc. But sometimes people just need to chill out.

An argument that it's plausible that almost all remarkable or interesting anecdotes that you read on Reddit are fake: https://slatestarcodex.com/2016/12/12/might-people-on-the-in...

I'm not sure if I believe this, and I certainly don't think it has much to do with the existence of r/thathappened (which does indeed seem much more rooted in people's fear of having been a sucker). But it's interesting to think that the basic intuition of "true stories are more common than fake ones" might be misleading with respect to Reddit in particular, because of the specifics of how Reddit works.

(The point about it being harmless is unpersuasive to me; I want to believe that a given story is true if and only if it is actually true.)

Wow, thats a truly excellent comment. Everyone who manages people should read that IMO.

If only it had any basis in reality.

>Learn how the system works, and learn how to be effective within that system.

And what if the system is corrupt? Do you advocate complacency?

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

And what if the people who do not succeed with such bureaucracy are actually better off for not being compliant? What is your measure of success? $?

Literally the point of a job at a for-profit company is to make money, yes, primarily for yourself and secondarily for the business. This is by no means moral or virtuous. But it is true, and because it is true, the people who admit the truth of it will be more successful in the sense that they will be working with the system, and the people who act as if it is somehow untrue and there is some greater virtue behind it will be frustrated in the sense that they will never be able to work against the system enough to unseat it.

Why did the startup get acquired by the large company in the first place? To make money for the shareholders (mostly the founders), partly through an exit event, partly through the ongoing value of their shares. Sure, they wrote an internal email and a blog post about the "next stage of their journey" and how the big company "shares their vision" or whatever, but that's not the real reason - the reason is money. Why do employees get equity? To incentivize them to care about the money the company makes, because otherwise they wouldn't care sufficiently about the secondary goal of making money for the company (i.e., making more money for management, who sets the equity policies). Why do employers compete on salary in the first place? Because that's what being employed is about - making money.

If you want to do good work, to change the world for the better, to have fun, or whatever, you have two options. One is to secure your place within the system of being successful by making money - i.e., to show management that you will make them money if they keep you around and keep you happy - and then find some room to maneuver within it. There are a lot of people who are happy and fulfilled with their jobs because they can do this. The other is to leave the system (retire, work part-time, join a convent, etc.).

But refusing to admit the rules of the game will work about as well as trying to play a game of chess by bowling a ball at the pieces and knocking them down. You might say you don't care to win, which is fine, but that's hardly the problem - everyone involved, including you, will end up upset.

It's both funny and sad you've got to remind that to people who post on HN of all places...

The end of a for-profit company, I will agree, is to profit, but what end is that for humanity? You imply that moral corruption toward profitable ends is of no difference to those where righteousness in action creates profitability to the owners of the business firm, e.g. honest income. What if the managers you advise working for are evil? You seem to affirm that it is not your problem so long as you are succeeding at making money. That there is no difference in profiting at a usurious bank than a charitable one, indeed to participate in the usury because it temporally rewards more, when in fact there naturally is.

I think you missed the part where I said this was not moral or virtuous. Don't go looking for virtue. You won't find it.

If the managers you advise are working towards evil (say, they're having you find zero-days to deploy against human rights advocates in the service of murderous autocrats), by all means, stop working for them! But that's very different from the managers not being able to process your feature request until Q2 and asking you to fill out a Google Doc. This is not evil, nor will it benefit humanity to send in some patches to the other team's code and get it shipped tomorrow. Don't go looking for virtue there, either.

To reiterate my point - I'm not saying it's good that the things I'm claiming are true. But I'm saying they are true, and you'd better start by acknowledging the world as it actually is if you want to effectively improve the world as opposed to just ineffectively keeping your conscience clear. Expecting to find virtue at a for-profit business that isn't deliberately opting out of the system (and a startup that decided to be acquired is deliberately opting in) is misjudging reality. But in the same way, so is expecting to create virtue by making your employer a little more efficient at migrating VMs.

>I think you missed the part where I said this was not moral or virtuous. Don't go looking for virtue. You won't find it.

That's like, your opinion, man. There are plenty of businesses that run with integrity as a necessary motivation to sustain their future profitability. This ends up causing a more virtuous society where people do not need to tolerate evil in order to survive.

I don't buy into your argument for "effectively improving the world", i.e. one can keep a clear conscience and do extraordinarily well in life, metabolically speaking. And that's the point: the goal in life is not measured by temporal goods. But that's like my opinion, man.

What do you mean with "securing your place within the system of being successful"? Just keeping your job? Or are you talking about abandoning other goals than monetary success? I'd say that getting a win/win is more than a achievable within the "system". I.e. I get to do something I enjoy doing, while also getting payed for it. The company gets the output of my labor for a reasonable price. Everyone wins and no one is sacrificing anything.

I just mean keeping your job, but to the post above, I mean realizing that because there is no inherent virtue in a for-profit job, there is also no "corruption" simply because there's too much bureaucracy. The bureaucracy is typically in service to a functioning large organization being able to remain large and reliably make money; it's fine.

If you want to do some good in the world, it's a lot better to put up with the bureaucracy and instead direct your energy to some worthy local political cause or something. Trying to make your employer a force for good is a poor plan, because as an organization whose goal is profit, it will never be sustainably motivated by the desire to do good.

Or quit and find a workplace with a level of bureaucracy that you are comfortable with. Surely that's an option as well?

Of course you should try to adapt to a new workplace and its processes. I can't understand how you'd have a different opinion. Coming in as an outsider and trying to lead some sort of office revolution is sure to backfire.

The OP's situation is unfortunate because they didn't choose this workplace themselves (as their startup was bought), but "not being compliant" seems like a poor solution to the problem. Quitting seems more reasonable.

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

This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I've been in the same situation multiple times. Sometimes I've been allowed to do the work and sometimes not. In the cases where I was allowed to do the work, I certainly took longer than they would have taken, but the work was complete much earlier (months) than they would have done it, the quality was just as high, and the other group didn't really have to put effort into it. It was actually a win-win for everyone and resulted in products actually shipping on time. On the other hand, the organizations that didn't allow this were all basically operational disasters. This sort of thing was just one red flag of many.

I'd recommend /u/lopkeny12ko to either stop caring and just put in minimal effort or find somewhere new to work. It doesn't sound to me like they're taking advantage of your skills.

Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.

I was going to say the same thing here. It amazes me that the company I always assumed was massive, slow, and bloated actually moves at the speed of light compared to op's acquiring company.

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko.

I believe the manager explains it right after that. They have compliance reasons that not just anyone can access this codebase. It's also possible that the manager has acquiesced to types of requests before and it was a mess — new engineer doesn't understand they system, requirements of its scale (note that this is a new engineer from a startup so the world that they are familiar with is not this one), and either 1) needs hand-holding 2) has code that doesn't meet their standards and requires extensive code review back-and-forth.

There are many reasons why, "let me into your codebase" isn't a priority for the team you're talking to. Many legitimate, reasonable reasons.

> It doesn't sound to me like they're taking advantage of your skills.

Working as part of a large organization _is_ a skill. One that the OP doesn't seem to have. Which is understandable; they themselves said that they have always worked at startups. You can't walk into an entirely different context with challenges you're not familiar with, then expect to behave the same way and get the results you're used to.

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

If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use.

Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.

(Said having worked at both companies with global read visibility & access scoped to team only)

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

Companies can have whatever compliance terms they like, whether they map to ISO27001 controls or not.

> Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.

Or they believe it's a reasonable control. Let's imagine this is a company working on self driving cars. Your source code is probably something you want to protect very carefully.

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

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

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

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

My closest experience was working with SDK of CCTV system. Which, after six months of waiting for legal, ended up being the ugliest and most obtuse codebase I've ever seen.

Thankfully, it was an optional side project at work, so I was able to step away and make more progress elsewhere.

But it also substantially reinforced my opinion that... if you need to keep a codebase secret... it's probably not a good thing.

And yes, I realize it is sadly endemic in the embedded world, for reasons both good (firmware secrets) and bad (artificial moats and controlling integration and compatibility).

The real reason is that the manager doesn't care at all, and it takes a lot less effort to say no than yes.

Or having worked on a platform team - you still need resources to at the very least review the change.

And it is on you and not these folks if something breaks in production.

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko.

I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I introduce a bug? What if the feature is popular enough that they now have to add additional functionality onto it?

Plus the ability to jump into another repo with zero assistance to implement a change is not common. Aside from the technical skills needed, other stuff like filling out change control forms or making sure the build passes CI isn't something you can do with repo access alone. To go down all those possible roads with anyone who asks can turn into a full time job when you multiply it in a large org.

Then after supporting those requests and cleaning up after those people, you job becomes lumpy and irregular with tons of people owning your time. Getting out of a role like that either takes years or quitting.

Setting up teams for inner source work can be done and tends to earn itself back, but most teams aren’t set up for this. Typical solutions for the issues you mention: trusted committers to review and merge work without having that role burden the whole team, contribution guidelines to set standards, 30 day warranty to avoid getting code dumped in their lap that’s broken but also avoid having too many owners of parts of the codebase.

Anyway, I would recommend going to the inner source commons website and reading a few of the success stories like paypal’s.

Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)

The full explanation is on the inner source patterns website: https://patterns.innersourcecommons.org/p/30-day-warranty

Heaven forbid someone introduce a popular feature into an internal tool. I do know the concern here, but it seems to miss the forest for the leaves on the trees.

At scale, if you let everyone do this, suddenly you're maintaining 50 features that were contributed and are each used by...two teams. Ownership with contributions requires really strong culture. (this is the same reason that you don't always see a PR just approved to an open source library.)

You mean just like when someone thought it was a cool feature to have JNDI lookups in Log4J ?

Are you going to assume ownership of that change if it breaks in production at any point and the team needs to provide support? Because I surely don't like owning pieces of critical code that wasn't implemented/explicitly maintained by my team, doing code archeology while putting out fires caused by 3rd parties' code is in the not-so-much-fun category of work.

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko.

Probably because $BIG_CORP was also a nimble startup ages ago, and people had written important APIs as fast as possible because they had to, and they were successful, and the company grew, and three years later the core team realized they're supporting three different sets of APIs which all overlap but do things slightly differently, and because 70% of the company revenue depended on it, it took five more years and the souls of a few dozen developers to finally get it cleaned up.

Understandably they don't want to open their codebase to someone thinking "It's just one feature that takes a few days to add! What's the issue?" - they're probably thinking "Will this make sense five years from now? What if $ACRUIRED_PROJECT gets deprecated later? Honestly I bet this project won't last two years..."

...or maybe they are just power-tripping lazy-asses. That also happens.

Author mentioned compliance. He likely is an untrained engineer in the eyes of the organization owning the codebase. Working in a medical company I recognize this. You can get write access after you followed all necessary trainings. Part of those are for regulatory reasons, part of those are added by the company to make sure new people don't make a holy mess of a (central) platform codebase. Most of time people coming from outside the platform group can't oversee the impact of their changes. They think of implementing the feature but don't know the history of the codebase, forget to add tests (or add at the wrong place in test pyramid, do not check execution times, etc), requirements, design reviews, FMEA, SW BOM updates in case 3rd party is used, fix quality tool reorted issues, link tests to the requirements, update design documents and portals, communicate breaking changes, if any, etc.

That is assuming the extension is actually desired. If everybody would start adding their little extension to a central platform before too long your platform is gone and instead you end up with a mono-archive that has no clear owner, a variation for every business unit, and so many possible configurations it can no longer be maintained.

Probably it is not that contributions aren't welcome but the author must be trained, given access and the team owning the code must be made available to support. After design discussions the author should implement end2end but likely is not allowed to modify requirements and access some of the other tools to make the updates. So owning team must be made available to do that work. The owning team is likely not paid to smoke cigars with their feet up so Q1 2022 is their proposal. I've seen worse.

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko

It sounds like OP is moving a bunch of the startup's systems onto bigcorp's infrastructure. Usually you can't "just do" stuff like that in a public company since there are laws and regulations surrounding access control, change management, data security, etc. For example PCI, SOC2, SOX, GDPR, ...

It's usually not the case that the bigcorp people just want to prevent the fast-moving Startup Superstar! from moving quickly. Bigcorp operates in an entirely different context from startup, and needs to protect itself from employees with incomplete information making reckless decisions.

I agree that OP should find a job that's better suited to their preferred style of working.

If the other team lets you do the work, who's going to review it, explain the codebase to you and, by FAR the most important thing: who's going to maintain it when it breaks? Are you commiting your team and your time to a response when a bug appears with your code or when it needs to be migrated?

That's pretty much the same issue as FOSS maintainers have with random drive-by patches - someone needs to still maintain that stuff in the future and in 99% the original owner fscks off by that time leaving the original team to deal with their artsy hacky creation.

The amount of people on HN nowadays that are okay with getting nothing useful done is striking. Startup guy, you don't have to accept being part of a bloated hierarchy that rewards politics more than good decision-making. You could check out at the corpo job and start prototyping your own startup ideas. Or join another early stage startup where your performance matters. I'll be starting one soon - let's keep in touch.

if your startup ever makes it to any sort of scale, it will likely have the same problems -- they all do :)

and you're lucky if you can actually tell what the real problems are, because mostly I find people are chasing symptoms these days.

exactly this. once you have paying customers you don't want them to grow to hate you and look for an alternative.

So don't break stuff. If you are google or aws then fine do what you want. There will always be another customer along soon.

but YOU are not google or aws.

Yeah, I'm at a startup that's rapidly growing, and is adding more process. I don't feel like it's overmanaged, I don't generally need to pull in my manager or skip. But I can imagine giving a similar response, the major difference is that the team I'm on doesn't really have official processes set up.

The main problem is that the team has a lot of work to do. So simple tasks might take awhile if they aren't high priority. If I got significant push back, I'd talk to my manager or skip. Because doing it sooner would mean pushing back other high priority requests.

And when it reaches that stage, the OP can nope out to another up and coming startup. There's no reason someone needs to stay at a company through its whole lifecycle.

true, I've done similar in my career. IME your growth potential and earnings potential can peter out when you do this though. YMMV

SpaceX seems to do just fine?

do you work there? would be interesting to hear how you believe it's different and why. if not, then I think "just fine" is probably conjecture, and I'd imagine they have the same problems as everyone else at scale.

SpaceX clearly has no problems innovating and moving forward fast. Something you don’t see in more bureaucratic organisations. I saw an interview with astronauts who has worked for both NASA and SpaceX and they said that the big difference was that what would take a year for NASA took a day for SpaceX.

Sorry to say, but there are plenty of companies with absolutely atrocious internal cultures that still manage to innovate and move forward fast, I've had the misfortune of working for a few LOL

I can believe that. What does that have to do with working for a bureaucratic organisation? NASA innovates. It just takes forever compared with non-bureaucratic organisations.

Yeah. All the explanations are a waste of words if OP isn't happy with the process. The process isn't going to improve. If it's not to your taste, bail as soon as your deal is complete (might be already).

Personally, I think we all win if the people who want to move fast are in situations where they can move fast.

As someone who just transitioned from a small startup to a much larger organization I feel the pain of the OP, and I hate it, but I get the feeling that this is typical and maybe unavoidable as organizations scale. Is that not your experience? Seems like you either have scale or efficiency.

It's just different priorities.

Startups are busy trying to build a functional house of cards.

Established businesses are trying to keep employees from knocking over that functional house of cards.

> Established businesses are trying to keep employees from knocking over that functional house of cards.

And usually also spend the next 10 years cleaning up the total mess of a house of cards from the startup phase into a more manageable and stable house of cards.

> The amount of people on HN nowadays that are okay with getting nothing useful done is striking.

You're mistaking the role of a mature company. Unlike a startup, in a mature company there are a ton of customers relying on your product and making sure you don't f*k up their business with a mistake or careless change is much more important than building cool new stuff quickly. You don't want your bank "moving fast and breaking things". There are a whole lot of industries where stability and consistency are an order of magnitude more important than fast innovation. This may not be as sexy or fun as rapidly prototyping some MVP, but it's how a lot of important stuff that runs the world works. To this end, a large org may not be everyone's cup of tea.

Yes, there will be some waste and bureaucracy at any large org, but that's not the same as a place full of people "that are okay getting nothing useful done". If anything, it's the established boring companies that are doing something useful (even if that something is not sexy or exciting), while a lot of startups are just burning through someone else's money designing things that no one really wants or needs.

Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the company gets sued? Your $BIG_COMPANY is not putting this change request through ultra-scrutiny just to frustrate you.

First, the team needing to do the work has about 10X as much work waiting in their queue than they can possibly do given their staffing. So your request either has to be more important than the existing work, you need to get a VP to expedite it, or you need to wait. It's not like there's an engineer just sitting there picking his nose browsing Facebook waiting for work. And even if you just yeet them a patch, they will need to set aside engineering time to review that patch, so back of the queue it goes, too.

Second, that work needs to go through (sometimes multiple) code reviews, have unit and integration tests written, and be able to show those test passing more than once, it needs to get reviewed by legal so it doesn't expose us to legal liability, it needs to get reviewed by security so my 9 year old can't use it to get a root shell, it needs to get reviewed by privacy/data protection so we know it's not leaking some user's personal information, it needs to get a systems review so we know it won't disrupt other critical revenue-generating services. I mean, what are you expecting, just type the code in, run a few tests, any yolo it into production?? No way.

A fantastic and experienced reply. OP, please listen to this

> it needs to get reviewed by legal so it doesn't expose us to legal liability

I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?

Usually it is more like "legal needs to be notified anytime third party dependencies are updated with a list of the licenses to make sure we aren't accidentally using GPL or proprietary code".

Other times legal gets involved earlier at the planning stages in case a feature or product falls under HIPAA or similar regulatory framework.

Actual code itself doesn't cross legal's desk anywhere that I know of.

The setup I saw is: there is an IP plan that documents whatever 3rd part IP you are using in your product (open-source or not). Someone has to sign-off on that plan, and sometimes developers do self-attestation that they have not deviated from it. Additionally, the binaries are scanned for certain things to avoid escapes of pre-release information, etc.

Our legal team has to review parts of our application to ensure we were in compliance with certain government programs such as ITAR and EAR. They don't do code level review but they do review business processes, UI's and messaging to make sure we're in compliance.

There is no code review by legal. There is a talk, usually multiple talks, between legal representatives and the engineers + manager delivering something. It's the engineers and manager job to explain what the piece of work will do and help legal understand its implications so they can gather knowledge and come up with their assessment given their skills in Law.

I think you read it too literally, legal will review what is the impact of some changes in compliance and so on but you, as an engineer, is responsible to translate what the code/feature/system is doing to something that legal can understand and reason about, it's part of your job if you are anywhere senior+ level.

I had to interact quite a lot with legal in my past couple of jobs, it wasn't ever an issue because the legal department seemed to be staffed with smart people that would understand what I was telling them, or would ask relevant questions to clarify their understanding, it's a two-way street, not a button to push on the PR to "ask for legal review".

Let's also not forget the value of having a person sitting there doing just the bare minimum needed to have some familiarity with where things are and what does what... so if something does blow up (and it will), (s)he can instantly step in and take emergency measures to restore service.

It's called 'reserve capacity', and some people think it is helpful

> If anything, it's the established boring companies that are doing something useful (even if that something is not sexy or exciting), while a lot of startups are just burning through someone else's money designing things that no one really wants or needs.

To be honest, SME remain the economic backbone of most modern countries and the size of SME still allow them to operate somewhat effectively. Most large companies are either slowly drifting to irrelevance, surviving on a steady diet of acquisitions from teams who could previously achieve things or milking a business line they established when they were smaller and somewhat nibble. Large companies successfully growing by building what you call important stuff without acquiring are the exception.

Working backwards from your label, what signs leading up to Facebook's recent outages could we have used to evaluate them as being or not being a "mature company"?

I think, perhaps, that being siloed, bureaucratic, large, profitable, and management heavy are not the best or only qualifiers of "maturity".

Given that the entire tech industry is built on making money with tools and services that are not useful to the society, it's only fair their employees take the mantra and apply it to their professional sphere of influence.

Totally agree. Would love to hear more about what you're thinking about. Didn't see your contact info listed. How can we keep in touch?

As much as this sentiment feels natural for an engineer there are a few things to keep in mind:

* you get exposed to a wider range of technology at a startup and can work on different things; that's more fun for you personally especially when you're under 30 yo and still learning the ropes; political indoctrination is mostly non-existent

* many startups at best get acquired; so all your "useful" efforts could end up in /dev/null or be completely replaced after the next VC round

* a minority of startups are doing real tech that's worth tolerating small company inconveniences; for every Imply/Rockset/Starburst there are many more companies building another web app, likely using inferior programming languages

* Big Co compensation and benefits are unbelievable for people coming from startups. Work/life balance cannot be compared too. Unlimited PTO could actually be European-style 4 weeks. I believe there were not so many posh places to work at ten years ago and so it was less realistic to join one.

* there's no question that startups and large corporations require dramatically different mindsets/habits. But you really get paid a lot to tolerate that smaller-than-a-tiny-cog feeling.

I mean sure there is "some" truth to it. But more likely than not the acquiring company has two conflicting priorities:

1. acquire startups/talent to improve certain things that the company is incompetent at

2. actively block efforts from the startup because a certain part of the company actually believes that they are doing things better themselves, i.e. ego

I advised a big US car maker on their autonomy and one part of the company actually took 8 months to acquire PC's to do machine learning with(which then ran into a supply shortage further delaying it) and 5 months to upload test data to s3. It's not that they weren't working on it. They had meetings every week.

You give them too much credit. Of course there is probably also that one guy actually implementing in the middle of the 20 people that just talk who's plate is completely full. But that doesn't stop those companies from hiring 20 PMs with their own agendas to manage that one guy.

If you really need the money keep working there. If not either force change it and get fired or run away.

Someone in Germany called it the 3 A's.

A - Akzeptieren -> accept

A - Aendern -> change

A - Abhauen -> flee

EDIT: in the time I was there half of the team of the acquihire they made quit and moved on to better opportunities, because the org itself took almost a year just figuring out how to get these people to migrate their docs from google docs to office 365

...or commonly phrased by my ex manager when I loudly complained about something as "love it, change it or leave it".

It was a hard truth to swallow, but rationalizing it, I quickly realized all other reactions to adversity are pretty pointless indeed.

There are people who thrive in large orgs and then there's others... eventually I realized there's simply no way I'll ever make peace with bureaucracy.

I can stand brilliant chaos and long, hard hours among talented people better than being a smart cog in the wheel who effectively does 50% of a 9-5 gaming the system and playing solitaire otherwise.

Everybody needs to choose their poison.

run, hide, fight

The three A's line up perfectly with the options presented in the influential book "Exit, Voice, and Loyalty".

https://en.m.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty

Not implying this is the case for OP, but there is also:

3. Acquire potential competition to get rid of them. There are cases where the parent company never intended to develop the startup's product, but simply wants to keep the startup from competing with them.

> is probably one request in a long queue of requests that team is dealing with

You've explained away the crux of the problem without even identifying it as a problem. Queues are an inappropriate construct for managing work. If something urgent & important takes weeks to even get looked at then there is a prioritization problem. If something that isn't urgent or important even gets worked on at all then there is a commitment problem. Based on what OP has described, the company is likely doing a lot of work they shouldn't be doing and working on things in the wrong order. Similarly, the work OP is doing may be much less important than they think it is.

Now, I agree that it's important to understand how the system works, but IMO it's equally as important to understand how it can be improved. Long lead times is definitely not a good thing, and also not a foregone conclusion at big companies.

The queue can be WSJF-t and still be long. Crux of the problem is OPs issue might not be as important as OP thinks.

Now if there are too many people waiting on the central team and all requests are valid the company should address the single point of failure. Grow the central team, train more externals to become contributors or agree to have duplication to a certain agree. Not everything is worth a platform with today's tools and (SaaS) services.

> If something urgent & important

Who said OP's task was particularly urgent or important? Maybe it's getting pushed down the list because they don't have a prioritization problem. We don't know - all we have is OP's (limited) perspective.

I also said:

> Similarly, the work OP is doing may be much less important than they think it is.

> Queues are an inappropriate construct for managing work.

I disagree. A queue is used to assign priority to a project. When there is more work than people to do the work, you need to prioritize and triage. Just because there is a queue doesn't mean that you can't handle urgent work. You can move it to the head of a queue.

Usually what accompanies a queue is a ticketing system. Nobody like these, but when the organization reaches a certain size, you need this. Tickets are good because it forces the requesting party to put down in writing what they want. This is a necessary step to ensure that right work is done, and it leaves and audit trail, for future people to see what decisions were made and what work was done.

I've worked in an organization where we used a stack based method. In that case the most important thing was the last request. This isn't a good way to work, because it's hard/impossible to maintain focus.

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

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

Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.

For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.

Echoing other comments, your company was acquired. The way you're used to doing things sounds like it's quite different from how the new owners do things.

I can't make any sort of judgment call on which is or isn't "better" based on a brief HN post, but I think it's worth keeping in mind that it pays to be adaptable and to scout out the post-acquisition lay of the land before you let it affect you too much.

You don't want to create an impression of being a "difficult" employee "left over" from the acquired company, as unjust or unfair as that may seem.

If you were just acquihired and no one high up in the BIGCOMPANY is taking an active interest in you. LEAVE. You are cannon fodder. The sooner you realize that the better off you will be. If you are contractually tied to the job, plan your exit NOW and leave the first day you can.

Look around and see where your former leaders are now? Are they gone or in positions of power? If no BIGCORP employees are reporting to them then you know the writing is on the wall.

Leave.

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

This is 100% correct. It takes time to find the people who can help you get things done and also time to build relationships with them. As others have mentioned, jobs (depending on the job of course) that one person can handle easily in a small company may take the coordination of multiple departments at a large company. For this reason you have to take the time to grow these relationships with those around you and in other departments. With time you'll find friends that will gladly help you accomplish the task you are looking to do!

Surely this huge company with lots of people, where most people didn’t ask to buy a new company, is doing nothing but sitting around waiting for this guy to give them some work??

>That team probably set up the onerous Google Docs process to gate requests because they get so many!

Also: they're likely understaffed, there's no division of responsibility - anyone could get a task for anything - and because of this, simply can't handle the volume of requests or route the requests to people who already know what's going on (and would be able to handle it more efficiently than someone with zero knowledge). Infrastructure teams often seem spread thin.

Dev teams are lucky that not every other dev team relies on them, usually. This reduces communication for that team significantly. Every dev team relies on infrastructure, so lots of communication overhead for them.

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

Somewhat ironically, I just left a FAANG where people constantly had this behavior of expecting me (or other members of my team) to drop whatever and prioritize their request.

I kept mentioning this to my manager as an issue because we needed to figure out a way to prevent this, maybe change it, etc. But basically it's a "company culture" thing (some people might be able to guess which company).

Also, know that as an acquired company and requests you submit are lower priority that the core company workload.

Agree and to elaborate : the companies will have radically different speeds goals processes priorities methods and cultures. Bluntly, you can be shocked and incredulous, or you can attempt to understand empathize learn and adapt.

Approaching the engineer and being surprised they shunt you to the manager for example - I sense that you are genuinely surprised. Fair enough. But from their perspective - it's a big company, lots of requests, lots of priorities, and they likely feel (rightly) it is their managers jobs to shield them from every enthusiastic energetic requestor in a large company. They are required but also judged based on completing assigned priorities. It is a survival skill to focus on those and ignore distractions and random requests from random people.

Similarly, you seem surprised you can't touch their code. You think about speed of development. They likely think about development standards, quality, supportability, maintenanability - and ultimately liability. If a random person from random team implements a random thing in their code... And if they let everybody do it (fight personal exceptionalism; if you want to do it everybody wants to do it), what state will their code be in?

Q1 2022 could mean anything. Large companies have freeze periods particularly holiday season. And they can have deep pipeline - your thing may or may not be a few days (pardon me but we as developers are notorious for being optimistic :), but may take a while to get to front of queue and then may need to go through formal stages.

There are reasons startups have high velocities. But there are also reasons why large companies have high conservatism - ultimately like any other Conservativism it's because they don't want to muck the status quo - they have more to lose.

Agree with both of you, and for the OP: Q1 2022 sounds pretty good in my experience!

A team you don't know much about, that has an unknown set of priorities and an unknown backlog of work from your perspective, and which has its own standards to uphold, and which probably interacts with a bunch of teams just like yours and thus has to consider the long-term implications of any feature creep -- that team is promising to get your change made in (allowing for holidays) less than one quarter?

At a Fortune 500 company that's a sign that you are being given a lot of respect, now try to make sure your team doesn't mess it up and make that deadline slip.

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

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

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

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

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

Everything in the story is quite reasonable! The engineers can't be taking requests from every rando that walks by, that works in a <50 person startup but not so much (not at all) if they have like a 10+K person engineering organization. An important part of their managers job is to run interference so they can get work done instead of listening to requests all day long.

"No response after two days"? At a largish company where I had such a request queue, we'd only read and triage them once a week. Anything more frequent would be too distracting. So two days is quite a good response time.

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

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

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

Having worked for years in large companies including in the public sector, your comment made my day. Everyone having experienced this kind of environment and not forced to drink the company kool-aid to advance their career knows the actual reason things take ages are far less positive especially when the request comes for a recently acquired team. Also bypassing process is the only way to truly achieve anything at very large corporations but doing it properly take skills.

Unless you are stuck there for reasons linked to your compensation or find you now want to work a lot less, provided you are good at building things in a startup environment, my advice is to leave as fast as you can.

Ahh the lifer life.

Can attest to this. Well not me, talking from experience from a friend. She keeps telling me about engineers from the startup that "they" acquired. Her team is already overloaded by requests from a bunch of other teams that they try their best to prioritize and deliver - it is hard work.

Even after that they get comments like OP "This is a simple change, why will it take a week?", "I can just finish this in few hours and submit a patch". I guess it takes a while for people to learn that writing code is only 5% of the effort, the rest of it is review, testing, QA, E2E, compliance and what not. There sometimes is unnecessary bureaucracy as well, but that doesn't mean that the actual engineering processes are useless.

The problem is that "learning the ropes" in a big org is often just an interminable slog of suffering from lack of information, dead-end rabbit-holes, and dealing with assholes. One is often forced to choose between being a doormat or being offensively aggressive with little ground in between.

In the context of an acquisition, especially, staff on both sides will be in fear of losing their jobs, status, or comfort-zone. There will automatically be barriers put up against change whether folks are conscious of it or not.

The OP just needs to talk to a human being.

It's his responsibility to reach out and find one. In my experience, the thing about big-company process is that YOU HAVE TO go around it to communicate. You have to talk things out with the RIGHT people in advance, come up with a plan in cooperation with them, have them collaborate by getting things warmed up on their side. After all that the stupid meetings and "approvals" are just formalities. In fact, you can tell when this is the case when project decisions are handled with almost parliamentary procedures. There's no room for discussion and thinking things through in such meetings-- everything, EVERYTHING, has to be worked out in advance through side-channels.

Let’s compare two large organisations: NASA and SpaceX. According to astronauts who have worked for both, it takes a year to get a simple UI change implemented when working for NASA, and it takes one day when working for SpaceX. The difference is bureaucracy. Not the amount of actual work that needs to get done.

Indeed. Large organizations have prioritization issues. You need to explain impact so the manager(s) can prioritize, don't discuss technicalities (known unknowns).

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

To add to this, something that helped me accept this change: your acquisition marked the achievement of your startup goal. You're done now, you can now stop living for your work, and start working to live.

or pick up a new hobby that occupies the mind! Or start the next thing!

I think OP was an employee at a startup got acquired. Which may or may not mean they got a huge financial windfall from it

I get where you are coming from, but even if you don't get huge financial windfall, there is just no point in sacrificing yourself anymore. It's not going to make as big of a difference anymore.

If you don't get a huge financial windfall, there was never a point in sacrificing yourself.

And the truth comes out.

Unless you're employee ~3, you're probably not going to make a huge financial windfall. The only counterexample I've seen was from an employee who invested in startups themselves. (Apparently he even "investment sniped" one that later became a YC co, which I found pretty impressive.) Suffice to say, he knew how to play the game.

I think lots of people work at startups because they like to work. There's nothing wrong with that. But don't be too surprised at the end of it when you walk with a total comp of less than you'd have made at $bigco. People work at $bigco for the money because it sucks -- that' why it pays $bigcash -- and OP's story shows the kind of pain you're avoiding by taking a pay cut.

OP, I wish you all the best. If this is your first experience with a big company, well... Just know that it's far worse at big banks. :) You're lucky in that sense.

Then this is the time that the OP needs to join a startup as founder or early employee and get meaningful equity in exchange.

You mean in 5 years when they have saved up a nest egg using that stupid big company money and stock options that are actually worth something.

When you win the lotto you don't toss away the ticket so you can play again. Even if OP didn't cash out founder style - they still get essentially a multi-year paid vacation.

I really doubt he saw a large compensation increase with the acquisition.

When $snallstartup I was an employee at got acquired by $hugemultinational, all we got was a big fat juicy 1000$ „bonus“, an attaboy, and those who had been grossly underpaid for years were brought up to market pay. And that’s it.

And "market pay" being HR's idea of the going rate, not what a good engineer with niche knowledge and startup experience could command at a big tech company.

Bingo. I've been through a similar situation, and what helped was realizing I 'won'. Unfortunately not a unicorn type win, but a win nonetheless. Relax, recharge, and then look for the next opportunity.

I think a lot the advice in this thread about navigating large company politics is missing the point a bit. I've heard entrepreneurs and people who like to work at start ups describe they don't do so because they necessarily like to, but because they have to. They are either bad at, or can't/refuse to deal with large company politics so head in a different direction.

This.

I call this achieving Enterprise Zen.

You have to let go of your attachment to productivity and ponder on kohns such as "If a task is accomplished but no one sees it on a report, was that task accomplished?"

Ugh, the management visibility dance might be the worst part of enterprise work.

And this is only beauty of JIRA and sprint reports being a KPI in an org. I wouldn't so much as even lift a finger unless it had a ticket assigned to it.

If this work doesn't show up on a report, should I do it. Not unless you want your hand smacked.

we call this :PASOK:

Aren’t they out of office?

Completely agree. I would add, though, that there is no reason not to recommend improvements if you can think of them. You don't have to just accept that things take forever, are broken, and everyone hates life. It's not all that rare to find a good manager even at a big Org that wants to help improve things where they can. But if they reject your suggestions then the Zen approach is by far the best.

Exactly. There are environments where individual proactive efficiency is highly rewarded and respected, but not all. Sometimes you just need to settle down into the same flow as others. Trying to swim faster than the current just doesn't pay and can also breed resentment toward those who have mastered the coasting mentality and seem to be doing better off financially and mentally.

Or, more usefully, find (or ask your management to help you find) something else useful to do while you're waiting on the other team.

External blockers can be a frustration if they are blocking what you want to get done, but they can be blessing if they are blocking work you don't care about. So you can't move to the corporate VM for at least a quarter. Great! More time to do more interesting work instead!

Keep your corporate integrations on the periphery so you can develop, test and ideally deploy the core code without dependencies on other departments. I mean this in both the code-architecture and org-chart senses. Accept that those integrations will move at the speed of bureaucracy, don't put them in the critical path, and continue to enjoy developing the core.

If this isn't possible, then move on.

"Care enough, but no more."

Also: consider the possibility that bigco bought your littleco not to nuture/integrate/leverage it, as they said in the press release, but to kill it. Help your new corporate masters achieve their nefarious goal by taking their paycheck until you find something better and then split.

It's stupid, but are you really willing to try to solve all of the world's stupidity?

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.

You raise a fair point here - good managers protect their employees’ time, however in this case, the the task was not a “personal task” but rather an initiative handed down from the parent company, without giving OP the proper resources and guidance to complete the task.

If that’s the case (and having found myself in that position many times, it likely is), this a failing of the parent company. I’d expect those managing the integration to assign point people, both technical and managerial, to assist with OP’s task, schedule introduction meetings and communicate expectations to both teams. That’s not too much to ask. It sounds like OP was left to navigate the situation on their own.

Based on the description given in the OP, I don't think we have enough information to conclude whether the OP was given the right amount of resources to complete their task or not. While the "migrate to the new deploy infrastructure" might be the most important task from the OPs perspective, there's nothing there to indicate to me that it's a particularly important task from the broader businesses perspective. Indeed, I wouldn't be surprised if this expectation was already communicated to the engineer by their manager, which is why they're here posting about it.

Of course, it's entirely possible that you're right, and if this was a more important issue I definitely agree with you that it needs to have a dedicated resource assigned from the deploy team and it needs to be scheduled into their roadmap somehow. Ultimately we're just all speculating based on the small details the OP gave us.

However, I think my core point still stands—even if OP is right to feel that the deploy team is making the wrong decision in general about prioritization, they need to at least consider that the deploy team has other, competing priorities that they're juggling, and that the actual change might be more complicated in "at scale" (code review, QA, interaction with other options, documentation, long-term maintenance, etc) then OP is willing to believe.

> This feels like a rant that comes from someone who doesn't have a lot of experience deploying and maintaining complex systems over long periods of time.

Agree. Also:

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

If migrating the app to the new platform is a priority, why not escalate up the startup's leadership chain to get it prioritized higher in the infrastructure team's roadmap? Looks like the startup was poorly run, with no clear escalation paths, and employees unaware that such mechanisms exist in companies (and find it odd when they notice another engineer do it).

Honestly, I kind of regret the sentence that you quoted. Whether the OP is correct about the complexity of the change or whether the deploy team is right to be protective over it is is really missing the point—the point is that the OP needs to have more humility and understanding for the perspective of the other team when navigating these processes.

EDIT: I felt bad enough that I went and edited that sentence, in case anyone reading this later is confused.

> Looks like the startup was poorly run, with no clear escalation paths, and employees unaware that such mechanisms exist in companies (and find it odd when they notice another engineer do it).

Might be appropriate for a startup?

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

Yes. I don't have a manager at the moment, so I have to field these requests myself and my productivity has tanked.

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.

Exactly, and:

> I'm working on migrating our apps to the parent company's VM launching and deploy platform

Who asked you to do this? They should be "going to bat" to make sure that you're getting what you need to do this.

If it's some high up in your acquiring company who asked for this, that high up should be talking to the other team and making it known that they need to cater to you.

But: If this is some initiative from your team because you're good team players, expect whoever wants this done to put in the political grind. ("You asked for xyz, you need to do the politics if you want this donw.") Otherwise, it's best to move to a different task.

If you need it now to do your job, one strategy companies use is to escalate the request to the common point of reporting (even if it is the CEO). You and the person you are in conflict with (the other manager) need to write an escalation doc describing the conflict. It won't get to the CEO as there will be increasing levels of embarrassment up the report chain. If it does hit the point of common reporting and she says end of Q1 2022 you've got to accept her decision

Eeeeexacly. Working at a big company is a skill itself. I mean lets face it...we all can code, but can you code in a big company and work around bureaucracy and try to deploy at the speed of a startup (or close to it)? I know people may laugh, but it's a question to ask. For example you can't plan your infrastructure a week before you deploy because you gotta have the infrastructure team approve your requests (which requires architectural and security approval), and you gotta have the allocation for your project in the first place (of course the trick is if you forget you get a resource from an existing parallel project on your team!)

In ops case there is a disconnect. Whenever I had something high priority and I get red tape...there's 2 solutions

1) Escalate escalate escalate. Their manager doesn't help? Their director will. If their director isn't helpful...then sorry it's not really a high priority. I've NEVER had to gone above a director for escalation because the entire org was aligned with what was a priority. You might face a manager trying to protect their team but if their director says jump, they ask how high. Perfect example is a firewall rule takes 2 weeks to open up (security approval, firewall engineer allocation, etc etc). Guess what...I got like 3 open up with 24-48 hour turn around time each (kept getting blocked at different hops) for a high priority project.

2) If you've been around long enough and you have a good track record, you know people on a personal level, you do favors for them...people will do favors for you. You ping them, add a few emojis, reminisce about old times...and an hour later it's done. The other week we had a deploy and we forgot to contact an infrastructure team to let them know they had to promote something in production. Usually your deployment is dead in the water, because a new prod change request needs approval, yada yada. Well, of course there's a deviation for that (In Big Corp. there is ALWAYS a deviation for something). And I know their team lead, their manager and their Project Manager...we were back in business after negotiation what we needed to do to do it 'properly' and not get flagged for an authorized change.

1) Learn the skill of cutting red tape which a lot of times is escalation, planning ahead or being creative. 2) Be nice to people. If you're the new kid on the block and already pissing off people...you're going to get enough red tape to wrap everyone's Christmas presents at the company.

Use your new found knowledge sparingly. You don't want to be the boy that cries wolf.

Oh yeah - I've also been on the other side of the boat. Our big corp company sold off a division...we had a certain amount of time (months...) to split everything off and hand everything over. In some cases we had to rewrite entire applications to work with their xyz software/infrastructure/tech stack, whatever. If we don't meet the deadline, company pays a penalty per day or whatever. In other words - high priority.

We had to realign projects, drop projects, carve out resources. This also means anytime we had any requests as OP is mentioning, we get in front of the line if we mention the magic words.

My point is - if something is important at Big Corp, it gets done. If it's not getting done, it probably isn't as important as you think it is.

Another example is - this recent log4j security vulnerability. You think people sat around waiting for approvals? Hah. Every application had a few days to fix test and deploy. People were called back from vacations. Deployment freezes were magically unfrozen.

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.

My response to "Oh, I can implement this in 5 minutes" is always "but will you support it?"

I think this is the hardest thing about moving from a startup to a more mature company (either through growth and age or acquisition); you have to move your mindset from building to supporting. Building is fun and creative, supporting can be tedious and soul sucking (but needed!). It's a huge, and legitimate, reason why large companies slow down (either to support, or to consider support in the build process).

And it's not just large companies that slow down, either. I work for a very small organization (three developers) that's been around for 10 years. We'd love to spend more time building new stuff, but we've got 10 years' worth of old code to support. We don't have bureaucracy getting in the way, but we still can't move as fast as new startups.

I've only ever worked at small companies, but have a few friends that work at larger ones.

And I always bust up laughing reading their stories about trying to avoid adding even more code under their support umbrella. One person wrote a useful tool for fun, it got passed around and all of a sudden an unrelated team from halfway around the world started asking him for features.

It's definitely a mindset I'm not used to.

> "Oh, I can implement this in 5 minutes"

Close to a decade ago I got into a heated debate with my then boss over a project which was delayed and got served this(just with three months instead of five minutes).

I was fired and sure enough, few months went by and I get a call from the client asking if I could testify against my former boss.

That crazy sonofabitch actually tried to pull this off, but grossly underestimated the project's complexity, to predictable results.

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

Also, changing the app itself is an option. The $LARGE_CORPORATION infrastructure works for other apps, if it doesn't work for the acquired app, it's not a given that the infra must add features but perhaps rather the app should be restructured according to $LARGE_CORPORATION habits. Sure, it will take work, but if according to OP the alternative is to wait a full quarter, then changing the app might be possible in that time.

I think I give about the same advice, so I put this here

When life gives you Bozos, enjoy the circus while you're there.

Get the most out of it.

This may very well be your best opportunity to deeply determine exactly what this sluggish bureaucracy needs to overcome this type of weakness and result in improved performance by an excellent margin, or maybe a multiple.

Even if you don't get to deploy many of your ideas under the current situation, it's always good to know how to turn bigger companies around.

In case you do get into a position where that may be expected of you someday.

Develop the qualities that are most needed by this size org and if there is very little uptake then you just keep becoming more valuable to another outfit and more able to avoid places where they actually don't get as much done as they should.

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.

This is probably the correct answer in most circumstances, unfortunately. It's just the circle of life. Acquisitions are rough and if you aren't being significantly incentivized to deal with all the extra BS that comes along with it, then it's time to move on.

But while you're along for the ride (or trapped on the slowly sinking ship), it can be really helpful to see where the big company's policies and procedures are outright dysfunctions. Not everything they do is merely "this is how things are done in all large organizations." Then you can take a list of a few practices that result in ossification and a slow death to your next small startup. Maybe you won't take away a polished playbook on how an industry leader handles product development, but having firsthand experience on what breaks at "scale" is also useful.

Some hypothetical examples: What happens when there are more than four engineering teams? What changes when dedicated scrum masters are introduced and begin arguing about whether work belongs in sprint 133 or sprint 134 while walking past your cubicle? How do enterprise contracts for PaaS providers work? And, at my current employer, what happens when more than 100 engineers' work is shelved for holiday "frosts" and "freezes?"

Afterwards, you'll have more interesting conversations with the bright-eyed 23-year-olds working with you at The Next Startup. Instead of "I feel like this is a bad idea," or--heaven forbid--"Because I said so," you can confidently state "Company X tried Y. Z was the tragic result. How can we implement Y, but avoid Z?" It's one thing to have head knowledge of why frequent releases are beneficial, but watching what happens the moment a code freeze is lifted and hundreds of commits hit production? That's priceless.

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.

It sounds pretty standard, and it doesn't sound like the OP has put a lot of work into considering why it works the way it does.

Know that annoying executive who likes to come to the development team and ask them for work? That's what the OP is doing. And how he then loudly laments that he will have to follow some process to have his request added to a backlog, before, at some opportune time in the future, it can be considered and possibly scheduled for being implemented? Yup, OP again.

We hate it when process hits us, but you'd hate it even more if there was none.

I was an ops manager at $big_company like the one described; your response gets it pretty right. There were many many groups that all wanted a slice of our team's time, and it added up to probably a 6 month lead time on all requests. Bringing in skip levels was almost necessary as we sometimes had to have upper management fight over who wants their subordinates' tasks done first. We didn't care who's tasks got done first, we just needed to know what the enterprise's priorities were. It wasn't uncommon for these tasks to have to snake through multiple groups for a couple weeks so that they can each give their input on what should be prioritized before it even hit our backlog.

If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no.

All of these gripes are just big company issues. I suspect OP is a better fit for smaller, non-public companies.

> If their parent company is publicly traded, giving access to the codebase is a huge SOX no-no.

Could you please elaborate on this?

Sure. So while Sarbanes Oxley doesn’t contain anything like “thou shalt not commit to a repo”, it’s pretty clear about separation of duties. This means that the person who commits code cannot be the same as the person who deploys (or has access to deploy) the code.

There’s many ways to implement separation of duties that are all valid, but the compliance industry has settled on the concept of least privilege as a framework to enforce this requirement. So if a person external to a dev team wants to write to their code base, the hard rule of least privilege keeps the regulatory train on the rails, so to speak. Keeping that wall between external teams reduces risk in the company, at the cost of increased friction and reduced agility. Consider it a part of the price to pay for investor money.

If you have any other questions I’d be happy to answer!

Very interesting, thank you. I’m not based in the US, so was unaware of these regulatory requirements. I can certainly see how it increases friction, as you say.

Agree 100%.

However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling.

Now, if they don't have a roadmap, and their prioritization sucks, that's another matter, and entirely possible, of course.

We see the matter from the OP's perspective only, who knows what he was told.

> However, the manager of the other group should get some management training. He did a piss poor job at communicating. All it would've taken is explaining the group's prioritization and roadmap and the OP would've not left with "THIS COMPANY CAN'T DO SHIT!" feeling.

My impression of the OP is that he expects other teams to drop everything and make the change. He may have been told about the roadmap but feel that his project is more important. That seems more likely than the following excerpt from the post.

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

But what's not allowing access for compliance reasons and that's it? There should be a form where he can request access if he thinks he can pull off an implementation in days of something that takes months otherwise.

I worked in big and very big corporations and cut through PCI, HIPPA, and lots of those with requests like that. That they have forms and scheduled for a month in the future (assuming second half of December doesn't exist which is reasonable) is good. But that there's no process to get access to their code and figure our what's going on is not ok. Specially if they are an infra team.

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.

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

I'd quibble with your word choice and replace "and somehow..." with "because of this". It's apparent to me that you can work faster and do it cheaper when you're cutting corners, which is where some of the value in startups lie (in addition to the actual innovation).

Acquiring companies do a lot of heavy lifting to ensure compliance in all their markets. As a startup, front end devs could push out a feature in half a day; bur that was in (American) English only, with no review of the copy by Legal, and didn't comply with EU accessibility standards on minimum contrast ratio, nor did they check to see of it works with screen readers. Each of these things could cause legal/regulatory/reputation problems for large companies, but all the former-startup engineer sees is bureaucracy - because they are now working at a scale they are not familiar with.

A startup may ignore colorblind users, with no consequences, but the DMV should not. For large societal problems, MVPs do not cut it.

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.

> It's probably necessary work, but not important.

I like the direction you're going with this but note that a task being necessary also implies that it is important - otherwise it would be optional!

The only success I've ever had (but at a small co) with getting others to work out what is important and what isn't is by forcing the requester/decision maker to prioritize goals against each other. It gives the opportunity cost a more personal, and therefore real, taste.

We’re probably quibbling over semantics here. I use important in the dictionary sense of having a profound effect on survival. The company won’t go out of business if those VM tasks don’t get done for a couple quarter.

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.

Mid-size companies are where it's at.

The huge ones (1k+ employees) are way too big and unwieldy and you'll get lost in the bureaucracy and get fed up with all the people promoted based on the Peter Principle. Good stuff if you want a peaceful-ish place to work at, maybe you have small kids at home and just want to work 9-5 and bring zero work home.

In small ones (dozens) you tend to become the smartest person in the room too quickly, you also usually need to be a jack of all trades and have very little advancement options. On the other hand you can do all the cool stuff and break stuff =) Work-life balance usually doesn't exist.

Mid size corps (hundreds of employees, but way under 1k) are the sweet spot in my opinion. Large enough to have some structure, small enough to not have too much red tape if you need to get stuff done. You can also do lateral moves easier, change specialties or maybe even get some team leading experience.

100% this

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 on two companies which got acquired by much larger companies.

I understand that some things need to be standardised for an enterprise.

But what I hate is that the acquiring company often tries to totally change the company they bought. They bought the company because they did something well, why don't they try to learn from that instead of forcing their system on the new people?

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.

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

Uh? I think it’s pretty random to say that kind of stuff without knowing anything about the new company. I can’t see any decent company firing newly acquired employees because they want to move fast…

> I think it’s pretty random to say that kind of stuff without knowing anything about the new company.

Works both ways, right?

Probably the key negative was:

> This is a simple task

Is it? OP has no idea about the software it's being integrated into, and while it may _seem_ like a simple task in principle, it may not be, and it's a judgement on the work that's on another team to deal with. Quite easy to fall into a trap of trivializing work that you yourself aren't responsible for.

Also,

> he doesn't have an answer

You sure? Literally speechless?

> Is it? OP has no idea about the software it's being integrated into, and while it may _seem_ like a simple task in principle, it may not be, and it's a judgement on the work that's on another team to deal with. Quite easy to fall into a trap of trivializing work that you yourself aren't responsible for.

Right! May be the team/manager he was talking to - had no capacity left for the current quarter. There could be dependencies on other teams that might require some planning etc

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

O man! I believe OP has a lot of insight into corporate dynamics. It exactly happened to a friend of mine. Those corporate seasonal managers does not like to be questioned or give any input. A friend of mine did something similar, and guess what - he was laid off after few weeks; very shortly after starting at a mega corp $

Not only did they fire him for daring to question a manager, they fired a bunch of other people to cover their tracks!

It’s almost as if layoffs are common after acquisitions and correlation is not causation.

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

Almost certainly not. This requires actual malice on the part of the manager in question. The manager in question doesn’t have any direct authority over OP (unless OP is really bad at storytelling) so would have to go way out of their way to hurt OPs career. Much more likely, the manager doesn’t care about OP at all, because why would they?

But yeah, unless OP is waiting on piles of stock to vest, move on. But because they are unhappy, not because of this random manager.

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.

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.

I mean, how much work is it to change to another method of vm provisioning and deployment? Could be a bit, but I mean… that’s what you have to do during an integration… I’d love to know why this is a blocker really, reeks of “my precious hand crafted helm (or the devops magic that makes everything work was written by someone who isn’t around anymore, and it’s too scary to fsck with) needs to be binned and I still attached to it”

Sorry op, you don’t own it anymore.

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.

> and you can reasonably get away with doing absolutely nothing

I see comments in this vein a lot and it just blows my mind that you'd want to sit around all day doing nothing. To be clear, I'm not advocating the sort of role/company which demands 110% for 12 hours a day, work/life balance is extremely important. But I could not find any enjoyment in just sitting at my desk all day without actually doing anything productive. I guess I'm fortunate enough to have a job which I really enjoy.

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.

Yes, yes yes! This is an interview question I (at big tech) like to ask candidates: "You have a very high priority project and need another team's help. You find they already have many "high priority projects" that they are working on. How do you go about getting this help?" A good answer to this question often separates the actual senior engineers from the junior "Senior Software Engineers". Navigating a corporate bureaucracy and influencing across it where you have no managerial control is a skill you have to develop in Big Tech, and when you get good at it, it's a superpower.

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.

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 makes it seem like meaningful work cannot happen outside of a startup environment, which is patently not true.

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

Sounds like you could be getting the blues from working there…

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.

> very grown up sport, more like running a country than building a house

We need to stop calling things "grown up" when what we mean is that they take a different set of skills. It's childish, and I think it's been causing harm in our industry.

So it’s okay to refer to something as childish but not as grown up?

so much irony

It's okay to refer to capabilities that should be expected of everyone as "grown up", and falling short of those standards as "childish". It is harmful to extend that to specialized skills, because it leads people to forget that they are specialized skills that aren't going to be learned through mere maturation (and that their lack doesn't necessarily imply immaturity).

I agree with this and it’s how I felt when I read the parent.

A recent startup I was involved with hired a senior manager from the “grown up” end of town and he is in the process of comprehensively destroying the business because the rules and processes are more important to him than shipping product. He literally has no idea what he is doing, and it’s entirely because he doesn’t have the skill set necessary to bootstrap a company.

There is a stark difference between the mindset and skills required to start from zero versus those required to defend billions in revenue, and it has nothing to do with being “grown up”.

“Tell me you never bootstrapped a startup, without telling me”.

I dislike your condescending tone and I also think your speech doesn't generalize.

There are large code bases in production that are productive: Everything that is open source - and still the process isn't as shit as op describes.

So this has to do with corporate hierarchies and not the quality of the code.

The original post is pretty condescending, it's just worded slightly less so. Now, that doesn't mean the very best response is to be condescending, but the invitation is right there. Sometimes a reasonable response to ~ "can you believe these idiots!" is "actually, look in the mirror, and squint a little".

> There are large code bases in production that are productive: Everything that is open source

Yes there are but these are not without rules. Try to add a new feature to a large open source project as a new contributor. That has probably as much chance of succeeding as doing this in an enterprise.

There is a reason larger OSS projects have the "good first contribution" section. These are small bug fixes where the work is already spelled out typically. You do these to get familiar with the codebase and learn how to make a valuable contribution the size of a feature.

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

Your post does a good job of that.

Man, unvarnished, lacking agenda---besides the stroking of one's ego---and blunt communication: I missed you so.

I agree with the sentiment. Being an "adult" is about restrictions, limits, boundaries, and confines; you can't just willy-nilly do whatever you feel like. You must now realize and accept that we all bend the knee to something. We are not immortal gods, free from all consequence, but merely ants allowed to live by the systems we inhabit.

Perhaps the most authentic post I've seen on this entire site in a long time.

You're presenting one way of running, "a large code base in production" as if it's the only way.

It's not.

The other way is to deploy frequently, accept some amount of bugginess, and build your systems to deal with it appropriately.

Running and maintaining a large code base is not the huge technical challenge it once was, but unfortunately the relics of the past remain, and force everyone to do things their way, lest their hard-won knowledge becomes obsolete.

Maybe they are frequently deploying to prod, but those pipelines are being used by other processes and commits.

There's a big differece between committing small changes to an existing service or infrastructure base frequently, and conversely a PR or feature request from left field from a recent acquire.

The code bases we have today are vastly larger than at any point in history and grow larger every day. The past is not so black and white.

You guys complain about things taking quarters to complete. In other industries like aerospace, small changes take years.

There is a large gradient between 'fucking around in production' and crippling big corporate process. Maybe the big tech companies all have the perfect amount of process, but much of the process and ceremony at other big companies I've seen is simply in place to keep the lowest common developer employed. Heck, people complain about excessive process on this very site all the time.

On other nitpick is that startups live and die with automation by their lean nature. They have fewer resources and must automate everything they can. It's built into startups mindset.

Try to think about the other side of this. Do you want to be standing in line at the grocery store and have your debit card just not work at all because Visa aquired this dudes startup and he didn't understand that feature X wasn't implemented because it would swamp the 10 megabit VPN link between Visa and your credit union?

It isn't about keeping the lowest common developer employed, it is about keeping the lowest common developer from bricking the entire system. Unless of course you can tell me where to find enough developers of your skill level to write all the code required to run a modern society.

consider $bigco making $10B year

that's $20K/minute

chances are, $shiny_acquisition isn't making $20K/minute, and woe is the helpful IT responder who kills the golden goose. it'd be crazy if anyone can do that, so many layers of bureaucracy & compliance have evolved to prevent that.

The solution is generally (a) do work not involving production (b) work where production isn't like that, which is generally smaller companies or a surprisingly small number of ~tech companies. Digital Transformation (cloud, PaaS, ...) often involves trying to enable self-serve at enterprise-scale, but I generally still see roadblocks when GPUs, TLS, DNS, SaaS, etc, get involved.

Instead of sending the credit card ID number across the phone line, we will take a picture of the credit card for extra security, and send a full RAW PNG each time.

> On other nitpick is that startups live and die with automation by their lean nature. They have fewer resources and must automate everything they can. It's built into startups mindset.

I am at a medium sized company. We acquired a startup. They did not "live and die with automation", instead they contracted out the production operations. A dozen customers, all on snowflake systems which were constantly tweaked directly in prod with no documentation or audit process.

My experience on the acquirer side is that startup engineers like to just build stuff and deploy it. Design? Testing? Documentation? Automation? None of that existed in this company in any fashion. And they are themselves grating against a modicum of process. Please explain what you want to do, why, and provide a high level design. You are going to replace the whole auth system, it's not something you just "figure out" as you go along... Sigh.

> My experience on the acquirer side is that startup engineers like to just build stuff and deploy it

This has been my experience exactly. Automation has a high upfront cost where that payoff is in the long term. As a startup the priority is on income now. Not cost saving that pays off over the next year.

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

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

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

> A dozen customers, all on snowflake systems which were constantly tweaked directly in prod with no documentation or audit process.

I've directly seen this at all sizes of companies. I worked at a billion+ revenue company and watched my boss edit stored procedures directly on production (for way more than a dozen customers). I ended up encrypting them in prod to force him through the build process I made.

The point is that there is wild west going on everywhere, and the size of the company is only one factor. There are startups with great engineering and big companies with terrible engineering. It's just the state of software right now.

For those on the other side, who inherit startup code and have to fold it in ... the hatred is mutual.

Yeah, I was wondering what this might sound like to the other side, perhaps something like:

"Yeah, hi, I just got here last week, I'm here to inject innovation into your life. So your battle tested deployment pipelines that deploy all the code that pays both of our paychecks (because my stuff is pre-revenue, naturally), they don't support the idiosyncratic workflow I literally made up myself. Can you drop everything and jump on this instead?"

But Microservices?

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.

Moving slow isn't bad? Try mentioning that at the next standup.

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/

Why are you shilling articles for sifted.eu? Every comment is a pointer to an article on sifted.eu. @dang is this normal user behavior?

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.

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.

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.

Stuff like this is why I'm trying to get out of the industry and just write games by myself or with 1-2 other people. It's such a complete... well, ball-drag working in this environment, and I'm so burnt out on the fast movement of startups despite having enjoyed it previously.

Yeah it's why I intentionally take long breaks now and then (f your recruiter and his complaint about "work gaps") just to learn how to be human and creative again.

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

Before doing that, make sure you have a new job lined up, because your life is likely to be made even worse.

They won’t care. Their job isn’t to worry about employee satisfaction. They’re more worried about going public or getting acquired.

As others have said, they're fully aware - after all, they've been working in such places all their working life. It's just an accepted way of doing business and plenty of people are happy to work in such places (due to almost always being blocked by something, you don't have to put in a lot of effort, while the pay is often very good).

What will this accomplish?

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.

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

Isn't this dangerous advice? Could work done on a side project during company time end up being legally owned by their employer?

Assuming you're salaried, there is no such thing as "company time".

You should make sure to complete your work projects. Then work on your side projects. Use your own machine so as not to have the conflict of interest.

Reply on news.ycombinator.com