[HN Gopher] Ask HN: Startup acquired by a large company and it s...
___________________________________________________________________
Ask HN: Startup acquired by a large company and it sucks. What to
do?
I work at a startup with ~50 employees (and have always worked at
startups). Love the work and the people. Recently we were acquired
by $LARGE_CORPORATION and the experience has been a living hell for
all of us. Things that should take a few days take a few weeks.
Things that should take a few weeks take a few quarters. It's
slowly driving me insane. The experience is best shared as a
story. I'm working on migrating our apps to the parent company's
VM launching and deploy platform. Should be fairly straightforward,
I think. Unfortunately, the deploy tooling isn't entirely
compatible with our app so I ask the team if they can implement $X
feature to support our app. The first engineer I talk to doesn't
even attempt to answer my question but redirects me to their
manager. Ok, that's odd, I think, but whatever. Manager says sure,
just fill out this feature request doc. It's a Google Docs template
with 4 (!) pages of required documentation to just explain why I
want this feature implemented. It asks for my team name, the
motivation, why I can't solve the problem some other way, yada
yada...ok, I guess it's good to document your work, so sure. I fill
it out and submit it. No response after two days. Then I get an
automated email that their _skip_ level manager has approved the
work. Huh? This is followed by an email that the team 's eng
manager approved the work. Why do two layers of management need to
approve work on something they have no knowledge about? Finally,
after many rounds of arguing about why this needs to be done in the
first place (ahem: you told us to migrate to your platform, and it
literally does not work for our app), they quote us a delivery
timeline of _end of Q1 in 2022_. At this point I am in absolute
shock. This should take no more than a few days to implement. So I
reach out to the manager and ask what is going on. This is a simple
task, I said. Why does it take an entire quarter for your team to
deliver? He doesn't have an answer. I tell him I'm happy to fix
the issue myself, if they link me to the relevant codebase. "It
shouldn't be too hard to dig in and submit a patch," I think to
myself. He says he cannot give me access to the codebase for
compliance reasons, and that only members of his team have R/W on
that repo. What??? This is insane. And this entire time I was only
alllowed to interact with managers and have not spoken to a single
engineer about the actual technical details. It is impossible to
get anything _done_ here now. Is this how it's like at all large
companies? What should I do?
Author : lopkeny12ko
Score : 141 points
Date : 2021-12-21 17:13 UTC (5 hours ago)
| icedchai wrote:
| This is normal. You need to fill out all that stuff because the
| other team has a huge backlog of work. They could probably do it
| in a couple of days if they had _nothing else to do._
|
| Absolute shock? Q1/2022 isn't that far away in "big company"
| terms. It's probably easier to keep running your app the way
| you're doing now anyway, so what's the big deal?
|
| Don't worry about it and move on.
| itoocode wrote:
| Yes, large companies work this way. I think you are person who
| does not want to waste your time for the sake of slow process.
| Staying longer will make you feel less confident of yourself. If
| it was me I would look for another fast paced startup or medium
| sized company.
| madrox wrote:
| 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.
| can16358p wrote:
| If you have options, I'd suggest to move to another startup that
| fits your style.
|
| Sad but true: that company will only kill your startup culture in
| the favor of their boring enterprise corporate model, and you
| (rightfully) don't want that.
| vgeek wrote:
| The middle managers need to manage their serfdoms and prove their
| value. It seems like the less value someone actually adds, the
| more territorial they are-- typically blaming arbitrary
| "established processes" or something of the same nature. For non-
| tech companies it seems like burecracy starts to become an issue
| at like $500mm/yr. Any academia or government org will be the
| same. You can't really fight the system and win, so it is easiest
| to just find another job.
| ghostbrainalpha wrote:
| You should send this write up directly to the CEO.
|
| You can either quit because working a big company can suck, or
| you can get moved up the chain of command if you are the type of
| person who actually cares about this problem and wants to fix it.
| mfrye0 wrote:
| Yes, this is how a lot of large companies work - I've worked at
| several like that.
|
| As far as what to do, it depends on your comp. If you're still
| vesting, mentally check out and rest/vest until you make enough
| to feel comfortable. Depending on the company, it's pretty easy
| to get by doing nothing, and/or you can work on your own stuff on
| the side.
|
| If you're not vesting anymore, the vesting amount is not worth
| it, or you prefer to move faster / do something, quit and get
| out.
|
| Alternatively if you want to stay, a large company is a different
| game. Again depending on the company, but it's more about image,
| strategy, politics, and non technical sort of work.
| theshrike79 wrote:
| > 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.
| Clubber wrote:
| Just leave, seriously. I spent way too much time in the same
| situation waiting for things to get better and they never did. I
| did this twice; once for 6 years and one for 2. It won't get
| better, but it will make you worse at your craft. The only regret
| I had was I should have done it sooner.
| Raed667 wrote:
| Reminds me of a multinational where I had to "purchase"
| infrastructure from the team in the next workspace to deploy our
| new application. Literally all the paperwork and requirement
| gathering you'd expect from getting external providers/contracts,
| run through an internal system with all sorts of forms and people
| being brought "in the loop", yet the infra team was literally a
| few desks over... '
| flemhans wrote:
| Sounds like you could be getting the blues from working
| there...
| ameliaibwne wrote:
| Not feeling great after an acquisition isn't uncommon! These
| articles might help
|
| Examples of things going wrong after acquisition:
| https://sifted.eu/articles/gopuff-dija-acquisition-dilemma/
|
| What staff actually need during mergers and acquisitions:
| https://sifted.eu/articles/employees-mergers-acquisitions/
| rexreed wrote:
| Why are you shilling articles for sifted.eu? Every comment is a
| pointer to an article on sifted.eu. @dang is this normal user
| behavior?
| [deleted]
| davidw wrote:
| 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.
| theshrike79 wrote:
| Mid-size companies are where it's at.
|
| The huge ones (1k+ employees) are way too big and unwieldy and
| you'll get lost in the bureaucracy and get fed up with all the
| people promoted based on the Peter Principle. Good stuff if you
| want a peaceful-ish place to work at, maybe you have small kids
| at home and just want to work 9-5 and bring zero work home.
|
| In small ones (dozens) you tend to become the smartest person
| in the room too quickly, you also usually need to be a jack of
| all trades and have very little advancement options. On the
| other hand you can do all the cool stuff and break stuff =)
| Work-life balance usually doesn't exist.
|
| Mid size corps (hundreds of employees, but way under 1k) are
| the sweet spot in my opinion. Large enough to have some
| structure, small enough to not have too much red tape if you
| need to get stuff done. You can also do lateral moves easier,
| change specialties or maybe even get some team leading
| experience.
| patrakov wrote:
| No, this is not how large companies work. That's how over-
| regulated companies work, no matter the size.
| james_s_tayler wrote:
| https://komoroske.com/slime-mold/
|
| You're welcome.
| fileeditview wrote:
| 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.
| achillesheels wrote:
| So the honest recommendation is to accept it takes >1 month to
| get something done in an orderly fashion when it can take days?
| Is this how military's organize themselves, or do they just get
| shi*t done?
| jonathankoren wrote:
| >Is this how military's organize themselves, or do they just
| get shi*t done?
|
| If you think the military isn't a large government
| bureaucracy with mountains of paper work, I recommend you
| talk to a veteran.
| zarkov99 wrote:
| It depends. Special Forces team typically cut through a lot
| of that bullshit. Perhaps there in lies the answer. If you
| want the resources of a large organization and the freedom
| of a startup you need to look for the smaller elite teams
| within the org.
| jacobr1 wrote:
| Often called the "Tiger team" in the lingo of corporate
| jargon.
| danielmarkbruce wrote:
| The explanation given above is that you aren't the priority
| you used to be.. it doesn't take a month to get something
| done, it takes a month to do all the things in the queue in
| front of you.
|
| 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.
| achillesheels wrote:
| The judgment, however, is that while one is not the same
| priority any longer, one's priorities are necessarily
| devalued, due to the a competition for resources, namely,
| time. I see the common explanation here is to just shrug at
| the state of affairs. Is this the best management can do? I
| can see why Fortune 500 companies die now.
| danielmarkbruce wrote:
| When you say "is this the best management can do", I
| believe you are thinking about it in the wrong terms.
| It's a trade off. Almost all these decisions are trade
| offs and there isn't a strictly better option available.
| I read most of the explanations here pointing to that
| trade off and understanding it.
|
| 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.
| bastijn wrote:
| I see a lot of startups dying, much more than fortune 500
| companies. Can I now conclude not having processes kills
| companies faster?
|
| 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.
| korijn wrote:
| Let's see you solve 50 tickets each worth a couple days in a
| couple days.
| achillesheels wrote:
| yibg wrote:
| Why do you assume the code isn't clean? Maybe if the code
| wasn't clean it'd take a couple of weeks instead of a
| couple of days to implement.
| dqpb wrote:
| Just leave, everybody's hiring right now.
| swader999 wrote:
| If you can't change your Company, change your Company.
| danabrams wrote:
| I'm a consultant. This is my experience at most large companies,
| at least in legacy industries.
|
| Different large companies have different cultures, which mostly
| is about how much the employees like each other. But they're all
| giant, kafkaesque bureaucracies that our government red tape to
| shame, in my experience.
| shiohime wrote:
| I worked at a startup that was acquired by a larger corporation.
| This echoes my experience as well, everything became so clogged
| up with processes, documentation, responsibilities so distributed
| that there were times it became unclear who was responsible for
| what. I had a bunch of arguments with other departments and upper
| management over processes that were directly impacting my team of
| engineers, but eventually just caved in. Meeting glut, passing of
| responsibilities, nobody stepping up to get stuff done, and a
| bunch of other things that made me unhappy. They at least treated
| me well enough all things considered and I had multiple
| promotions, but eventually I got so burnt out I just left.
|
| I don't think it's necessarily like this at all large companies.
| I had worked at a much, much, much larger company before and
| never had to deal with anything like that. It really comes down
| to the company that acquires the smaller one.
|
| I mean look at Blizzard, who inevitably just became Activision
| despite years of claiming they would not. The process / culture
| of the company that acquires the smaller one almost inevitably
| wins out.
|
| You have to realize that the company you worked for no longer
| exists. It was acquired and is something else entirely. If you're
| unhappy, I would suggest to consider looking around for different
| opportunities.
| sli wrote:
| I worked at a startup with three employees (and _six_ C-levels
| that were too busy suing former clients to sell the current
| product) that tried to start acting corporate at that scale. It
| was an atrocious experience and I 'm glad I left.
|
| Sounds like it's time to jump ship and find something new.
| vanusa wrote:
| _Is this how it 's like at all large companies?_
|
| Yup, for a large portion of them.
|
| _What should I do?_
|
| Quit.
|
| And pat yourself on the back for finally getting a chance to
| learn, up-close and first-hand, what this industry is actually
| like.
| sli wrote:
| Stuff like this is why I'm trying to get out of the industry
| and just write games by myself or with 1-2 other people. It's
| such a complete... well, ball-drag working in this environment,
| and I'm so burnt out on the fast movement of startups despite
| having enjoyed it previously.
| vanusa wrote:
| Yeah it's why I intentionally take long breaks now and then
| (f your recruiter and his complaint about "work gaps") just
| to learn how to be human and creative again.
| nightpool wrote:
| A lot of people have talked about the issues with this post, but
| I wanted to call out one specific thing: The
| first engineer I talk to doesn't even attempt to answer my
| question but redirects me to their manager. Ok, that's odd, I
| think, but whatever.
|
| This is definitely not odd. The whole _point_ of managers is that
| they 're there to protect their engineers from getting off track
| with every random request that comes up. I understand that it may
| feel bureaucratic, but as an engineer, someone who insists on
| talking to me directly without going through my manager is always
| going to mark themselves as someone who doesn't respect my time
| and doesn't understand that they're not the center of my
| universe.
|
| This feels like a rant that comes from someone who doesn't have a
| lot of experience deploying and maintaining complex systems over
| long periods of time--or at least someone who isn't willing to
| put themselves in the shoes of the other team and understand
| their concerns. 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.
| mavelikara wrote:
| > This feels like a rant that comes from someone who doesn't
| have a lot of experience deploying and maintaining complex
| systems over long periods of time.
|
| Agree. Also:
|
| > Finally, after many rounds of arguing about why this needs to
| be done in the first place (ahem: you told us to migrate to
| your platform, and it literally does not work for our app)
|
| If migrating the app to the new platform is a priority, why not
| escalate up the startup's leadership chain to get it
| prioritized higher in the infrastructure team's roadmap? Looks
| like the startup was poorly run, with no clear escalation
| paths, and employees unaware that such mechanisms exist in
| companies (and find it odd when they notice another engineer do
| it).
| nightpool wrote:
| Honestly, I kind of regret the sentence that you quoted.
| Whether the OP is correct about the complexity of the change
| or whether the deploy team is right to be protective over it
| is is really missing the point--the point is that the OP
| needs to have more humility and understanding for the
| perspective of the other team when navigating these
| processes.
| guynamedloren wrote:
| You raise a fair point here - good managers protect their
| employees' time, however in this case, the the task was not a
| "personal task" but rather an initiative handed down from the
| parent company, without giving OP the proper resources and
| guidance to complete the task.
|
| If that's the case (and having found myself in that position
| many times, it likely is), this a failing of the parent
| company. I'd expect those managing the integration to assign
| point people, both technical and managerial, to assist with
| OP's task, schedule introduction meetings and communicate
| expectations to both teams. That's not too much to ask. It
| sounds like OP was left to navigate the situation on their own.
| nightpool wrote:
| Based on the description given in the OP, I don't think we
| have enough information to conclude whether the OP was given
| the right amount of resources to complete their task or not.
| While the "migrate to the new deploy infrastructure" might be
| the most important task from the OPs perspective, there's
| nothing there to indicate to me that it's a particularly
| important task from the broader businesses perspective.
| Indeed, I wouldn't be surprised if this expectation was
| already communicated to the engineer by their manager, which
| is why they're here posting about it.
|
| Of course, it's entirely possible that you're right, and if
| this was a more important issue I definitely agree with you
| that it needs to have a dedicated resource assigned from the
| deploy team and it needs to be scheduled into their roadmap
| somehow. Ultimately we're just all speculating based on the
| small details the OP gave us.
|
| However, I think my core point still stands--even if OP is
| right to feel that the deploy team is making the wrong
| decision in general about prioritization, they need to at
| least _consider_ that the deploy team has other, competing
| priorities that they 're juggling, and that the actual change
| might be more complicated in "at scale" (code review, QA,
| interaction with other options, documentation, long-term
| maintenance, etc) then OP is willing to believe.
| usgroup wrote:
| "The Trial" by Kafka.
|
| Corporate BS is quite enough to turn one into a cynic within a
| year. Its the daily lying and gaslighting I think.
|
| I have an allergy to the environment.
| clavicat wrote:
| >a living hell for all of us
|
| Put all these grievances to paper, have every worker sign it, and
| submit it to every member of the board of directors.
| burntoutfire wrote:
| As others have said, they're fully aware - after all, they've
| been working in such places all their working life. It's just
| an accepted way of doing business and plenty of people are
| happy to work in such places (due to almost always being
| blocked by something, you don't have to put in a lot of effort,
| while the pay is often very good).
| dpark wrote:
| What will this accomplish?
| ColinWright wrote:
| Before doing that, make sure you have a new job lined up,
| because your life is likely to be made even worse.
| altdataseller wrote:
| They won't care. Their job isn't to worry about employee
| satisfaction. They're more worried about going public or
| getting acquired.
| pavel_lishin wrote:
| I wonder if the team in question has had an experience like this:
| https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...
| harel wrote:
| Why not move to $ANOTHER_STARTUP? Start fresh. This happens.
| Larger organisations have "larger" processes. Your skills are in
| demand. Just take them elsewhere...
| AtNightWeCode wrote:
| "Is this how it's like at all large companies?" Short answer is
| probably yes. Depending on where you are located, but with large
| corps you may end up with SOX among other things.
|
| Over time all the tools will fine tune to all the new processes
| and the overhead will hopefully be reduced. If there is ambition
| for this.
|
| Also, have in mind that many large security breaches happens when
| large corporations acquisition smaller companies and tries to
| incorporate them too fast.
|
| Do not be too quick to switch job is my general advice.
| Gortal278 wrote:
| I'd suggest you leave and find something else. It doesn't sound
| like you are cut out to handle the corporation structure
| politics.
|
| > So I reach out to the manager and ask what is going on. This is
| a simple task, I said. Why does it take an entire quarter for
| your team to deliver? He doesn't have an answer.
|
| This was probably career ending at your company, I expect you
| have been added to a layoff shortlist somewhere for the next
| round of downsizing.
|
| Go find something else sooner rather than later.
| molyss wrote:
| > This was probably career ending at your company, I expect you
| have been added to a layoff shortlist somewhere for the next
| round of downsizing.
|
| Uh? I think it's pretty random to say that kind of stuff
| without knowing anything about the new company. I can't see any
| decent company firing newly acquired employees because they
| want to move fast...
| andrewjf wrote:
| > I think it's pretty random to say that kind of stuff
| without knowing anything about the new company.
|
| Works both ways, right?
|
| Probably the key negative was:
|
| > This is a simple task
|
| Is it? OP has no idea about the software it's being
| integrated into, and while it may _seem_ like a simple task
| in principle, it may not be, and it's a judgement on the work
| that's on another team to deal with. Quite easy to fall into
| a trap of trivializing work that you yourself aren't
| responsible for.
|
| Also,
|
| > he doesn't have an answer
|
| You sure? Literally speechless?
| mandeepj wrote:
| > Is it? OP has no idea about the software it's being
| integrated into, and while it may _seem_ like a simple task
| in principle, it may not be, and it's a judgement on the
| work that's on another team to deal with. Quite easy to
| fall into a trap of trivializing work that you yourself
| aren't responsible for.
|
| Right! May be the team/manager he was talking to - had no
| capacity left for the current quarter. There could be
| dependencies on other teams that might require some
| planning etc
| mandeepj wrote:
| > This was probably career ending at your company, I expect you
| have been added to a layoff shortlist somewhere for the next
| round of downsizing.
|
| O man! I believe OP has a lot of insight into corporate
| dynamics. It exactly happened to a friend of mine. Those
| corporate seasonal managers does not like to be questioned or
| give any input. A friend of mine did something similar, and
| guess what - he was laid off after few weeks; very shortly
| after starting at a mega corp $
| dpark wrote:
| Not only did they fire him for daring to question a manager,
| they fired a bunch of other people to cover their tracks!
|
| It's almost as if layoffs are common after acquisitions and
| correlation is not causation.
| dpark wrote:
| > _This was probably career ending at your company, I expect
| you have been added to a layoff shortlist somewhere for the
| next round of downsizing._
|
| Almost certainly not. This requires actual malice on the part
| of the manager in question. The manager in question doesn't
| have any direct authority over OP (unless OP is really bad at
| storytelling) so would have to go way out of their way to hurt
| OPs career. Much more likely, the manager doesn't care about OP
| at all, because why would they?
|
| But yeah, unless OP is waiting on piles of stock to vest, move
| on. But because they are unhappy, not because of this random
| manager.
| nerevarthelame wrote:
| 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.
| twblalock wrote:
| > 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.
| fiachamp wrote:
| The amount of people on HN nowadays that are okay with getting
| nothing useful done is striking. Startup guy, you don't have to
| accept being part of a bloated hierarchy that rewards politics
| more than good decision-making. You could check out at the
| corpo job and start prototyping your own startup ideas. Or join
| another early stage startup where your performance matters.
| I'll be starting one soon - let's keep in touch.
| femiagbabiaka wrote:
| if your startup ever makes it to any sort of scale, it will
| likely have the same problems -- they all do :)
| maerF0x0 wrote:
| and you're lucky if you can actually tell what the real
| problems are, because mostly I find people are chasing
| symptoms these days.
| chris11 wrote:
| Yeah, I'm at a startup that's rapidly growing, and is
| adding more process. I don't feel like it's overmanaged, I
| don't generally need to pull in my manager or skip. But I
| can imagine giving a similar response, the major difference
| is that the team I'm on doesn't really have official
| processes set up.
|
| The main problem is that the team has a lot of work to do.
| So simple tasks might take awhile if they aren't high
| priority. If I got significant push back, I'd talk to my
| manager or skip. Because doing it sooner would mean pushing
| back other high priority requests.
| jimjimjim wrote:
| exactly this. once you have paying customers you don't want
| them to grow to hate you and look for an alternative.
|
| So don't break stuff. If you are google or aws then fine do
| what you want. There will always be another customer along
| soon.
|
| but YOU are not google or aws.
| TigeriusKirk wrote:
| Yeah. All the explanations are a waste of words if OP isn't
| happy with the process. The process isn't going to improve.
| If it's not to your taste, bail as soon as your deal is
| complete (might be already).
|
| Personally, I think we all win if the people who want to move
| fast are in situations where they can move fast.
| zarkov99 wrote:
| As someone who just transitioned from a small startup to a
| much larger organization I feel the pain of the OP, and I
| hate it, but I get the feeling that this is typical and maybe
| unavoidable as organizations scale. Is that not your
| experience? Seems like you either have scale or efficiency.
| bcrosby95 wrote:
| It's just different priorities.
|
| Startups are busy trying to build a functional house of
| cards.
|
| Established businesses are trying to keep employees from
| knocking over that functional house of cards.
| tharne wrote:
| > The amount of people on HN nowadays that are okay with
| getting nothing useful done is striking.
|
| You're mistaking the role of a mature company. Unlike a
| startup, in a mature company there are a ton of customers
| relying on your product and making sure you don't f*k up
| their business with a mistake or careless change is much more
| important than building cool new stuff quickly. You don't
| want your bank "moving fast and breaking things". There are a
| whole lot of industries where stability and consistency are
| an order of magnitude more important than fast innovation.
| This may not be as sexy or fun as rapidly prototyping some
| MVP, but it's how a lot of important stuff that runs the
| world works. To this end, a large org may not be everyone's
| cup of tea.
|
| Yes, there will be some waste and bureaucracy at any large
| org, but that's not the same as a place full of people "that
| are okay getting nothing useful done". If anything, it's the
| established boring companies that are doing something useful
| (even if that something is not sexy or exciting), while a lot
| of startups are just burning through someone else's money
| designing things that no one really wants or needs.
| spike021 wrote:
| >Take this as a learning experience: don't assume that you are
| at a startup where people will drop everything to handle a
| request from you right away. Instead, assume that people are
| dealing with a lot of other requests, from a lot of other
| people. Learn how the system works, and learn how to be
| effective within that system.
|
| Somewhat ironically, I just left a FAANG where people
| _constantly_ had this behavior of expecting me (or other
| members of my team) to drop whatever and prioritize their
| request.
|
| I kept mentioning this to my manager as an issue because we
| needed to figure out a way to prevent this, maybe change it,
| etc. But basically it's a "company culture" thing (some people
| might be able to guess which company).
| megablast wrote:
| Surely this huge company with lots of people, where most people
| didn't ask to buy a new company, is doing nothing but sitting
| around waiting for this guy to give them some work??
| achillesheels wrote:
| >Learn how the system works, and learn how to be effective
| within that system.
|
| And what if the system is corrupt? Do you advocate complacency?
|
| > but I also know for sure that new employees who try to bypass
| process and question the priorities of other teams, before they
| learn the ropes and build credibility and trust with other
| people, do not succeed.
|
| And what if the people who do not succeed with such bureaucracy
| are actually better off for not being compliant? What is your
| measure of success? $?
| geofft wrote:
| Literally the point of a job at a for-profit company is to
| make money, yes, primarily for yourself and secondarily for
| the business. This is by no means moral or virtuous. But it
| is _true_ , and because it is true, the people who admit the
| truth of it will be more successful in the sense that they
| will be working with the system, and the people who act as if
| it is somehow untrue and there is some greater virtue behind
| it will be frustrated in the sense that they will never be
| able to work against the system enough to unseat it.
|
| Why did the startup get acquired by the large company in the
| first place? To make money for the shareholders (mostly the
| founders), partly through an exit event, partly through the
| ongoing value of their shares. Sure, they wrote an internal
| email and a blog post about the "next stage of their journey"
| and how the big company "shares their vision" or whatever,
| but that's not the real reason - the reason is money. Why do
| employees get equity? To incentivize them to care about the
| money the company makes, because otherwise they wouldn't care
| sufficiently about the secondary goal of making money for the
| company (i.e., making more money for management, who sets the
| equity policies). Why do employers compete on salary in the
| first place? Because that's what being employed is about -
| making money.
|
| If you want to do good work, to change the world for the
| better, to have fun, or whatever, you have two options. One
| is to secure your place within the system of being successful
| by making money - i.e., to show management that you will make
| _them_ money if they keep you around and keep you happy - and
| then find some room to maneuver within it. There are a lot of
| people who are happy and fulfilled with their jobs because
| they can do this. The other is to leave the system (retire,
| work part-time, join a convent, etc.).
|
| But refusing to admit the rules of the game will work about
| as well as trying to play a game of chess by bowling a ball
| at the pieces and knocking them down. You might say you don't
| care to win, which is fine, but that's hardly the problem -
| everyone involved, including you, will end up upset.
| csdvrx wrote:
| It's both funny and sad you've got to remind that to people
| who post on HN of all places...
| lojack wrote:
| > is probably one request in a long queue of requests that team
| is dealing with
|
| You've explained away the crux of the problem without even
| identifying it as a problem. Queues are an inappropriate
| construct for managing work. If something urgent & important
| takes weeks to even get looked at then there is a
| prioritization problem. If something that isn't urgent or
| important even gets worked on at all then there is a commitment
| problem. Based on what OP has described, the company is likely
| doing a lot of work they shouldn't be doing and working on
| things in the wrong order. Similarly, the work OP is doing may
| be much less important than they think it is.
|
| Now, I agree that it's important to understand how the system
| works, but IMO it's equally as important to understand how it
| can be improved. Long lead times is definitely not a good
| thing, and also not a foregone conclusion at big companies.
| bastijn wrote:
| The queue can be WSJF-t and still be long. Crux of the
| problem is OPs issue might not be as important as OP thinks.
|
| Now if there are too many people waiting on the central team
| and all requests are valid the company should address the
| single point of failure. Grow the central team, train more
| externals to become contributors or agree to have duplication
| to a certain agree. Not everything is worth a platform with
| today's tools and (SaaS) services.
| fknorangesite wrote:
| > If something urgent & important
|
| Who said OP's task was particularly urgent or important?
| Maybe it's getting pushed down the list because they _don 't_
| have a prioritization problem. We don't know - all we have is
| OP's (limited) perspective.
| rpeden wrote:
| That sounds about right.
|
| I'd also note to the OP that in might help to treat the
| acquiring company like the Borg: _they_ acquired _you_ , and
| now it's on you to serve their needs, not necessarily the other
| way around. If your app isn't quite compatible with their
| infrastructure, the right move is probably to modify your app,
| not ask them to modify their infrastructure. That might be
| annoying, but it's probably also the reality of your situation
| for the the time being.
| dpark wrote:
| > _If your app isn 't quite compatible with their
| infrastructure, the right move is probably to modify your
| app, not ask them to modify their infrastructure._
|
| This is my thought as well. The claim is that the fix on the
| infrastructure side should be a few days at most, but also
| that the infrastructure _does not work_ for the app. If it's
| only a few days for an infrastructure change, why is it so
| untenable to modify the app?
|
| As an engineer (and manager) who owns infrastructure
| components, these "little" requests are death by a thousand
| cuts. They typically aren't actually little, but even when
| they are, they forever add additional maintenance cost and
| complexity.
|
| I've seen one deployment infrastructure/hardware management
| team take all of these little requests to make their
| customers happy and the end result was an entire team who
| basically did nothing except service requests from one final
| customer. They made the system fully customized for the one
| use case. I've seen another deployment
| infrastructure/hardware management team essentially refuse
| and tell their customers to fit into the supported model or
| find another solution. They provided a few standard hooks and
| said figure it out.
|
| The former team died when their last customer moved to the
| later solution because it was actually supportable.
| [deleted]
| isbvhodnvemrwvn wrote:
| And with acquisition you are likely a very small fish in a
| big pond, whatever used to be high priority in a company of
| 50 is probably more of a mild annoyance at a company of 5-10k
| people.
| rjzzleep wrote:
| I mean sure there is "some" truth to it. But more likely than
| not the acquiring company has two conflicting priorities:
|
| 1. acquire startups/talent to improve certain things that the
| company is incompetent at
|
| 2. actively block efforts from the startup because a certain
| part of the company actually believes that they are doing
| things better themselves, i.e. ego
|
| I advised a big US car maker on their autonomy and one part of
| the company actually took 8 months to acquire PC's to do
| machine learning with(which then ran into a supply shortage
| further delaying it) and 5 months to upload test data to s3.
| It's not that they weren't working on it. They had meetings
| every week.
|
| You give them too much credit. Of course there is probably also
| that one guy actually implementing in the middle of the 20
| people that just talk who's plate is completely full. But that
| doesn't stop those companies from hiring 20 PMs with their own
| agendas to manage that one guy.
|
| If you really need the money keep working there. If not either
| force change it and get fired or run away.
|
| Someone in Germany called it the 3 A's.
|
| A - Akzeptieren -> accept
|
| A - Aendern -> change
|
| A - Abhauen -> flee
|
| EDIT: in the time I was there half of the team of the acquihire
| they made quit and moved on to better opportunities, because
| the org itself took almost a year just figuring out how to get
| these people to migrate their docs from google docs to office
| 365
| laluser wrote:
| Exactly this. It's not too hard to think about the intake of
| random requests a popular team may receive. Even code reviewing
| a patch from a separate team carries its own set of eyes, which
| is still work for the team. There's a ton of context OP is
| probably not familiar with and walking them through all of that
| baggage is not worth the effort. While this may seem annoying
| from an outside team's perspective, it's the only way to really
| focus on their roadmap and be able to commit to scheduled work.
| harmegido wrote:
| It's pretty interesting to contrast OP's experience with this
| recent /r/bestof that describes in detail why things might be
| the way you're describing:
|
| https://www.reddit.com/r/bestof/comments/rkru22/uloosesignif...
| ascar wrote:
| 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.
| treis wrote:
| 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.
| iKnowKungFoo wrote:
| I can buy the part about putting up fences between
| business people at the tech team. Been there, done that,
| modernized project management. But the "thank you"s,
| bonuses and all that? Complete fantasy. :)
| meigwilym wrote:
| I immediately thought of this as well. Great minds etc.
| vsareto wrote:
| >That team probably set up the onerous Google Docs process to
| gate requests because they get so many!
|
| Also: they're likely understaffed, there's no division of
| responsibility - anyone could get a task for anything - and
| because of this, simply can't handle the volume of requests or
| route the requests to people who already know what's going on
| (and would be able to handle it more efficiently than someone
| with zero knowledge). Infrastructure teams often seem spread
| thin.
|
| Dev teams are lucky that not every other dev team relies on
| them, usually. This reduces communication for that team
| significantly. Every dev team relies on infrastructure, so lots
| of communication overhead for them.
| zebraflask wrote:
| Echoing other comments, your company was acquired. The way
| you're used to doing things sounds like it's quite different
| from how the new owners do things.
|
| I can't make any sort of judgment call on which is or isn't
| "better" based on a brief HN post, but I think it's worth
| keeping in mind that it pays to be adaptable and to scout out
| the post-acquisition lay of the land before you let it affect
| you too much.
|
| You don't want to create an impression of being a "difficult"
| employee "left over" from the acquired company, as unjust or
| unfair as that may seem.
| CogitoCogito wrote:
| > Take this as a learning experience: don't assume that you are
| at a startup where people will drop everything to handle a
| request from you right away.
|
| This doesn't explain why they wouldn't accept the offer of work
| from /u/lopkeny12ko. I've been in the same situation multiple
| times. Sometimes I've been allowed to do the work and sometimes
| not. In the cases where I was allowed to do the work, I
| certainly took longer than they would have taken, but the work
| was complete much earlier (months) than they would have done
| it, the quality was just as high, and the other group didn't
| really have to put effort into it. It was actually a win-win
| for everyone and resulted in products actually shipping on
| time. On the other hand, the organizations that didn't allow
| this were all basically operational disasters. This sort of
| thing was just one red flag of many.
|
| I'd recommend /u/lopkeny12ko to either stop caring and just put
| in minimal effort or find somewhere new to work. It doesn't
| sound to me like they're taking advantage of your skills.
| bastijn wrote:
| Author mentioned compliance. He likely is an untrained
| engineer in the eyes of the organization owning the codebase.
| Working in a medical company I recognize this. You can get
| write access after you followed all necessary trainings. Part
| of those are for regulatory reasons, part of those are added
| by the company to make sure new people don't make a holy mess
| of a (central) platform codebase. Most of time people coming
| from outside the platform group can't oversee the impact of
| their changes. They think of implementing the feature but
| don't know the history of the codebase, forget to add tests
| (or add at the wrong place in test pyramid, do not check
| execution times, etc), requirements, design reviews, FMEA, SW
| BOM updates in case 3rd party is used, fix quality tool
| reorted issues, link tests to the requirements, update design
| documents and portals, communicate breaking changes, if any,
| etc.
|
| That is assuming the extension is actually desired. If
| everybody would start adding their little extension to a
| central platform before too long your platform is gone and
| instead you end up with a mono-archive that has no clear
| owner, a variation for every business unit, and so many
| possible configurations it can no longer be maintained.
|
| Probably it is not that contributions aren't welcome but the
| author must be trained, given access and the team owning the
| code must be made available to support. After design
| discussions the author should implement end2end but likely is
| not allowed to modify requirements and access some of the
| other tools to make the updates. So owning team must be made
| available to do that work. The owning team is likely not paid
| to smoke cigars with their feet up so Q1 2022 is their
| proposal. I've seen worse.
| Sevii wrote:
| Away team work is standard at Amazon. Of course you still may
| have to go to office hours and sign up for busy teams.
| tyre wrote:
| > This doesn't explain why they wouldn't accept the offer of
| work from /u/lopkeny12ko.
|
| I believe the manager explains it right after that. They have
| compliance reasons that not just anyone can access this
| codebase. It's also possible that the manager has acquiesced
| to types of requests before and it was a mess -- new engineer
| doesn't understand they system, requirements of its scale
| (note that this is a new engineer from a startup so the world
| that they are familiar with is not this one), and either 1)
| needs hand-holding 2) has code that doesn't meet their
| standards and requires extensive code review back-and-forth.
|
| There are many reasons why, "let me into your codebase" isn't
| a priority for the team you're talking to. Many legitimate,
| reasonable reasons.
|
| > It doesn't sound to me like they're taking advantage of
| your skills.
|
| Working as part of a large organization _is_ a skill. One
| that the OP doesn't seem to have. Which is understandable;
| they themselves said that they have always worked at
| startups. You can't walk into an entirely different context
| with challenges you're not familiar with, then expect to
| behave the same way and get the results you're used to.
| cm2012 wrote:
| The real reason is that the manager doesn't care at all,
| and it takes a lot less effort to say no than yes.
| ethbr0 wrote:
| There is _no_ compliance reason why OP couldn 't have
| _read_ access to look at the source.
|
| If there _is_ a compliance issue with someone looking at
| source, then either (a) their source control is
| misconfigured, (b) their source control is being misused,
| or (c) they have no policy to guarantee appropriate use and
| detect improper use.
|
| Any organization that uses compliance as an excuse for
| opaqueness, creating silos, and guarding projects like
| treasure is toxic, especially if people there are so
| institutionalized that they think that's a valid reason,
| and OP should begin looking for another job ASAP.
|
| (Said having worked at both companies with global read
| visibility & access scoped to team only)
| staticassertion wrote:
| > There is no compliance reason why OP couldn't have read
| access to look at the source.
|
| Companies can have whatever compliance terms they like,
| whether they map to ISO27001 controls or not.
|
| > Any organization that uses compliance as an excuse for
| opaqueness, creating silos, and guarding projects like
| treasure is toxic, especially if people there are so
| institutionalized that they think that's a valid reason,
| and OP should begin looking for another job ASAP.
|
| Or they believe it's a reasonable control. Let's imagine
| this is a company working on self driving cars. Your
| source code is probably something you want to protect
| very carefully.
| obstacle1 wrote:
| > This doesn't explain why they wouldn't accept the offer of
| work from /u/lopkeny12ko
|
| It sounds like OP is moving a bunch of the startup's systems
| onto bigcorp's infrastructure. Usually you can't "just do"
| stuff like that in a public company since there are laws and
| regulations surrounding access control, change management,
| data security, etc. For example PCI, SOC2, SOX, GDPR, ...
|
| It's usually not the case that the bigcorp people just want
| to prevent the fast-moving Startup Superstar! from moving
| quickly. Bigcorp operates in an entirely different context
| from startup, and needs to protect itself from employees with
| incomplete information making reckless decisions.
|
| I agree that OP should find a job that's better suited to
| their preferred style of working.
| pavel_lishin wrote:
| > _This doesn 't explain why they wouldn't accept the offer
| of work from /u/lopkeny12ko._
|
| I know of at least two teams who would kindly ask me to
| refrain from doing this; me doing the work doesn't mean they
| don't have to do any. They still have to take the time to
| review my code, provide feedback, possibly explain to me
| their standards and conventions. Afterward, they have to
| maintain and own my changes - what if I introduce a bug? What
| if the feature is popular enough that they now have to add
| additional functionality onto it?
| piyh wrote:
| Plus the ability to jump into another repo with zero
| assistance to implement a change is not common. Aside from
| the technical skills needed, other stuff like filling out
| change control forms or making sure the build passes CI
| isn't something you can do with repo access alone. To go
| down all those possible roads with anyone who asks can turn
| into a full time job when you multiply it in a large org.
|
| Then after supporting those requests and cleaning up after
| those people, you job becomes lumpy and irregular with tons
| of people owning your time. Getting out of a role like that
| either takes years or quitting.
| Joeri wrote:
| Setting up teams for inner source work can be done and
| tends to earn itself back, but most teams aren't set up for
| this. Typical solutions for the issues you mention: trusted
| committers to review and merge work without having that
| role burden the whole team, contribution guidelines to set
| standards, 30 day warranty to avoid getting code dumped in
| their lap that's broken but also avoid having too many
| owners of parts of the codebase.
|
| Anyway, I would recommend going to the inner source commons
| website and reading a few of the success stories like
| paypal's.
| yongjik wrote:
| > This doesn't explain why they wouldn't accept the offer of
| work from /u/lopkeny12ko.
|
| Probably because $BIG_CORP was also a nimble startup ages
| ago, and people had written important APIs as fast as
| possible because they had to, and they were successful, and
| the company grew, and three years later the core team
| realized they're supporting three different sets of APIs
| which all overlap but do things slightly differently, and
| because 70% of the company revenue depended on it, it took
| five more years and the souls of a few dozen developers to
| finally get it cleaned up.
|
| Understandably they don't want to open their codebase to
| someone thinking "It's just one feature that takes a few days
| to add! What's the issue?" - they're probably thinking "Will
| this make sense five years from now? What if
| $ACRUIRED_PROJECT gets deprecated later? Honestly I bet this
| project won't last two years..."
|
| ...or maybe they are just power-tripping lazy-asses. That
| also happens.
| kk6mrp wrote:
| > I know for sure that it's possible to be highly productive at
| a large company with a lot of bureaucracy -- but I also know
| for sure that new employees who try to bypass process and
| question the priorities of other teams, before they learn the
| ropes and build credibility and trust with other people, do not
| succeed.
|
| This is 100% correct. It takes time to find the people who can
| help you get things done and also time to build relationships
| with them. As others have mentioned, jobs (depending on the job
| of course) that one person can handle easily in a small company
| may take the coordination of multiple departments at a large
| company. For this reason you have to take the time to grow
| these relationships with those around you and in other
| departments. With time you'll find friends that will gladly
| help you accomplish the task you are looking to do!
| readme wrote:
| This is your moment of clarity: start interviewing.
| giantg2 wrote:
| "Is this how it's like at all large companies?"
|
| Maybe your example is a little more extreme than my experience,
| but yeah, pretty much how it works.
| misterbwong wrote:
| Having been _exactly_ where you've been a couple different times
| I can assure you that things can & will get better, if you let
| them. It's really up to you to learn and work within the system
| or to begrudge it. No judgement either way, bigco's aren't for
| everyone. I'm working on migrating our apps to
| the parent company's VM launching and deploy platform. Should be
| fairly straightforward, I think. Unfortunately, the deploy
| tooling isn't entirely compatible with our app so I ask the team
| if they can implement $X feature to support our app.
|
| > The actual fix is rarely the long pole in the tent for
| implementation. In the other team's mind this translates to: "Can
| you support a completely unfamiliar platform in your app from now
| until eternity?" The first engineer I talk to
| doesn't even attempt to answer my question but redirects me to
| their manager. Ok, that's odd, I think, but whatever.
|
| > Engineers being hit up directly by other teams is the first
| thing a manager stops in bigco. It's _good_ for their team but
| not necessarily outside teams or for moving fast.
| Manager says sure, just fill out this feature request doc. [...]
| delivery timeline of end of Q1 in 2022.
|
| > This is about prioritization and ROI. They need to document the
| feature, compare against other company and team priorities, and
| get approval to move on it. Bigco is a cruiseliner not a
| speedboat. It takes a lot to turn it so it naturally wants to be
| sure that it's headed in the right direction before turning.
| At this point I am in absolute shock. This should take no more
| than a few days to implement. So I reach out to the
| manager and ask what is going on. This is a simple task, I said.
| Why does it take an entire quarter for your team to deliver? He
| doesn't have an answer.
|
| > Again, the _code_ isn 't the hard part. I tell
| him I'm happy to fix the issue myself [...] and that only members
| of his team have R/W on that repo. What???
|
| > CYA, get used to it. What happens WHEN your patch breaks and
| deletes customer data? Who takes the fall? Probably not the guy
| who submitted a PR one time to help the team out.
| This is insane. And this entire time I was only alllowed to
| interact with managers and have not spoken to a single engineer
| about the actual technical details. It is impossible to get
| anything done here now.
|
| > Sounds like you also need to update your team structure for the
| realities of bigco. In bigco, there are _people_ (scrum master,
| eng mgr, product owner, product managers, etc) that deal with all
| the things in this post and shield your eng team from having to
| deal with bigco 's mess. Is this how it's like at
| all large companies? What should I do?
|
| > You should adapt. Or not. It's up to you. Some people like it,
| some people don't. Personally, I've come to terms with it and
| have tried to carve out a "smallco team" within the bigco
| structures. It's not perfect but it helps scratch my "get things
| done" itch. Also keep in mind, there are benefits to bigco.
| Work/life balance, etc etc etc.
| efficax wrote:
| Yes, this is all big corps, pretty much. Hopefully you get equity
| and job security to make up for it. Before we were acquired i put
| in 10 hour days at least. Now a good 4 hours and I've gotten more
| done than most. So that's also a benefit
| mattlondon wrote:
| Perhaps you are not their highest priority.
| rsd79 wrote:
| Hi!
|
| I have engineer's background and very much still feel like an
| engineer, but for over 10 years I have been managing a team of up
| to 50 developers within an organization with several hundreds of
| staff. Let me try to explain the "whys" below. Once you see the
| wider picture you might look at all this with less negativity,
| but it's also fine if you find it unacceptable - there are valid
| reasons why people leave corporations to work on something in
| smaller scale and what you describe fits a lot of these reasons.
|
| Larger companies focus much more on avoiding the risk of breaking
| something than on the speed of implementing new features. The
| painful process you are going through is probably a result of
| earlier experiences of having requirements dropped into the
| backlog by random people. In your relatively small startup team
| you did not experience it, but in large corporations just by pure
| chance you can get hundreds of requests from all over the place.
| Each of them has costs associated with it: implementation,
| testing, change management (in order to keep track of stuff for a
| chance of a team resigning en masse) and the virtual cost of the
| risk of breaking stuff in production. Especially in a project
| which seems to be widely used by other teams.
|
| The 4 pages long form is there to make sure that you really need
| the stuff done - otherwise you would not waste your time to write
| all that.
|
| The two managers approving the change are there to prevent stupid
| stuff from being worked on just because somebody sits next to the
| developers and has various "ideas" and "needs". They are not
| there to discuss your idea with you, but rather to make sure it
| does not go against the project's priorities, which are unknown
| to you.
|
| The lack of R/W access to the repo is to keep control over what
| happens in the project. It's not that they don't trust you, it's
| that you have no idea what they need outside of your small
| feature. After few months they need to be able to know (more or
| less) why something is present in the code, regardless of you
| being there or not.
|
| You are not allowed to speak to the engineers, because they will
| be working on your feature around the end of Q1 2020, so you'd be
| wasting their time now. They have a backlog of other stuff to do
| and won't remember your input after few months anyway.
|
| What can you do? Notify your manager about there being a blocker
| for your task and find something else useful to be busy with in
| case your blocker will land below a hundred of other blockers
| from other people. Remember that your personal efficiency is not
| equivalent to organization's efficiency and learn to handle
| several tasks at the same time while waiting for blockers for
| most of them to be resolved. Do not mistake it with multitasking
| (actually working on multiple things simultaneously), it's just
| an efficient scheduling of available resource - yourself - in the
| context of an organization working in unison.
|
| PS. For most of the my time managing developers I've been working
| really hard to make sure people from across the organization do
| not interrupt them in their work. Once you put yourself in the
| skin of the engineers you are not allowed to talk to you will
| understand that at least some of the stupid mechanisms you've
| encountered are there for exacly that reason. You should respect
| that as an engineer.
| jensensbutton wrote:
| > 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.
| milkytron wrote:
| 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.
| dools wrote:
| Don't think of it as one company, imagine every team is a
| company. What you're experiencing is no different from when I use
| a SaaS product and I would love them to implement a feature in
| their API, but it's not their priority.
|
| Imagine if I asked that SaaS company for access to their codebase
| so I could submit a patch.
| mcbrit wrote:
| The redirect to a $LARGE_COMPANY/process is best understood as
| what everyone who does not have $THE_WIRE/suction deals with to
| get anything done. No one that matters at a $LARGE_COMPANY is
| impeded by the process unless they want to be impeded by the
| process. (eg: delaying tactic, turf war!, pass for political
| reasons, don't think it matters and so can't be bothered, think
| that the request is wrong for reasons, and so on.)
|
| Large companies view your day-to-day activities through a very
| different lens than a startup, and they want you to use a very
| different lens as well, and you'd need to get the right
| combination of manager and mentor and team and teammates and
| yourself to get the payoff.
|
| I'd roll into another startup; since you haven't, I'd assume you
| have reasons for not rolling into another startup, but it's
| getting kind of abstract at this point.
| pjc50 wrote:
| > Recently we were acquired by $LARGE_CORPORATION
|
| You didn't mention retention bonuses, so: start looking for
| another job. Your old job is gone.
| kelnos wrote:
| I hate to say it, but, in agreement with many others here, this
| isn't all that unusual. It's probably on the worse end of normal,
| but isn't abnormal.
|
| What do you do? Well, I assume you have some sort of retention
| bonus or stock lockup that requires you to stay for a while if
| you want the money, so decide if it's worth it to you to stay,
| and quit if not.
|
| If you decide to stay, you'll have to find a way to remove
| yourself emotionally from this work for a while. Stop caring
| about how long things take, and coast for a bit. Rearrange your
| time so you front-load things that you can do on your own,
| without onerous process or others' permission. Try to anticipate
| things you'll need to get done that _will_ require coordination
| or help from other teams, and start that process as soon as you
| can.
|
| I agree it's frustrating, and not what you're used to, but if the
| money is good enough such that you want to stick around for a
| bit, you'll have to adapt both your attitude and how you organize
| your work.
| perlgeek wrote:
| > What should I do?
|
| The obvious solution: if it drives you nuts, quit.
|
| If you don't plan to go that route, do two things you:
|
| 1) tell your direct superior (in writing)
|
| 2) whenever you get asked "why aren't you done with this
| migration", answer "we're blocked by $X" with a reference to
| their issue tracker / ticket system / whatever.
|
| ... and then work on something else.
| golemiprague wrote:
| talolard wrote:
| I worked at Citi for a while and this pain sounds familiar. It
| once took me 6 months of hounding an MD to get approval for my
| app to connect to a particular database.
|
| It sounds like you're very motivated and presumably talented, but
| the organizational friction doesn't really allow for your
| blessings to shine.
|
| On the other hand, this is the reality for many many people and
| many many dollars. It's a great opportunity to both develop
| empathy for a kind of user you never imagined (all those people
| trapped in these processes for life) and to learn new ways to
| excel, within the context you're currently in.
|
| When I was at Citi I learned a lot about communicating with
| stakeholders and fostering internal relationships which has been
| very useful in my career. Maybe you can find the same there ?
| rhacker wrote:
| This is what I did. Worked there for another year. Enjoyed the
| options payout (it wasn't much but it was something).
|
| However, slight regret was the larger company's stock was worth
| WAAAAY more 5 year later. Like 5x.
| hn_throwaway_99 wrote:
| My recommendation:
|
| When you're young, find dynamic startups to work on, there is a
| good chance you'll find the work interesting, learn a lot and get
| to have a larger proportional impact, and potentially have a
| decent exit.
|
| When you're on the back side of your career, find a nice big
| company where you can hide in the cracks long enough to collect a
| paycheck before they question what it actually is ya do here.
| You'll have plenty of time for outside hobbies with little
| stress.
| ryanbrunner wrote:
| 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.
| toast0 wrote:
| This kind of thing is more or less how large companies work.
| These specifics sound pretty bad, but inability to do work that
| isn't on the roadmap and a roadmap that's written in stone once a
| year (maybe twice if you're lucky) is very common. The way to be
| able to get things done is to reduce dependencies on other
| groups, especially other groups that are impossible to work with;
| but that might not fit with corporate policies.
|
| If your retention compensation is good, try to learn to accept it
| and just keep getting things done, even though it takes longer
| and you can't get as many things done, until the retention runs
| out or you can't take it anymore or whatever. If the compensation
| isn't good, then it's time to look for something else.
|
| One of my coworkers left rather than be part of an acquired team.
| He had been acquired before and wasn't willing to deal with it
| again.
| lowbloodsugar wrote:
| I used to question the decisions of engineering leadership (in a
| small company of 50). When I was promoted to engineering
| leadership, I found myself making the same decisions that I had
| complained about.
|
| You have entered a world of which you have no experience. You are
| simply not qualified to evaluate the performance or methods of
| the people around you.
|
| You can take this as a learning opportunity, or you can run
| screaming back to the world of startups. Both are utterly valid
| and rational decisions. I did startups for thirty years, and now
| I'm in an enterprise. Part of me wants to run screaming every
| day, and then there's the part that gets shit done in an insanely
| complex environment.
|
| If you stay, I recommend that you are the one that bends. Change
| your deployment system to work with their framework, not the
| other way around. Be pragmatic.
|
| If you leave, do so quickly.
|
| Either way, make a _choice_ and act.
|
| Now, if you stay, you may learn that, in fact, yes, the managers
| at this company are byzantine managers [1], or you may learn that
| this is an effective organization. If the former, get out.
|
| I always chose the startup option until recently, and while my
| stock was never worth anything, I'd do the same if I was young
| again. Do so knowingly.
|
| [1] https://twitter.com/ncweaver/status/1473084555976273924
| shadowtree wrote:
| Tell me you never ran a large code base in production, without
| telling me.
|
| Past a certain point there are no "simple code changes" anymore.
| Automation and functional QA needs to ensure zero regressions,
| internal and external docs need to be considered, it all needs to
| be bundled in with many other code changes (feature and fixes),
| etc. There is no shortcut. Even FB had to dial back their "break
| shit in prod" mantra.
|
| Of course startup devs hate this, real men fuck around in
| production, which is great. Running and maintaining a large code
| base is very grown up sport, more like running a country than
| building a house. For those on the other side, who inherit
| startup code and have to fold it in ... the hatred is mutual.
| dllthomas wrote:
| > very grown up sport, more like running a country than
| building a house
|
| We need to stop calling things "grown up" when what we mean is
| that they take a different set of skills. It's childish, and I
| think it's been causing harm in our industry.
| dools wrote:
| So it's okay to refer to something as childish but not as
| grown up?
| roflulz wrote:
| so much irony
| timdaub wrote:
| I dislike your condescending tone and I also think your speech
| doesn't generalize.
|
| There are large code bases in production that are productive:
| Everything that is open source - and still the process isn't as
| shit as op describes.
|
| So this has to do with corporate hierarchies and not the
| quality of the code.
| danielmarkbruce wrote:
| The original post is pretty condescending, it's just worded
| _slightly_ less so. Now, that doesn 't mean the very best
| response is to be condescending, but the invitation is right
| there. Sometimes a reasonable response to ~ "can you believe
| these idiots!" is "actually, look in the mirror, and squint a
| little".
| bastijn wrote:
| > There are large code bases in production that are
| productive: Everything that is open source
|
| Yes there are but these are not without rules. Try to add a
| new feature to a large open source project as a new
| contributor. That has probably as much chance of succeeding
| as doing this in an enterprise.
|
| There is a reason larger OSS projects have the "good first
| contribution" section. These are small bug fixes where the
| work is already spelled out typically. You do these to get
| familiar with the codebase and learn how to make a valuable
| contribution the size of a feature.
| throwaway2331 wrote:
| Man, unvarnished, lacking agenda---besides the stroking of
| one's ego---and blunt communication: I missed you so.
|
| I agree with the sentiment. Being an "adult" is about
| restrictions, limits, boundaries, and confines; you can't just
| willy-nilly do whatever you feel like. You must now realize and
| accept that we all bend the knee to something. We are not
| immortal gods, free from all consequence, but merely ants
| allowed to live by the systems we inhabit.
|
| Perhaps the most authentic post I've seen on this entire site
| in a long time.
| zepolen wrote:
| > Tell me you never ran a large code base in production,
| without telling me.
|
| Your post does a good job of that.
| altdataseller wrote:
| Yes this is how it is at almost all large companies,
|
| No, you don't have to stay, that part is optional. Lots of
| startups are hiring.
| notyourday wrote:
| > Is this how it's like at all large companies? What should I do?
|
| The answer is easy: make bank. You are making a lot more money at
| a large company for much less work, right? Enjoy it!
| trebligdivad wrote:
| Perfectly normal; a lot of big companies are broken - but...
| sometimes you can find an interesting/sane part of a big company;
| you could try and get yourself internally transferred to a sane
| part. I've seen whole teams from a startup move inside the big
| company away from the part that organised their purchase since
| they were so broken. Or just leave; the big company owes you
| nothing [or if it does at given specific dates, just hang in for
| those and plan your escape]
| stevage wrote:
| Quit, obviously. You like startups and this isn't one. What's the
| dilemma?
| pfooti wrote:
| 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.
| solarmist wrote:
| >Is this how it's like at all large companies?
|
| Not good ones or at least good team's within big companies.
| seattle_spring wrote:
| 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.
| chomp wrote:
| I was an ops manager at $big_company like the one described;
| your response gets it pretty right. There were many many groups
| that all wanted a slice of our team's time, and it added up to
| probably a 6 month lead time on all requests. Bringing in skip
| levels was almost necessary as we sometimes had to have upper
| management fight over who wants their subordinates' tasks done
| first. We didn't care who's tasks got done first, we just
| needed to know what the enterprise's priorities were. It wasn't
| uncommon for these tasks to have to snake through multiple
| groups for a couple weeks so that they can each give their
| input on what should be prioritized before it even hit our
| backlog.
|
| If their parent company is publicly traded, giving access to
| the codebase is a huge SOX no-no.
|
| All of these gripes are just big company issues. I suspect OP
| is a better fit for smaller, non-public companies.
| gorbachev wrote:
| Agree 100%.
|
| However, the manager of the other group should get some
| management training. He did a piss poor job at communicating.
| All it would've taken is explaining the group's prioritization
| and roadmap and the OP would've not left with "THIS COMPANY
| CAN'T DO SHIT!" feeling.
|
| Now, if they don't have a roadmap, and their prioritization
| sucks, that's another matter, and entirely possible, of course.
| pvarangot wrote:
| But what's not allowing access for compliance reasons and
| that's it? There should be a form where he can request access
| if he thinks he can pull off an implementation in days of
| something that takes months otherwise.
|
| I worked in big and very big corporations and cut through PCI,
| HIPPA, and lots of those with requests like that. That they
| have forms and scheduled for a month in the future (assuming
| second half of December doesn't exist which is reasonable) is
| good. But that there's no process to get access to their code
| and figure our what's going on is not ok. Specially if they are
| an infra team.
| johnyzee wrote:
| It sounds pretty standard, and it doesn't sound like the OP has
| put a lot of work into considering why it works the way it
| does.
|
| Know that annoying executive who likes to come to the
| development team and ask them for work? That's what the OP is
| doing. And how he then loudly laments that he will have to
| follow some process to have his request added to a backlog,
| before, at some opportune time in the future, it can be
| considered and possibly scheduled for being implemented? Yup,
| OP again.
|
| We hate it when process hits us, but you'd hate it even more if
| there was none.
| zerkten wrote:
| Based on only what you have posted you should leave in a
| controlled manner. No matter how you feel, you should avoid doing
| things that burn bridges. If something catastrophic happens, I've
| seen large companies be incredibly generous, either by opening up
| roles to take folks back, or offering long-term contract jobs
| where the person gets back eventually. Smaller organizations
| rarely have the flexibility to make that happen.
|
| However, there are good reasons not to leave immediately,
| including vesting, the opportunity that being acquired by
| $LARGE_CORPORATION may present (you aren't solely responsible,
| but you've helped build something that was acquired, which is
| experience worth something to some people), and expending perks
| that $LARGE_CORPORATION may offer (often these aren't all made
| visible to you.) If you have trusted peers that have left, or are
| potentially leaving, you may want to check-in with them.
| kazinator wrote:
| > _have always worked at startups_
|
| If you want that invariant to remain true, it is logically
| necessary to leave.
|
| > _Unfortunately, the deploy tooling isn 't entirely compatible
| with our app_
|
| I'd say that apps have to adapt to existing deploy tooling, not
| vice versa.
|
| Platforms are historically slow to adapt to applications not
| written for those platforms; almost invariably, the motivation to
| work on some platform, and the subsequent porting, comes from the
| application side.
|
| > _Is this how it 's like at all large companies? What should I
| do?_
|
| I'd say that it's a bit of a Dilbert caricature of how it is, but
| in some aspects it is representative. In a big company, there are
| other divisions and teams which have entirely different
| priorities from yours. They have their own work items and
| milestones; and it is a fact that managers protect engineers from
| taking on work from side channels. This can be a good thing: in a
| big company you can take advantage of that to reduce distractions
| and stay focused on something.
|
| Just because your idea is approved and scheduled for sometime in
| 2022 doesn't mean they are just twiddling their thumbs, but it
| does seem as if they don't share your view of how urgent the
| feature is.
|
| Source code repos not all being open company-wide is also not
| unheard of. The ownership boundaries tend to be clear.
|
| If you were to work on that software to submit a patch, one of
| two things would happen: it would be something like a customer
| request, where an engineer has to be assigned to that patch and
| be responsible for integrating it: getting it to pass all
| reviews, and do additional work on it like test cases,
| documentation and whatever. Or else, you would have to
| effectively be joined to their team to particpate in all that:
| get the associated ticket assigned to you, have access to all
| their systems (repos, bug databases, code review, documentation,
| ...).
|
| Probably best to just let them own it.
|
| Any sort of priority shift (your application A being an important
| payload for their delivery platform D) will have to take place at
| the management level. Your management convinces some higher
| management (that is above both of you) that this is important,
| and then that comes down as a mandate to their team: please give
| your cycles to A.
| rajangdavis wrote:
| Is it possible that there might be a code freeze at the end of
| the year so that engineers that are on call don't have to work
| through the holidays?
|
| Without knowing the codebase, can you accurately assess that the
| fix you want can truly be completed within a few days? Does that
| cover testing and documentation?
| dogleash wrote:
| >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.
| tejohnso wrote:
| Exactly. There are environments where individual proactive
| efficiency is highly rewarded and respected, but not all.
| Sometimes you just need to settle down into the same flow as
| others. Trying to swim faster than the current just doesn't pay
| and can also breed resentment toward those who have mastered
| the coasting mentality and seem to be doing better off
| financially and mentally.
| korijn wrote:
| To add to this, something that helped me accept this change:
| your acquisition marked the achievement of your startup goal.
| You're done now, you can now stop living for your work, and
| start working to live.
| yawnxyz wrote:
| or pick up a new hobby that occupies the mind! Or start the
| next thing!
| altdataseller wrote:
| I think OP was an employee at a startup got acquired. Which
| may or may not mean they got a huge financial windfall from
| it
| jacobr1 wrote:
| Then this is the time that the OP needs to join a startup
| as founder or early employee and get meaningful equity in
| exchange.
| korijn wrote:
| I get where you are coming from, but even if you don't get
| huge financial windfall, there is just no point in
| sacrificing yourself anymore. It's not going to make as big
| of a difference anymore.
| obstacle1 wrote:
| If you don't get a huge financial windfall, there was
| never a point in sacrificing yourself.
| matwood wrote:
| Bingo. I've been through a similar situation, and what helped
| was realizing I 'won'. Unfortunately not a unicorn type win,
| but a win nonetheless. Relax, recharge, and then look for the
| next opportunity.
|
| I think a lot the advice in this thread about navigating
| large company politics is missing the point a bit. I've heard
| entrepreneurs and people who like to work at start ups
| describe they don't do so because they necessarily like to,
| but because they have to. They are either bad at, or
| can't/refuse to deal with large company politics so head in a
| different direction.
| JamesBarney wrote:
| This.
|
| I call this achieving Enterprise Zen.
|
| You have to let go of your attachment to productivity and
| ponder on kohns such as "If a task is accomplished but no one
| sees it on a report, was that task accomplished?"
| beaconstudios wrote:
| Ugh, the management visibility dance might be the worst part
| of enterprise work.
| atmosx wrote:
| we call this :PASOK:
| selimthegrim wrote:
| Aren't they out of office?
| dimitrios1 wrote:
| And this is only beauty of JIRA and sprint reports being a
| KPI in an org. I wouldn't so much as even lift a finger
| unless it had a ticket assigned to it.
| datavirtue wrote:
| If this work doesn't show up on a report, should I do it. Not
| unless you want your hand smacked.
| jrmg wrote:
| _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)._
|
| 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.
| bink wrote:
| Completely agree. I would add, though, that there is no reason
| not to recommend improvements if you can think of them. You
| don't have to just accept that things take forever, are broken,
| and everyone hates life. It's not all that rare to find a good
| manager even at a big Org that wants to help improve things
| where they can. But if they reject your suggestions then the
| Zen approach is by far the best.
| Simon_O_Rourke wrote:
| Count yourself lucky you had the necessary kit to actually
| interact with the codebase at all.
|
| I've seen large corporations dragging their heels getting basic
| laptops, database access or repo permissions out to devs, even
| when there's some critical fix required.
|
| Accept there's little you can do in these situations except play
| their game. You're now going to have to figure out whether the
| financial gain is worth the loss of agency, simple as that.
| vmception wrote:
| The market is saying you should go solo and work on Web3 because
| it wont take you a quarter to launch something useful and you can
| make way more money
|
| I know, tough idea to swallow, especially when thinking that it
| sounds like "just launch a web 2.0 startup with a mobile app"
| after knowing how few people make any money. But I think you'll
| be able to look back at this and see it was an accurate
| suggestion.
| gringoDan wrote:
| When the Dilbert comics become all too real. While you may find
| it difficult to get things done, the bureaucracy will leave you
| with a lot of time on your hands. With that time, either:
|
| 1. Pour the energy you would have put into work into side
| projects, starting your own company, etc. Good route to take if
| you are vesting.
|
| 2. Interview at other companies where you can actually make an
| impact. Luckily the job market is insanely hot right now, so your
| comp package should be bumped accordingly.
| Sohcahtoa82 wrote:
| > 1. Pour the energy you would have put into work into side
| projects, starting your own company, etc. Good route to take if
| you are vesting.
|
| Isn't this dangerous advice? Could work done on a side project
| during company time end up being legally owned by their
| employer?
| martini333 wrote:
| r/antiwork
| geofft wrote:
| 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.
| ivan_gammel wrote:
| 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.
| clavalle wrote:
| I'm in a similar boat. I feel your pain.
|
| I was an engineer and very early employee at a startup. I helped
| grow it from four clients to many millions in revenue and a
| successful exit. I nurtured a team of amazing engineers. I felt
| like I needed to stick around to see the product off to a good
| start and my team thriving at their new home. I was also excited
| because I hadn't worked at a large company since I was just out
| of college and I was interested in the unknown challenges that
| awaited.
|
| Our parent company isn't quite as bureaucratic as yours sounds,
| but it's more bureaucratic than our original company, for sure.
| But they said all of the right things. More resources. More
| opportunities for personal and team growth. But things wouldn't
| change and we'd be left alone to continue our success but with
| more fuel and maybe a slight shift to integrating more smoothly
| with the rest of the company's products.
|
| I also found myself in a leadership position, so I thought I
| could change what few small things I noticed as a bit inefficient
| in the the culture to be a bit more responsive.
|
| Long story short: I'm looking for another growth stage startup to
| join. I probably should have done so right away.
|
| First warning -- the new company was obsessed with what title I
| should have. The startup didn't put much weight in titles. We did
| what needed to be done. My official title was Director of
| Engineering -- mostly to make clients happy when I talked to
| them, but they definitely could not have that...that tier was
| full. I ended up a Solutions Architect and Technical Manager. Ok,
| cool. Similar responsibilities and team.
|
| Second warning -- lots of leadership changes at the home office.
| We've had three CEOs since we've been acquired. We're just the
| right size to be a stepping stone for ambitious leaders. It's
| kind of amazing that we have CEOs step into a very complex
| organization selling very complex solutions and they expect to
| learn enough to make an impact in a month. Then they start to
| pursue their agenda with verve! So...they inherit the broad
| brushstrokes of the previous administration, add a few of their
| own, and the organization is off on a new adventure.
| Unfortunately, it's a recipe for a lot of stuff to be ignored.
| The previous agendas that might have been the first step in a
| fine program of ideas that would lead to wonderful things becomes
| The Agenda. Predictably, the first step isn't enough to see a
| whole lot of fruit so...yeah.
|
| Third warning -- we weren't allowed to even talk about creating
| new products. We're an acquisition company, now. We buy winners.
| We don't risk creating losers. Not so fun for someone who Really
| Loves Creating New Things.
|
| So...here I am envying your early clarity. Large companies are
| just different. I am starting to believe innovation at scale is
| rare, if it exists at all. If I were you, or me two years ago,
| I'd start looking for a better fit.
|
| Let the MBAs run these companies through the motions of the
| terminal stages of the business lifecycle. I'm ready to get back
| to bringing new things to life. It sounds like you are, too.
| mathattack wrote:
| Large companies spend more time on coordination, risk management
| and the mythical "alignment" than smaller companies, who spend
| more time doing. If done right, this creates economies of scale,
| as well as the predictability that Wall Street asks for.
|
| But... To thrive you have to focus on a lot of less fun things.
| And excellence at the expense of the things listed above isn't
| valued.
|
| If you love the small company work environment more than your
| specific product, then you should consider an exit. If the value
| of your golden handcuffs is too high, then play along.
| jrockway wrote:
| At large companies, I've always been in the habit of expecting
| one thing I need per quarter. That means that if I need something
| this quarter, I put it on the other team's roadmap for next
| quarter, and then do my integration the quarter after that. (My
| experience was an organization where OKRs were the root of all
| planning. If you are working with teams that do bug triage /
| prioritization / sprint planning every two weeks, then obviously
| the latency can be decreased. But quarters seem like an
| artificial boundary that people love for whatever reason.)
|
| This sounds terrible, but it worked pretty well for larger
| things. I was a TL and was in the habit of meeting with my
| internal customers before quarterly planning, to make sure that
| we could add their requests to our todos for that quarter, and
| then make sure we always executed on them. (We did do the things
| we promised, so people could make accurate plans. I remember many
| quarters of people sounding mildly shocked that we did stuff they
| asked for, but after a track record of execution, we got trust
| without any pushback like "can you do that right now instead of
| next quarter?")
|
| Obviously, this doesn't help you very much if you want to get
| your thing done today and move on to your next task. Your product
| and your integration is going to look like the org structure that
| your company has. If you need deep integration with the product
| but are a separate team, well, I've simply never seen that work.
| The teams need to be much closer together in the org for that to
| happen.
|
| Edit: oh, I'll add one other thing. Once planning starts to work,
| you can kind of dial up or dial back how quickly you want to
| react to one-off tasks or special requests. For example, if your
| team has a track record of completing 100 story points worth of
| work per sprint, you could only take on 80 story points and use
| that capacity for special requests. Planning sounds like a drag,
| but the discipline is actually very useful.
| softwaredoug wrote:
| You just simply escalate to whoever is asking you to the parent
| company's platform. And lay out the consequences of it not
| happening - it's as simple as that.
|
| When your manager asks "why isn't this done yet" you document
| what you've said here, and say you're blocked. Any sane manager
| would escalate and see why it isn't done. If it truly is a
| company priority, it'll get unblocked. If it's not a company
| priority, it'll continue to be blocked, and you'll work on
| something else.
| Merad wrote:
| > So I reach out to the manager and ask what is going on. This is
| a simple task, I said. Why does it take an entire quarter for
| your team to deliver? He doesn't have an answer.
|
| Have you never worked on a team that had work planned out months
| in advance? Usually IME the team will only plan out the next
| quarter in any detail since things always change. But the product
| team and managers often have a roadmap (high level plan)
| extending out a year or more.
|
| Most likely this team has already planned their Q1 and has given
| commitments to stakeholders, etc. For your work to jump to the
| head of the queue it would need to be more important than what
| they've already planned. Yes, maybe your request only takes a few
| days, but odds are that the team has dozens of requests on their
| backlog that are just a few days worth of work. If you want to
| try to get them to prioritize this work then someone from your
| team (typically PO, PM, or manager) needs to reach out to the
| other team and communicate what the impact to the company will be
| if your team is blocked for the entire quarter.
|
| P.S. - Sort of a tangent, but this scenario is one where a good
| scrum master is worth their weight in gold. Once you communicate
| to the team that your work is blocked the SM can take on figuring
| out who needs to talk to who to try to prioritize the work, and
| will stay on those people to follow through so that you know when
| you'll be unblocked and the team can adjust plans accordingly. It
| may sound like a small thing, but it's wonderful not having to
| deal with it yourself as an engineer.
| crdrost wrote:
| So, the cost to the company becoming large is that politics
| exist. There are too many stakeholders and they want to pull
| things in different directions and you have to be politically
| savvy in order to balance between them.
|
| This is not everyone's vibe and it is why a lot of Open Source
| software does better with a benevolent dictator than with a
| democratic process. For instance it's the reason that I don't
| contribute to Wikipedia.
|
| Once you realize that you're particular situation is a political
| problem the solution becomes obvious. You stop working on the
| "required upgrade", citing that you are blocked on this other
| team. If possible, track your onboarding feature in the big
| company's issue tracker, and link the two bugs as blockers. The
| political side is, if somebody actually needed you doing this VM
| migration work, they need to escalate to this other team. Or,
| they need to give you a big juicy high-profile project to
| refactor your code, to not do whatever it was.. and this gives
| you plenty of space to also do all sorts of other things that you
| never get to budget refactoring time for. Your call whether you
| like the game once you know how to play, or whether you nope out
| like I did with Wikipedia.
| aroundtown wrote:
| >What should I do?
|
| You should take a moment, and try to understand the other side of
| your request.
|
| Read this response from /r/antiwork, it's about a new manager
| having to get his team to understand work life balance:
| https://www.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...
|
| Also, this issue goes beyond you. If you need something done,
| with a different org, that is now on your boss to figure out how
| to get that done, not you.
| nocturnial wrote:
| 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.
| bps4484 wrote:
| My response to "Oh, I can implement this in 5 minutes" is
| always "but will you support it?"
|
| I think this is the hardest thing about moving from a startup
| to a more mature company (either through growth and age or
| acquisition); you have to move your mindset from building to
| supporting. Building is fun and creative, supporting can be
| tedious and soul sucking (but needed!). It's a huge, and
| legitimate, reason why large companies slow down (either to
| support, or to consider support in the build process).
| lolinder wrote:
| And it's not just large companies that slow down, either. I
| work for a very small organization (three developers) that's
| been around for 10 years. We'd love to spend more time
| building new stuff, but we've got 10 years' worth of old code
| to support. We don't have bureaucracy getting in the way, but
| we still can't move as fast as new startups.
| costcofries wrote:
| Is there any value in you learning how to effectively work in a
| place where things take weeks instead of days? If not, that's
| okay. Though do appreciate that as that 50 person company scales,
| it too will need to take a longer time to align all the moving
| pieces.
|
| Moving slow isn't inherently bad, it just might not be.. your
| thing.
| datavirtue wrote:
| Moving slow isn't bad? Try mentioning that at the next standup.
| guynamedloren wrote:
| 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.
| channel_t wrote:
| This is probably the correct answer in most circumstances,
| unfortunately. It's just the circle of life. Acquisitions are
| rough and if you aren't being significantly incentivized to
| deal with all the extra BS that comes along with it, then it's
| time to move on.
| TheGigaChad wrote:
| wly_cdgr wrote:
| Just leave and get a job at another startup. Some people are desk
| jockeys and some people are field agents
| lido wrote:
| Yes. Quit. Join a startup (we're hiring).
| ironmagma wrote:
| > Is this how it's like at all large companies?
|
| Pretty much. Hearing about a large company that moves at any
| appreciable velocity is the exception, not the rule.
|
| > What should I do?
|
| If you have stock, it's probably worth it. But maybe not --
| you're the only one who can decide. What do you value more, money
| or happiness?
| WORMS_EAT_WORMS wrote:
| Vest and walk. Congrats
| PragmaticPulp wrote:
| 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.
| BurningFrog wrote:
| 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.
| auggierose wrote:
| It's really simple. Remember how it was in school? There was
| nobody in your class like you. In your year? One or two you could
| actually talk to. Now, in a big corp, it's basically like in
| school again. Just get out of there.
|
| And the people telling you, that's just the way it is, and the
| managers have their reasons? Of course they have their reasons,
| but they are not yours. They have families they need to take care
| of, they got used to their big pay checks, and all of these
| things make it impossible to do certain things anymore, although
| they might seem simple.
| rkk3 wrote:
| My favorite $LargeCompany move was a few years ago, when my
| friends highly compensated (6 figure equivalent) summer intern
| class didn't get IT's permission for internet access at the
| company, for 2 weeks.
| dpark wrote:
| > _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.
| gwbas1c wrote:
| Exactly, and:
|
| > I'm working on migrating our apps to the parent company's VM
| launching and deploy platform
|
| Who asked you to do this? They should be "going to bat" to make
| sure that you're getting what you need to do this.
|
| If it's some high up in your acquiring company who asked for
| this, that high up should be talking to the other team and
| making it known that they need to cater to you.
|
| But: If this is some initiative from your team because you're
| good team players, expect whoever wants this done to put in the
| political grind. ("You asked for xyz, you need to do the
| politics if you want this donw.") Otherwise, it's best to move
| to a different task.
| renewiltord wrote:
| Many large companies are like this. Personally, I find it very
| frustrating. At one place I worked that was acquired, the teams
| decided to silo themselves off (no outside patches) with SOC2 or
| something or the other determined to be the reason. There were
| many parts of the system that I knew better than the teams
| themselves and I didn't have the commit bit. It was a nightmare
| and through lots of work I managed to get commit. It was
| successful for a bit but ultimately I was expending a lot of
| social capital and even if I took on full ownership for
| maintenance and delivered on it, the standards people hold for
| their own team are usually lower than what they hold for someone
| like that.
|
| I left to go on to other things.
| [deleted]
| jc_811 wrote:
| To sift through all of the noise, the answer that makes the most
| sense is 1 word: quit
|
| In your own words it "sucks". If you don't want it to, your only
| real options are to accept the new normal, or find a new job. In
| organizations of that size it will be a grinding multi-year
| (decade?) marathon to make any company-wide change.
|
| If you're an engineer, and have an acquired startup on your
| resume, you should have no issues finding a new role at another
| company that has your ideal employee size & culture.
|
| Edit: I don't mean quit today and walk out. But rather, have a
| new job be your new primary goal and start the search. This will
| help you get through the days you have left (you'll be amazed how
| much mental relief is provided when dealing with a stressful
| situation, but then realizing - I don't have to deal with any of
| this much longer), while being responsible and not leaving until
| you have a new gig lined up
___________________________________________________________________
(page generated 2021-12-21 23:00 UTC)