Ask HN: Startup acquired by a large company and it sucks. What to do?
444 comments
> 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.
Your simple task, which you think would only take a few days to implement, is probably one request in a long queue of requests that team is dealing with. That means they won't be able to start on it for a long time.
That team probably set up the onerous Google Docs process to gate requests because they get so many!
When they do start working on your request, maybe it will only take a few days -- or maybe you underestimate the level of effort required because you are new to the company and you don't understand the complexity of the systems you are dealing with.
Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. Instead, assume that people are dealing with a lot of other requests, from a lot of other people. Learn how the system works, and learn how to be effective within that system.
I know for sure that it's possible to be highly productive at a large company with a lot of bureaucracy -- but I also know for sure that new employees who try to bypass process and question the priorities of other teams, before they learn the ropes and build credibility and trust with other people, do not succeed.
>Is this how it's like at all large companies?
Not all, but a lot.
>What should I do?
Short term: Mentally check out. Embrace the Zen of just doing what's asked of you. It's not your job to be a go-getter anymore. Half because of institutional complexity/inertia, and half because in a tall organization hierarchy the middle managers don't want anyone below them swimming outside their lane (even if it would be to their unit's benefit and they can take every ounce of credit).
You'll notice that many people in this thread explaining why you shouldn't expect this or that from other teams. And they're not wrong, but none of them are acknowledging or explaining why those reasons weren't automatically communicated in your conversation with those teams. You're not only not seen as a problem solver anymore, you're also too low on the totem pole to be owed an explanation.
So follow the official processes to adapt their system to your product, and your product to their system. Keep your management in the loop about the time cost of both options, it's their problem to fix, not yours. Pour your mental energy into something outside work.
Long term: Decide if you like being checked out or want a new job.
Not all, but a lot.
>What should I do?
Short term: Mentally check out. Embrace the Zen of just doing what's asked of you. It's not your job to be a go-getter anymore. Half because of institutional complexity/inertia, and half because in a tall organization hierarchy the middle managers don't want anyone below them swimming outside their lane (even if it would be to their unit's benefit and they can take every ounce of credit).
You'll notice that many people in this thread explaining why you shouldn't expect this or that from other teams. And they're not wrong, but none of them are acknowledging or explaining why those reasons weren't automatically communicated in your conversation with those teams. You're not only not seen as a problem solver anymore, you're also too low on the totem pole to be owed an explanation.
So follow the official processes to adapt their system to your product, and your product to their system. Keep your management in the loop about the time cost of both options, it's their problem to fix, not yours. Pour your mental energy into something outside work.
Long term: Decide if you like being checked out or want a new job.
A lot of people have talked about the issues with this post, but I wanted to call out one specific thing:
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.
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.
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.
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.
This is where your manager (and if necessary their manager) needs to get involved. Is this actually important and urgent work? If so, they need to work with this other team’s management to get this done. If not, it can wait.
What you’re describing sounds like a particularly dysfunctional and bureaucratic corporation, but dealing with politics like this (and that’s exactly what this is) is part of being in a large company. Cynical people will say that everyone is just trying to protect their fiefdom, but most people are just trying to do the most important work.
That team you’re asking for work probably has hundreds of feature requests every quarter. The process is intended to protect the engineers from being randomized constantly by low value requests. But yeah, the trade off, especially if taken to extremes like this, is that it can slow collaboration to a crawl.
You wanted something done, you explained why it should be done, they agreed and will implement it.
I would quit that job immediately! I'm not even being sarcastic. If it bothers you that much that people like to plan things and that takes too much time according to you then yes, just quit. I've been on the other end of things where someone said: "Oh, I can implement this in 5 minutes". The first few persons I would happily explain why this isn't the case, but after that.. thank you managers for isolating me from this crap.
I would quit that job immediately! I'm not even being sarcastic. If it bothers you that much that people like to plan things and that takes too much time according to you then yes, just quit. I've been on the other end of things where someone said: "Oh, I can implement this in 5 minutes". The first few persons I would happily explain why this isn't the case, but after that.. thank you managers for isolating me from this crap.
> ahem: you told us to migrate to your platform
_Someone_ at $LARGE_CORPORATION told you to migrate, but clearly this team didn't. They have no idea who you are, what you're working on, what your timelines are, what the priority of this work is relative to other things happening at the company, or whether there's other things you can be doing in the meantime. Yet they actually did some diligence, got it approved (after 2 days even), and got it on their roadmap. As others have mentioned, you need to invest in figuring out how to get things done at $LARGE_CORPORATION. Acquisitions are a dime a dozen and certainly do not pre-empt things like security or compliance. This could be a great opportunity to dig in and develop a better understanding.
At large companies communication and alignment is generally more difficult to solve than any of the actual technical challenges. You may not like it and choose to leave, but at least try to develop an understanding so you can take that lesson with you.
_Someone_ at $LARGE_CORPORATION told you to migrate, but clearly this team didn't. They have no idea who you are, what you're working on, what your timelines are, what the priority of this work is relative to other things happening at the company, or whether there's other things you can be doing in the meantime. Yet they actually did some diligence, got it approved (after 2 days even), and got it on their roadmap. As others have mentioned, you need to invest in figuring out how to get things done at $LARGE_CORPORATION. Acquisitions are a dime a dozen and certainly do not pre-empt things like security or compliance. This could be a great opportunity to dig in and develop a better understanding.
At large companies communication and alignment is generally more difficult to solve than any of the actual technical challenges. You may not like it and choose to leave, but at least try to develop an understanding so you can take that lesson with you.
One thing you should consider (not an infra eng myself, but I know a lot at the FAANG where I work) is that the infra team gets a lot of requests for stuff like that.
There's a general dislike of special-casing all build deploy run pipelines for some team's snowflake needs, since once you put a feature in, you have to support it forever. So one suggestion is that you look really closely at your own service and ask: can you change that to fit the framework? The majority of times an infra eng gets a request that amounts to "we can't use the framework until it does X", the answer is actually, "you should not want to do X, for reasons Y".
This might not be your specific issue, but if you want the thing soon, work on the parts of the codebase you do have control over.
And in general, yes. This is how big companies tend to work. Teams plan out effort far in advance. I have an ask to a sister team right now for 2022 planning, and I would be delighted if they came back and said "Q1". There's a million things all going on at once.
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.
Consider it mission accomplished, startup acquired, check the box, journey over, on to the next one. The market for software developers is on fire right now. You'll have no problem finding a new startup to join, and you'll be instantly relieved.
Those feature request intakes occur because otherwise infra teams become bombarded with multiple requests per day. In isolation they're not much work, but the cumulative requests could take years and truly need prioritization.
Being a recently acquisition, I recommend scheduling time with their manager to talk directly about your situation and trying to get on as part of their primary priorities. If that doesn't work, then your manager should be doing a better job getting other teams to be ready to support you.
Being a recently acquisition, I recommend scheduling time with their manager to talk directly about your situation and trying to get on as part of their primary priorities. If that doesn't work, then your manager should be doing a better job getting other teams to be ready to support you.
Not what you asked, but stories like this are why competition is critical to the economy.
All large human systems, government, academia, business, whatever, converge to this. Everybody's comfortable, nobody's working too hard, sure, we'll get to it in a couple months...maybe. The paychecks will keep on coming, we can all go home at 5, everything's great.
Then, all of a sudden, some small startup "cuts corners", doesn't fill out the paperwork, kind of ignores all this "compliance" a bit, and somehow...out-executes you with 1/10th the staff, at half the price.
The immediate reaction is always disbelief, and rationalization. "They don't have feature X". "They aren't PCI-DSS compliant." Yet somehow, the customers are lining up and can't get enough. Someone figured out precisely what mattered and what didn't (what people were willing to pay for), and delivered it.
Single-payer healthcare, the DMV, and private equity-created monopolies are what happens when there's no competition. There lies the world of consistently higher prices, "waiting rooms", we can't do that because "it's never been done that way before", etc.
All large human systems, government, academia, business, whatever, converge to this. Everybody's comfortable, nobody's working too hard, sure, we'll get to it in a couple months...maybe. The paychecks will keep on coming, we can all go home at 5, everything's great.
Then, all of a sudden, some small startup "cuts corners", doesn't fill out the paperwork, kind of ignores all this "compliance" a bit, and somehow...out-executes you with 1/10th the staff, at half the price.
The immediate reaction is always disbelief, and rationalization. "They don't have feature X". "They aren't PCI-DSS compliant." Yet somehow, the customers are lining up and can't get enough. Someone figured out precisely what mattered and what didn't (what people were willing to pay for), and delivered it.
Single-payer healthcare, the DMV, and private equity-created monopolies are what happens when there's no competition. There lies the world of consistently higher prices, "waiting rooms", we can't do that because "it's never been done that way before", etc.
This is pretty typical example of culture change when moving from a small organisation to a large one. The thing that makes this sort of culture change so emotionally challenging is that involves a fairly dramatic change in values. This can lead to a lot of feelings of underappreciation and frustration, which can be overcome only by recognizing that values are not immutable and universal, but are instead highly context dependent.
Massively overgeneralizing of course, we can observe the following tendencies: Small organizations tend to value people who are highly responsive and who can work independently in a fairly unstructured and unconstrained operating environment. They tend to value people who can do "whatever is technically necessary" to rapidly solve problems and move the business forward towards it's goals.
As organizations grow, such forward progress is easily stymied and halted by interruptions and context switches from colleagues, and velocity becomes largely a function of how much such "frictions" can be reduced or eliminated. Behaviours and traits which were highly valued and rewarded in a small-organization context (e.g. highly independent problem solving and proactivity) can, under many circumstances, become liabilities in large organizations if they interfere with the smooth running of established processes, or cause disruption and confusion to large numbers of people. Reliability (and above all predictability) become far more important than responsiveness or (sometimes) raw velocity.
Needless to say, being able to adapt behaviours and attitudes depending on context is an exceedingly useful skill, and just because you were rewarded for acting in a particular way in a small organization does not mean that you will continue to be rewarded for acting in a particular way in a big organization. The two are completely different beasts, and it's the communications structure that drives the shift in values.
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.
In my experience, it helps a lot to imagine the motivations behind each process in an uncynical light. Everyone is trying to solve their own problems, which aren't necessarily the same as your problems or the organization's as a whole. You went from an environment where whatever you were working on was a huge part of the overall organization to another environment where, proportionately, it simply isn't as important. If your startup had kept going, it would've ended up looking very similar as it got bigger.
Large companies are just startups that've learned more hard lessons. Every one of those processes were put in place in order to protect something or someone from the harms of doing what you're doing. They didn't emerge from nothing. You don't have to like it, but I encourge you to respect it.
Assuming every coworker who doesn't do what you want is an irrational idiot acting in bad faith seems like a shortsighted and unpleasant way to go about your career. Stick around long enough and you'll most likely find out why what looks like red tape is actually holding everything together.
I'm probably not going to add a whole lot more than what's already been written here, but pragmatically; if the deploy tooling isn't compatible with your app, and that tooling needs to support other apps as well, why not make changes at your end? It's a simple task right? Is it somehow enormously complex at your end?
What you should do, is realise you are no longer alone. You're not a small team at the fore-front anymore, you're part of a whole company of teams now and like it or not, these teams, whatever divisions they fall under and the company as a whole have deadlines and budgets. Someone looked at your request and plotted time. Does that not work? Find another solution. Don't complain about how its a small feature and you could fix it yourself easily, it isn't and you won't. Instead of arguing, being shocked and complaining about how insane it is, take a step back, talk to these people and try to understand how and why this company works the way it does. If after that it still doesn't work for you, you can always leave, but I'd honestly suggest you try to find a few people who can guide you around a bit instead of acting like the mistreated outsider, the only one who suffers there is you.
What you 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.
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.
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.
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.
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.
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.
In the end, it took them an entire week to fix it, and since none of it was my fault, of course I got paid. No one seemed to really mind that a week's worth of senior engineer salary was just gone. Except for me, I guess - I like coding and building stuff and fixing bugs and making things work.
I prefer startups, although I'd love to find a small stable company - one that's doing well but growing a bit at a time via revenue. Those are some of the best places I've worked.
This is not uncommon. Two things come to mind that might help:
1) Decide if you really care if this migration is on hold for several months. Your stuff presumably works fine still, right? If so, why do you care that the migration is delayed? Really take time to think it through. In the meantime, just report the delay back to whoever told you to do the migration and, if they have a problem with it, they can go fight battles for you while you do something else.
2) Recognize that $LARGE_CORP values != startup values. This can be really hard - you likely came from an environment in which getting things done quickly, efficiently, and sometimes really creatively, was highly valued, almost above all else. Those are good things, but now you are in an environment in which things like stability and predictability are possibly even more important, and a plodding, "inefficient" bureaucracy can actually work in favor of those values.
I found the above helpful while I endured a commitment to stay for a certain amount of time after the acquisition, but ultimately I missed the startup environment and returned as soon as I could. :)
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.
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.
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.
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.
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.
Small company, very fast paced, learned new tech very quickly for two years and actually pumped out awesome products (in addition to other small company perks).
After the acquisition, the way we worked completely changed for the worse. I ended up leaving and so did about 50% of the developers.
Promotions became much more difficult to achieve, raises were below or only matched inflation, and pretty much every aspect of work became more bureaucratic. This was exactly why I had left my previous company, and I ended up leaving this one as well after giving it a shot. Stagnating my career was not worth it especially in a hot job market.
I’ve been there before.
It’s all going to come down to your manager. You shouldn’t be out there fighting for resources from other teams and arguing their relative priority. Your manager needs to be working within the new company to establish priorities and get the appropriate time, money, headcount, and resources in place to make these things happen. The platform team won’t automatically know your situation and it’s not really your place to drive it. Get your manager involved.
However, you have to watch closely to see how your management chain is handling the acquisition the great energy and enthusiasm they had for the startup might be completely gone now that they’ve been acquired. If they’re only sticking around long enough to cash in their earn-out provision, they may be completely uninterested in helping out. If this is the case, you probably aren’t going to get any happier in your current role.
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.
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.
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.
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?