321–330 of 464 posts
The whole structure of big corporation is structured in this way. Different apartments have different interests in concern. If you could align, fine. If you can't, then it sucks.
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…
Some hypothetical examples: What happens when there are more than four engineering teams? What changes when dedicated scrum masters are introduced and begin arguing about whether work belongs in sprint 133 or sprint 134 while walking past your cubicle? How do enterprise contracts for PaaS providers work? And, at my current employer, what happens when more than 100 engineers' work is shelved for holiday "frosts" and "freezes?"
Afterwards, you'll have more interesting conversations with the bright-eyed 23-year-olds working with you at The Next Startup. Instead of "I feel like this is a bad idea," or--heaven forbid--"Because I said so," you can confidently state "Company X tried Y. Z was the tragic result. How can we implement Y, but avoid Z?" It's one thing to have head knowledge of why frequent releases are beneficial, but watching what happens the moment a code freeze is lifted and hundreds of commits hit production? That's priceless.
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. :)
Earlier quoted context omitted.
There is a large gradient between 'fucking around in production' and crippling big corporate process. Maybe the big tech companies all have the perfect amount of process, but much of the process and ceremony at other big companies I've seen is simply in place to keep the lowest common developer employed. Heck, people complain about excessive process on this very site all the time. On other nitpick is that startups li…
> On other nitpick is that startups live and die with automation by their lean nature. They have fewer resources and must automate everything they can. It's built into startups mindset. I am at a medium sized company. We acquired a startup. They did not "live and die with automation", instead they contracted out the production operations. A dozen customers, all on snowflake systems which were constantly tweaked direc…
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.
> 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 t…
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.
Earlier quoted context omitted.
Direct link https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s... for everyone else having a hard time figuring out how to find the actual comment. Really worth a read and absolutely puts OPs story into perspective.
Yeah that story is total bullshit. It's someone's fantasy. The equivalent of me telling the story of my epic comeback in the Superbowl.
This is not about culture or change or Big Corp vs startup. You are on your own working for a company where no one has a vested interest in your career or happiness.
Leave. Leave now. Start interviews on company time and get out. Leave and do not look back.
> 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 t…
Agree and to elaborate : the companies will have radically different speeds goals processes priorities methods and cultures. Bluntly, you can be shocked and incredulous, or you can attempt to understand empathize learn and adapt. Approaching the engineer and being surprised they shunt you to the manager for example - I sense that you are genuinely surprised. Fair enough. But from their perspective - it's a big compan…
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.