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.

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

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.

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.

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.

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

Great bosses like this exist

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

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

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

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.

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.

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

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

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.

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

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.

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.

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.

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

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?

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

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.

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.

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

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.

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

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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

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

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?

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.

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

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.

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.

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.

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.

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!

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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

Might be appropriate for a startup?

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

Could you please elaborate on this?

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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 ?

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.

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