Ask HN: Startup acquired by a large company and it sucks. What to do?
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?
463 comments
[ 3.0 ms ] story [ 340 ms ] threadPretty much. Hearing about a large company that moves at any appreciable velocity is the exception, not the rule.
> What should I do?
If you have stock, it's probably worth it. But maybe not -- you're the only one who can decide. What do you value more, money or happiness?
Put all these grievances to paper, have every worker sign it, and submit it to every member of the board of directors.
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?
If your retention compensation is good, try to learn to accept it and just keep getting things done, even though it takes longer and you can't get as many things done, until the retention runs out or you can't take it anymore or whatever. If the compensation isn't good, then it's time to look for something else.
One of my coworkers left rather than be part of an acquired team. He had been acquired before and wasn't willing to deal with it again.
No, you don’t have to stay, that part is optional. Lots of startups are hiring.
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.
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.
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!
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.
You're welcome.
> So I reach out to the manager and ask what is going on. This is a simple task, I said. Why does it take an entire quarter for your team to deliver? He doesn't have an answer.
This was probably career ending at your company, I expect you have been added to a layoff shortlist somewhere for the next round of downsizing.
Go find something else sooner rather than later.
Uh? I think it’s pretty random to say that kind of stuff without knowing anything about the new company. I can’t see any decent company firing newly acquired employees because they want to move fast…
Works both ways, right?
Probably the key negative was:
> This is a simple task
Is it? OP has no idea about the software it's being integrated into, and while it may _seem_ like a simple task in principle, it may not be, and it's a judgement on the work that's on another team to deal with. Quite easy to fall into a trap of trivializing work that you yourself aren't responsible for.
Also,
> he doesn't have an answer
You sure? Literally speechless?
Right! May be the team/manager he was talking to - had no capacity left for the current quarter. There could be dependencies on other teams that might require some planning etc
O man! I believe OP has a lot of insight into corporate dynamics. It exactly happened to a friend of mine. Those corporate seasonal managers does not like to be questioned or give any input. A friend of mine did something similar, and guess what - he was laid off after few weeks; very shortly after starting at a mega corp $
It’s almost as if layoffs are common after acquisitions and correlation is not causation.
Almost certainly not. This requires actual malice on the part of the manager in question. The manager in question doesn’t have any direct authority over OP (unless OP is really bad at storytelling) so would have to go way out of their way to hurt OPs career. Much more likely, the manager doesn’t care about OP at all, because why would they?
But yeah, unless OP is waiting on piles of stock to vest, move on. But because they are unhappy, not because of this random manager.
Yup, for a large portion of them.
What should I do?
Quit.
And pat yourself on the back for finally getting a chance to learn, up-close and first-hand, what this industry is actually like.
Sounds like it's time to jump ship and find something new.
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.
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 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.
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?
Maybe your example is a little more extreme than my experience, but yeah, pretty much how it works.
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.
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.
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.
If you think the military isn't a large government bureaucracy with mountains of paper work, I recommend you talk to a veteran.
If there is a lesson here it might be that companies quickly lose focus and try to do too many things. Then there are giant queues of things to do and important things are held up by unimportant things. Your thing might be important, but it also might be a problem holding back more important things.
Let's assume for a minute the poster has joined google. Do you want some random person changing code in a system used to deploy applications? No. That same code deploys Google Search. That thing pumps out over $50 bill a qtr of high margin revenue.
The process described could be at Google, Microsoft, Facebook, Amazon, Netflix, Apple. These are Fortune 500 companies and while they will die eventually, it isn't going to be in any time soon and it isn't going to be because the team working on internal infra doesn't move fast enough.
Give birth and do not possess-Tao Te Ching, 10
It's not that this thread advices to shrug it off. They try to explain why some things can't go faster that easily and what seems cloggy and stupid can still be an effective machine at scale.
No you cannot, because your starting premise is flawed. One organization has demonstrated its value over time - quite possibly inter-generationally - and the other has not proven its certainty in returning income. And what created that value in time? The people. With startups, it could be the idea.
>It's not that this thread advices to shrug it off. They try to explain why some things can't go faster that easily and what seems cloggy and stupid can still be an effective machine at scale.
My point is it looks effective, but the S&P 500 historically demonstrates bureaucracies asphyxiate. I'm simply pointing that out to people in this thread who likely participate in the miscarriage of organizational competency.
You might assume it's increased bureaucracy or lack of organizational competency but there isn't compelling evidence, I don't buy it, and good investors like Warren Buffett don't buy it. Talk to anyone who worked at a big successful newspaper in the 80s and anyone who worked (or works) at Coke (or Pepsi). Both will give you horror stories about bureaucracy. The newspaper industry is dead, and Coke keeps printing money (Pepsi too). Why?
I recognize it takes four years for McDonalds to add a new product to their global supply chain. That is a symptom of scale which the administration therein attempts to streamline. In the likes of $KO, I would wager there is less complexity in the internal administration of manufacturing a beverage which has not changed in recipe in a century, and which takes nearly the same amount of time to launch diet coke. The good manufacturing practices, in other words, have not changed nor do they need to as KO continues to grow in market share globally for beverages.
Meanwhile, business computing has simply exploded since 2010 yet IBM's revenue has shrunk ~30%. Are you to suggest it is not the personnel that are responsible for its tepid business development in response to a market which moves fast and breaks things? That maybe the preservation of the internal cohesiveness of the organization as intrinsically valuable kills companies in the presence of new market environments which the organization is motivated to be responsive at the risk of termination? I advise reading The Innovator's Dilemma to corroborate my assumption.
I think you've answered your own question with the examples you gave.
Alive companies: Environment hasn't changed much.
Dead/hobbled companies: Significant change in the environment around creating the product/service or distributing the product/service (or a substitute) which upended the competitive dynamic. 100s of companies try to take advantage of the new dynamic and the existing companies might win, but are just another 1 in the 100's who are vying to win the new game.
Point is there is much more at play why fortune 500 companies and startups die. You cannot put that to bureaucracy (alone), especially not from the distance we are discussing it here.
> Is this how military's organize themselves
The world's largest superpower just ended a 20 year engagement, so...
US basic training was also the origin of the phrase "hurry up and wait."
No, the honest recommendation was based on the included explanation of why it can't take days.
Corporate BS is quite enough to turn one into a cynic within a year. Its the daily lying and gaslighting I think.
I have an allergy to the environment.
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.
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.
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.)
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.
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.
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.
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.
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.)
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 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.
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.
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.
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.
If there is a compliance issue with someone looking at source, then either (a) their source control is misconfigured, (b) their source control is being misused, or (c) they have no policy to guarantee appropriate use and detect improper use.
Any organization that uses compliance as an excuse for opaqueness, creating silos, and guarding projects like treasure is toxic, especially if people there are so institutionalized that they think that's a valid reason, and OP should begin looking for another job ASAP.
(Said having worked at both companies with global read visibility & access scoped to team only)
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.
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.
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.
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.
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.
Personally, I think we all win if the people who want to move fast are in situations where they can move fast.
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.
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.
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?
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.
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".
It's called 'reserve capacity', and some people think it is helpful
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".
* 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.
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'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.
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.
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!
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.
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).
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.
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.
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.
Even after that they get comments like OP "This is a simple change, why will it take a week?", "I can just finish this in few hours and submit a patch". I guess it takes a while for people to learn that writing code is only 5% of the effort, the rest of it is review, testing, QA, E2E, compliance and what not. There sometimes is unnecessary bureaucracy as well, but that doesn't mean that the actual engineering processes are useless.
The problem is that "learning the ropes" in a big org is often just an interminable slog of suffering from lack of information, dead-end rabbit-holes, and dealing with assholes. One is often forced to choose between being a doormat or being offensively aggressive with little ground in between.
In the context of an acquisition, especially, staff on both sides will be in fear of losing their jobs, status, or comfort-zone. There will automatically be barriers put up against change whether folks are conscious of it or not.
The OP just needs to talk to a human being.
It's his responsibility to reach out and find one. In my experience, the thing about big-company process is that YOU HAVE TO go around it to communicate. You have to talk things out with the RIGHT people in advance, come up with a plan in cooperation with them, have them collaborate by getting things warmed up on their side. After all that the stupid meetings and "approvals" are just formalities. In fact, you can tell when this is the case when project decisions are handled with almost parliamentary procedures. There's no room for discussion and thinking things through in such meetings-- everything, EVERYTHING, has to be worked out in advance through side-channels.
You didn't mention retention bonuses, so: start looking for another job. Your old job is gone.
Past a certain point there are no "simple code changes" anymore. Automation and functional QA needs to ensure zero regressions, internal and external docs need to be considered, it all needs to be bundled in with many other code changes (feature and fixes), etc. There is no shortcut. Even FB had to dial back their "break shit in prod" mantra.
Of course startup devs hate this, real men fuck around in production, which is great. Running and maintaining a large code base is very grown up sport, more like running a country than building a house. For those on the other side, who inherit startup code and have to fold it in ... the hatred is mutual.
We need to stop calling things "grown up" when what we mean is that they take a different set of skills. It's childish, and I think it's been causing harm in our industry.
A recent startup I was involved with hired a senior manager from the “grown up” end of town and he is in the process of comprehensively destroying the business because the rules and processes are more important to him than shipping product. He literally has no idea what he is doing, and it’s entirely because he doesn’t have the skill set necessary to bootstrap a company.
There is a stark difference between the mindset and skills required to start from zero versus those required to defend billions in revenue, and it has nothing to do with being “grown up”.
“Tell me you never bootstrapped a startup, without telling me”.
There are large code bases in production that are productive: Everything that is open source - and still the process isn't as shit as op describes.
So this has to do with corporate hierarchies and not the quality of the code.
Yes there are but these are not without rules. Try to add a new feature to a large open source project as a new contributor. That has probably as much chance of succeeding as doing this in an enterprise.
There is a reason larger OSS projects have the "good first contribution" section. These are small bug fixes where the work is already spelled out typically. You do these to get familiar with the codebase and learn how to make a valuable contribution the size of a feature.
Your post does a good job of that.
I agree with the sentiment. Being an "adult" is about restrictions, limits, boundaries, and confines; you can't just willy-nilly do whatever you feel like. You must now realize and accept that we all bend the knee to something. We are not immortal gods, free from all consequence, but merely ants allowed to live by the systems we inhabit.
Perhaps the most authentic post I've seen on this entire site in a long time.
It's not.
The other way is to deploy frequently, accept some amount of bugginess, and build your systems to deal with it appropriately.
Running and maintaining a large code base is not the huge technical challenge it once was, but unfortunately the relics of the past remain, and force everyone to do things their way, lest their hard-won knowledge becomes obsolete.
There's a big differece between committing small changes to an existing service or infrastructure base frequently, and conversely a PR or feature request from left field from a recent acquire.
On other nitpick is that startups live and die with automation by their lean nature. They have fewer resources and must automate everything they can. It's built into startups mindset.
It isn't about keeping the lowest common developer employed, it is about keeping the lowest common developer from bricking the entire system. Unless of course you can tell me where to find enough developers of your skill level to write all the code required to run a modern society.
that's $20K/minute
chances are, $shiny_acquisition isn't making $20K/minute, and woe is the helpful IT responder who kills the golden goose. it'd be crazy if anyone can do that, so many layers of bureaucracy & compliance have evolved to prevent that.
The solution is generally (a) do work not involving production (b) work where production isn't like that, which is generally smaller companies or a surprisingly small number of ~tech companies. Digital Transformation (cloud, PaaS, ...) often involves trying to enable self-serve at enterprise-scale, but I generally still see roadblocks when GPUs, TLS, DNS, SaaS, etc, get involved.
I am at a medium sized company. We acquired a startup. They did not "live and die with automation", instead they contracted out the production operations. A dozen customers, all on snowflake systems which were constantly tweaked directly in prod with no documentation or audit process.
My experience on the acquirer side is that startup engineers like to just build stuff and deploy it. Design? Testing? Documentation? Automation? None of that existed in this company in any fashion. And they are themselves grating against a modicum of process. Please explain what you want to do, why, and provide a high level design. You are going to replace the whole auth system, it's not something you just "figure out" as you go along... Sigh.
This has been my experience exactly. Automation has a high upfront cost where that payoff is in the long term. As a startup the priority is on income now. Not cost saving that pays off over the next year.
Context is important also, a lot of young companies are still trying to figure out their optimal business model, so agility really is more important; adapt or die (kind of).
Lastly, you have to consider why anyone would ever work for a startup; they often pay less, more stress, less security, unpredictable environment, etc... but you get to do ridiculous experiments in production and try to build something cool. It's part of the incentive structure.
I've directly seen this at all sizes of companies. I worked at a billion+ revenue company and watched my boss edit stored procedures directly on production (for way more than a dozen customers). I ended up encrypting them in prod to force him through the build process I made.
The point is that there is wild west going on everywhere, and the size of the company is only one factor. There are startups with great engineering and big companies with terrible engineering. It's just the state of software right now.
Yeah, I was wondering what this might sound like to the other side, perhaps something like:
"Yeah, hi, I just got here last week, I'm here to inject innovation into your life. So your battle tested deployment pipelines that deploy all the code that pays both of our paychecks (because my stuff is pre-revenue, naturally), they don't support the idiosyncratic workflow I literally made up myself. Can you drop everything and jump on this instead?"