30 ms·

> 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

by _skel 5y ago

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

rpeden 5y ago
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.
- isbvhodnvemrwvn 5y ago
  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.
- dpark 5y ago
  > 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 5y ago
    [deleted]
  - masklinn 5y ago
    > If it’s only a few days for an infrastructure change, why is it so untenable to modify the app? It could be an incompatibility with a core requirement e.g. application used webrtc or websocket, bundling / deployment system can’t handle them (will reject / close on upgrade requests or long connections), you’d have to rearch the entire product, probably detrimentally to the system / experience.
    - dpark 5y ago
      Certainly something like that is possible, but I don’t think so given the way OP wrote about it. Especially lines this this: “the deploy tooling isn't entirely compatible”. That doesn’t sound like a critical missing feature (which would somehow be cheap to add). It sounds like a fairly minor roadblock that he expected the other team to solve for him. My guess is that it’s one of those things that might take the other team a week and would take OP 2-3 weeks, so in a little start-up, the other team would obviously do it because it’s more efficient. But in a big corp, asking the other team to make the change is kind of like asking AWS to make the change. (Which could be the case if Amazon is the big corp in this story.)
laluser 5y ago
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 5y ago
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/uloosesignificance166_explains_how_he_stopped_a/?ref=share&ref_source=link https://www.reddit.com/r/bestof/comments/rkru22/uloosesignif...
- meigwilym 5y ago
  I immediately thought of this as well. Great minds etc.
- ascar 5y ago
  Direct link https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_supervisor_and_my_direct_reports_are/hpacf5h/ 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 5y ago
    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 5y ago
      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. :)
      - isbvhodnvemrwvn 5y ago
        I 100% guarantee it's someone who has recently read "The Phoenix Project" and made it up based on that.
achillesheels 5y ago
>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 5y ago
  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.
CogitoCogito 5y ago
> 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.
- Sevii 5y ago
  Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.
  - kuraudo 5y ago
    I was going to say the same thing here. It amazes me that the company I always assumed was massive, slow, and bloated actually moves at the speed of light compared to op's acquiring company.
- tyre 5y ago
  > 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.
fiachamp 5y ago
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 5y ago
  if your startup ever makes it to any sort of scale, it will likely have the same problems -- they all do :)
  - maerF0x0 5y ago
    and you're lucky if you can actually tell what the real problems are, because mostly I find people are chasing symptoms these days.
  - jimjimjim 5y ago
    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.
  - chris11 5y ago
    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.
  - toast0 5y ago
    And when it reaches that stage, the OP can nope out to another up and coming startup. There's no reason someone needs to stay at a company through its whole lifecycle.
rjzzleep 5y ago
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
- endymi0n 5y ago
  ...or commonly phrased by my ex manager when I loudly complained about something as "love it, change it or leave it". It was a hard truth to swallow, but rationalizing it, I quickly realized all other reactions to adversity are pretty pointless indeed. There are people who thrive in large orgs and then there's others... eventually I realized there's simply no way I'll ever make peace with bureaucracy. I can stand brilliant chaos and long, hard hours among talented people better than being a smart cog in the wheel who effectively does 50% of a 9-5 gaming the system and playing solitaire otherwise. Everybody needs to choose their poison.
  - fargle 5y ago
    run, hide, fight
- dnissley 5y ago
lojack 5y ago
> 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 5y ago
  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 5y ago
  > 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.
  - lojack 5y ago
    I also said: > Similarly, the work OP is doing may be much less important than they think it is.
- mateo411 5y ago
  > Queues are an inappropriate construct for managing work. I disagree. A queue is used to assign priority to a project. When there is more work than people to do the work, you need to prioritize and triage. Just because there is a queue doesn't mean that you can't handle urgent work. You can move it to the head of a queue. Usually what accompanies a queue is a ticketing system. Nobody like these, but when the organization reaches a certain size, you need this. Tickets are good because it forces the requesting party to put down in writing what they want. This is a necessary step to ensure that right work is done, and it leaves and audit trail, for future people to see what decisions were made and what work was done. I've worked in an organization where we used a stack based method. In that case the most important thing was the last request. This isn't a good way to work, because it's hard/impossible to maintain focus.
zebraflask 5y ago
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.
- wombatpm 5y ago
  If you were just acquihired and no one high up in the BIGCOMPANY is taking an active interest in you. LEAVE. You are cannon fodder. The sooner you realize that the better off you will be. If you are contractually tied to the job, plan your exit NOW and leave the first day you can. Look around and see where your former leaders are now? Are they gone or in positions of power? If no BIGCORP employees are reporting to them then you know the writing is on the wall. Leave.
kk6mrp 5y ago
> 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!
megablast 5y ago
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??
vsareto 5y ago
>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.
spike021 5y ago
>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).
conductr 5y ago
Also, know that as an acquired company and requests you submit are lower priority that the core company workload.
NikolaNovak 5y ago
Agree and to elaborate : the companies will have radically different speeds goals processes priorities methods and cultures. Bluntly, you can be shocked and incredulous, or you can attempt to understand empathize learn and adapt. Approaching the engineer and being surprised they shunt you to the manager for example - I sense that you are genuinely surprised. Fair enough. But from their perspective - it's a big company, lots of requests, lots of priorities, and they likely feel (rightly) it is their managers jobs to shield them from every enthusiastic energetic requestor in a large company. They are required but also judged based on completing assigned priorities. It is a survival skill to focus on those and ignore distractions and random requests from random people. Similarly, you seem surprised you can't touch their code. You think about speed of development. They likely think about development standards, quality, supportability, maintenanability - and ultimately liability. If a random person from random team implements a random thing in their code... And if they let everybody do it (fight personal exceptionalism; if you want to do it everybody wants to do it), what state will their code be in? Q1 2022 could mean anything. Large companies have freeze periods particularly holiday season. And they can have deep pipeline - your thing may or may not be a few days (pardon me but we as developers are notorious for being optimistic :), but may take a while to get to front of queue and then may need to go through formal stages. There are reasons startups have high velocities. But there are also reasons why large companies have high conservatism - ultimately like any other Conservativism it's because they don't want to muck the status quo - they have more to lose.
- biztos 5y ago
  Agree with both of you, and for the OP: Q1 2022 sounds pretty good in my experience! A team you don't know much about, that has an unknown set of priorities and an unknown backlog of work from your perspective, and which has its own standards to uphold, and which probably interacts with a bunch of teams just like yours and thus has to consider the long-term implications of any feature creep -- that team is promising to get your change made in (allowing for holidays) less than one quarter? At a Fortune 500 company that's a sign that you are being given a lot of respect, now try to make sure your team doesn't mess it up and make that deadline slip.
jjav 5y ago
Definitely second the idea of taking it as a learning experience! It might be possible that the large company is completely disfuctional (but... they grew to be large enough to acquire the startup, so must be doing something right). But when the OP says they've only ever worked on startups... that tells me this is almost certainly about OPs lack of experience working in a company that values product quality and stability over "move fast and break things". So I'd suggest to work there for a while (at least a year or three) to learn how stable organizations operate and why. It's a different skillset that OP doesn't have (by virtue of having only worked in startups). Some people can only deal with the startup phase, that's ok too. But it's nice to decide that from a position of experience. Everything in the story is quite reasonable! The engineers can't be taking requests from every rando that walks by, that works in a <50 person startup but not so much (not at all) if they have like a 10+K person engineering organization. An important part of their managers job is to run interference so they can get work done instead of listening to requests all day long. "No response after two days"? At a largish company where I had such a request queue, we'd only read and triage them once a week. Anything more frequent would be too distracting. So two days is quite a good response time. "end of Q1 in 2022": That's a pretty quick turnaround I'd say. Surely the engineering team isn't sitting around waiting for OPs requests, they have many weeks/months of work already in the queue. "I tell him I'm happy to fix the issue myself" - That can't work at all in a large company. Just imagine if again any rando can go and push changes into any codebase they don't know anything about. Are you taking responsibility for all consequences? Even if you say yes, you can't because you don't have the authority to do so. If your change breaks some customer somewhere, the management chain who owns that codebase will be in trouble for allowing such an out of band change to get merged. I've been in 5 startups, a couple of them ground-up with just a few people. But have also spent well over ten years in 50K+ and even 100K+ people organizations. Different needs, different processes, different skillsets. It's nice to try them all.
WastingMyTime89 5y ago
Having worked for years in large companies including in the public sector, your comment made my day. Everyone having experienced this kind of environment and not forced to drink the company kool-aid to advance their career knows the actual reason things take ages are far less positive especially when the request comes for a recently acquired team. Also bypassing process is the only way to truly achieve anything at very large corporations but doing it properly take skills. Unless you are stuck there for reasons linked to your compensation or find you now want to work a lot less, provided you are good at building things in a startup environment, my advice is to leave as fast as you can.
_3u10 5y ago
Ahh the lifer life.
shaan7 5y ago
Can attest to this. Well not me, talking from experience from a friend. She keeps telling me about engineers from the startup that "they" acquired. Her team is already overloaded by requests from a bunch of other teams that they try their best to prioritize and deliver - it is hard work. Even after that they get comments like OP "This is a simple change, why will it take a week?", "I can just finish this in few hours and submit a patch". I guess it takes a while for people to learn that writing code is only 5% of the effort, the rest of it is review, testing, QA, E2E, compliance and what not. There sometimes is unnecessary bureaucracy as well, but that doesn't mean that the actual engineering processes are useless.
crispyambulance 5y ago
> 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. The problem is that "learning the ropes" in a big org is often just an interminable slog of suffering from lack of information, dead-end rabbit-holes, and dealing with assholes. One is often forced to choose between being a doormat or being offensively aggressive with little ground in between. In the context of an acquisition, especially, staff on both sides will be in fear of losing their jobs, status, or comfort-zone. There will automatically be barriers put up against change whether folks are conscious of it or not. The OP just needs to talk to a human being. It's his responsibility to reach out and find one. In my experience, the thing about big-company process is that YOU HAVE TO go around it to communicate. You have to talk things out with the RIGHT people in advance, come up with a plan in cooperation with them, have them collaborate by getting things warmed up on their side. After all that the stupid meetings and "approvals" are just formalities. In fact, you can tell when this is the case when project decisions are handled with almost parliamentary procedures. There's no room for discussion and thinking things through in such meetings-- everything, EVERYTHING, has to be worked out in advance through side-channels.
mmcnl 5y ago
Indeed. Large organizations have prioritization issues. You need to explain impact so the manager(s) can prioritize, don't discuss technicalities (known unknowns).
mbrodersen 5y ago
Let’s compare two large organisations: NASA and SpaceX. According to astronauts who have worked for both, it takes a year to get a simple UI change implemented when working for NASA, and it takes one day when working for SpaceX. The difference is bureaucracy. Not the amount of actual work that needs to get done.

by _skel 5y ago

rpeden 5y ago

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.

isbvhodnvemrwvn 5y ago
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.
dpark 5y ago
> 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 5y ago
  [deleted]
- masklinn 5y ago
  > If it’s only a few days for an infrastructure change, why is it so untenable to modify the app? It could be an incompatibility with a core requirement e.g. application used webrtc or websocket, bundling / deployment system can’t handle them (will reject / close on upgrade requests or long connections), you’d have to rearch the entire product, probably detrimentally to the system / experience.
  - dpark 5y ago
    Certainly something like that is possible, but I don’t think so given the way OP wrote about it. Especially lines this this: “the deploy tooling isn't entirely compatible”. That doesn’t sound like a critical missing feature (which would somehow be cheap to add). It sounds like a fairly minor roadblock that he expected the other team to solve for him. My guess is that it’s one of those things that might take the other team a week and would take OP 2-3 weeks, so in a little start-up, the other team would obviously do it because it’s more efficient. But in a big corp, asking the other team to make the change is kind of like asking AWS to make the change. (Which could be the case if Amazon is the big corp in this story.)

laluser 5y ago

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 5y ago

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/uloosesignificance166_explains_how_he_stopped_a/?ref=share&ref_source=link https://www.reddit.com/r/bestof/comments/rkru22/uloosesignif...

meigwilym 5y ago
I immediately thought of this as well. Great minds etc.
ascar 5y ago
Direct link https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_supervisor_and_my_direct_reports_are/hpacf5h/ 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 5y ago
  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 5y ago
    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. :)
    - isbvhodnvemrwvn 5y ago
      I 100% guarantee it's someone who has recently read "The Phoenix Project" and made it up based on that.

achillesheels 5y ago

>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 5y ago
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.

CogitoCogito 5y ago

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

Sevii 5y ago
Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.
- kuraudo 5y ago
  I was going to say the same thing here. It amazes me that the company I always assumed was massive, slow, and bloated actually moves at the speed of light compared to op's acquiring company.
tyre 5y ago
> 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.

fiachamp 5y ago

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 5y ago
if your startup ever makes it to any sort of scale, it will likely have the same problems -- they all do :)
- maerF0x0 5y ago
  and you're lucky if you can actually tell what the real problems are, because mostly I find people are chasing symptoms these days.
- jimjimjim 5y ago
  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.
- chris11 5y ago
  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.
- toast0 5y ago
  And when it reaches that stage, the OP can nope out to another up and coming startup. There's no reason someone needs to stay at a company through its whole lifecycle.

rjzzleep 5y ago

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

endymi0n 5y ago
...or commonly phrased by my ex manager when I loudly complained about something as "love it, change it or leave it". It was a hard truth to swallow, but rationalizing it, I quickly realized all other reactions to adversity are pretty pointless indeed. There are people who thrive in large orgs and then there's others... eventually I realized there's simply no way I'll ever make peace with bureaucracy. I can stand brilliant chaos and long, hard hours among talented people better than being a smart cog in the wheel who effectively does 50% of a 9-5 gaming the system and playing solitaire otherwise. Everybody needs to choose their poison.
- fargle 5y ago
  run, hide, fight
dnissley 5y ago

lojack 5y ago

> 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 5y ago
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 5y ago
> 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.
- lojack 5y ago
  I also said: > Similarly, the work OP is doing may be much less important than they think it is.
mateo411 5y ago
> Queues are an inappropriate construct for managing work. I disagree. A queue is used to assign priority to a project. When there is more work than people to do the work, you need to prioritize and triage. Just because there is a queue doesn't mean that you can't handle urgent work. You can move it to the head of a queue. Usually what accompanies a queue is a ticketing system. Nobody like these, but when the organization reaches a certain size, you need this. Tickets are good because it forces the requesting party to put down in writing what they want. This is a necessary step to ensure that right work is done, and it leaves and audit trail, for future people to see what decisions were made and what work was done. I've worked in an organization where we used a stack based method. In that case the most important thing was the last request. This isn't a good way to work, because it's hard/impossible to maintain focus.

zebraflask 5y ago

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.

wombatpm 5y ago
If you were just acquihired and no one high up in the BIGCOMPANY is taking an active interest in you. LEAVE. You are cannon fodder. The sooner you realize that the better off you will be. If you are contractually tied to the job, plan your exit NOW and leave the first day you can. Look around and see where your former leaders are now? Are they gone or in positions of power? If no BIGCORP employees are reporting to them then you know the writing is on the wall. Leave.

kk6mrp 5y ago

megablast 5y ago

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

vsareto 5y ago

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

spike021 5y ago

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

conductr 5y ago

Also, know that as an acquired company and requests you submit are lower priority that the core company workload.

NikolaNovak 5y ago

Agree and to elaborate : the companies will have radically different speeds goals processes priorities methods and cultures. Bluntly, you can be shocked and incredulous, or you can attempt to understand empathize learn and adapt. Approaching the engineer and being surprised they shunt you to the manager for example - I sense that you are genuinely surprised. Fair enough. But from their perspective - it's a big company, lots of requests, lots of priorities, and they likely feel (rightly) it is their managers jobs to shield them from every enthusiastic energetic requestor in a large company. They are required but also judged based on completing assigned priorities. It is a survival skill to focus on those and ignore distractions and random requests from random people. Similarly, you seem surprised you can't touch their code. You think about speed of development. They likely think about development standards, quality, supportability, maintenanability - and ultimately liability. If a random person from random team implements a random thing in their code... And if they let everybody do it (fight personal exceptionalism; if you want to do it everybody wants to do it), what state will their code be in? Q1 2022 could mean anything. Large companies have freeze periods particularly holiday season. And they can have deep pipeline - your thing may or may not be a few days (pardon me but we as developers are notorious for being optimistic :), but may take a while to get to front of queue and then may need to go through formal stages. There are reasons startups have high velocities. But there are also reasons why large companies have high conservatism - ultimately like any other Conservativism it's because they don't want to muck the status quo - they have more to lose.

biztos 5y ago
Agree with both of you, and for the OP: Q1 2022 sounds pretty good in my experience! A team you don't know much about, that has an unknown set of priorities and an unknown backlog of work from your perspective, and which has its own standards to uphold, and which probably interacts with a bunch of teams just like yours and thus has to consider the long-term implications of any feature creep -- that team is promising to get your change made in (allowing for holidays) less than one quarter? At a Fortune 500 company that's a sign that you are being given a lot of respect, now try to make sure your team doesn't mess it up and make that deadline slip.

jjav 5y ago

Definitely second the idea of taking it as a learning experience! It might be possible that the large company is completely disfuctional (but... they grew to be large enough to acquire the startup, so must be doing something right). But when the OP says they've only ever worked on startups... that tells me this is almost certainly about OPs lack of experience working in a company that values product quality and stability over "move fast and break things". So I'd suggest to work there for a while (at least a year or three) to learn how stable organizations operate and why. It's a different skillset that OP doesn't have (by virtue of having only worked in startups). Some people can only deal with the startup phase, that's ok too. But it's nice to decide that from a position of experience. Everything in the story is quite reasonable! The engineers can't be taking requests from every rando that walks by, that works in a <50 person startup but not so much (not at all) if they have like a 10+K person engineering organization. An important part of their managers job is to run interference so they can get work done instead of listening to requests all day long. "No response after two days"? At a largish company where I had such a request queue, we'd only read and triage them once a week. Anything more frequent would be too distracting. So two days is quite a good response time. "end of Q1 in 2022": That's a pretty quick turnaround I'd say. Surely the engineering team isn't sitting around waiting for OPs requests, they have many weeks/months of work already in the queue. "I tell him I'm happy to fix the issue myself" - That can't work at all in a large company. Just imagine if again any rando can go and push changes into any codebase they don't know anything about. Are you taking responsibility for all consequences? Even if you say yes, you can't because you don't have the authority to do so. If your change breaks some customer somewhere, the management chain who owns that codebase will be in trouble for allowing such an out of band change to get merged. I've been in 5 startups, a couple of them ground-up with just a few people. But have also spent well over ten years in 50K+ and even 100K+ people organizations. Different needs, different processes, different skillsets. It's nice to try them all.

WastingMyTime89 5y ago

Having worked for years in large companies including in the public sector, your comment made my day. Everyone having experienced this kind of environment and not forced to drink the company kool-aid to advance their career knows the actual reason things take ages are far less positive especially when the request comes for a recently acquired team. Also bypassing process is the only way to truly achieve anything at very large corporations but doing it properly take skills. Unless you are stuck there for reasons linked to your compensation or find you now want to work a lot less, provided you are good at building things in a startup environment, my advice is to leave as fast as you can.

_3u10 5y ago

Ahh the lifer life.

shaan7 5y ago

Can attest to this. Well not me, talking from experience from a friend. She keeps telling me about engineers from the startup that "they" acquired. Her team is already overloaded by requests from a bunch of other teams that they try their best to prioritize and deliver - it is hard work. Even after that they get comments like OP "This is a simple change, why will it take a week?", "I can just finish this in few hours and submit a patch". I guess it takes a while for people to learn that writing code is only 5% of the effort, the rest of it is review, testing, QA, E2E, compliance and what not. There sometimes is unnecessary bureaucracy as well, but that doesn't mean that the actual engineering processes are useless.

crispyambulance 5y ago

> 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. The problem is that "learning the ropes" in a big org is often just an interminable slog of suffering from lack of information, dead-end rabbit-holes, and dealing with assholes. One is often forced to choose between being a doormat or being offensively aggressive with little ground in between. In the context of an acquisition, especially, staff on both sides will be in fear of losing their jobs, status, or comfort-zone. There will automatically be barriers put up against change whether folks are conscious of it or not. The OP just needs to talk to a human being. It's his responsibility to reach out and find one. In my experience, the thing about big-company process is that YOU HAVE TO go around it to communicate. You have to talk things out with the RIGHT people in advance, come up with a plan in cooperation with them, have them collaborate by getting things warmed up on their side. After all that the stupid meetings and "approvals" are just formalities. In fact, you can tell when this is the case when project decisions are handled with almost parliamentary procedures. There's no room for discussion and thinking things through in such meetings-- everything, EVERYTHING, has to be worked out in advance through side-channels.

mmcnl 5y ago

Indeed. Large organizations have prioritization issues. You need to explain impact so the manager(s) can prioritize, don't discuss technicalities (known unknowns).

mbrodersen 5y ago

Let’s compare two large organisations: NASA and SpaceX. According to astronauts who have worked for both, it takes a year to get a simple UI change implemented when working for NASA, and it takes one day when working for SpaceX. The difference is bureaucracy. Not the amount of actual work that needs to get done.