Hacker News Reader

Comment by _skel | Hacker News Reader

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

View on HN

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

I immediately thought of this as well. Great minds etc.

Direct link

https://old.reddit.com/r/antiwork/comments/rkk9qg/im_a_new_s...

for everyone else having a hard time figuring out how to find the actual comment.

Really worth a read and absolutely puts OPs story into perspective.

Yeah that story is total bullshit. It's someone's fantasy. The equivalent of me telling the story of my epic comeback in the Superbowl.

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

I 100% guarantee it's someone who has recently read "The Phoenix Project" and made it up based on that.

He even referenced the Phoenix Project ;)

Now you understand modern book marketing. :-)

Wait...are you suggesting that whole comment is actually just an ad?

While I have no evidence in this particular case, if I wanted to promote a book, I could imagine making up a related, positive story, which just happens to mention the book positively, and posting it on a popular social media site (I put the book in my cart). Then one could follow up with a softball opposing story on another site to get some controversy and thus visibility.

Probably someone will cross link for you (I thought about doing that when I saw the headline). If not, a sock puppet can point out the link, and the book, again.

TBH these two stories have the exaggerated perfection that characterizes fake stories. And the fact that they arrived so close together makes me very suspicious.

I mean I read it and thought about looking up the book and getting it

I did like the book, back when I was completely new to DevOps. It's also a fictional story in the same vein as the one on reddit basically same template, but more mystic. Explaining DevOps through a story.

Now I'd suggest to just read the state of Devops reports by Google, they are excellent.

This is not an ad and I doubt it is fake. Click on the user profile and read some of his other comments. This guy is real.

Completely agree. I knew they'd link to the Phoenix Project at the end

If so, I’m even more impressed.

When I first encountered the Phoenix Project, I was expecting it to be some kind of satire. It wasn't, it was played straight all the way through and ends with "a win".

It blows my mind that someone could write a novel about work and NOT have it be a satire or dark comedy. This book is used in project management courses, by the way.

Why? Maybe it’s that you’ve never worked for a boss that fought that hard for your free time?

Great bosses like this exist

The manager maybe, but you don't change the culture of the company like that. A low level manager has very little influence on that, they'd be replaced the moment other VPs started complaining.

Depends on the on the exact political arrangements. I’ve seen a “low” level manager get the ear of a senior leader and get protection/empowerment that ended them to do something on par with this. It sounds like the author got the appropriate buy in, and I suspect that not all ad hoc work got prioritized in a FILO manner.

It sounded implausible to me. Admittedly I don’t work for a large corporation but this sounded like a socially challenged persons dream of how they’d convince large groups of opposing people to their side. Hostile interactions with shelter from an all powerful HR and the vague threat of a lawsuit.

I've explicitly asked for strong barriers from external leads and developers from my manager before and gotten them. My current boss aggressively puts barriers in place to keep us from being bothered or distracted.

Why? I do this stuff all the time as a manager. It really goes exactly that way. Notice that the reddit commenter started with getting buy-in from the higher-up in their org. He didn't unilaterally start changing process.

This is honestly basic management technique. It is called the "Auntie/Uncle" problem.

I’m having a bit of trouble what “Auntie/Uncle problem” is in reference to. My Google search are just a bit too generic to narrow in. Any chance you know of an article on the subject I can read through?

You might consider providing a link, since Google returns absolutely nothing about management relating to “Auntie / Uncle” as a search term.

I could see it happening where I work (Large Multinational in the Energy Industry). HR are removed enough that they would back this up, yet have the authority. Teams often report by function, therefore there isn't a local manager worried about the missed deadline. Combined with the companies image as attempting to be a leader in social responsibility (at least as much as an Oil and Gas company can). I can see it happen however I don't think I could see it in any of the smaller companies I have worked for as the results of missing deadline were frequently too significant.

That being said my current employer is exactly like the one mentioned by OP here. You basically need to build credibility internally to deliver.

Reddit is 90% LARPing when it comes to situations like this - it's obvious once you see it, and once you see it you can't unsee it ever again. It's like getting vaccinated against a sickness.

It's pretty hard to imagine HR intervening in business operations to protect a single department's work-life balance - couldn't really track it from there.

odd that most in this thread think this story is fiction, some even suggest it might be a marketing ploy to peddle a book. Is really the whole world like this or is there a difference depending on jurisdiction (e.g. comments reflect values of US?).

While I can't prove a negative, this story is highly plausible in Europe where legal/HR will be on your ass and even fire the CEO if it turns out they had knowledge.

In 2020 I was in a similar situation with an IoT "startup" (70 people) in Austria where some of the original founding team worked their employees in a brutal manner (made fun of the engineering providers that invented the product in a "low-cost" neighboring country, and being total f-heads all around).

My superior even made fun of one intern for "stuttering" in front of the whole team, scolding him for "sloppy thinking" and being "too slow in his head" (fact was he wasn't used to speaking English, was a bit insecure because he was still very young). People regularly cried.

That was just the internal stuff. In my first weekend in this firm I was given new tasks on Friday 16:00 to finish until Monday 08:00 (tasks so complex that it would normally take a whole week to finish and required multiple rounds of input). I had no free weekend in my first month and 12/hrs per day was the norm. In my first client meeting 2 days into the job I learned that my company lost all their data 3 months before ... genuinely curious I started probing the client to get a better picture of how we were perceived. The client talked himself into such a rage that he ended up screaming at me (and a day later apologizing for doing so).

2 weeks after I joined, I wrote a long letter to HR with a list of all the communication that happened, e.g. who said what to me when, and even smtp headers of communication received in an appendix. After the CEO asked me to lie on a revenue forecast that served as input to the business plan (and where I was told "to make up numbers" !!) I looped in the Holding company into my ongoing conversation with HR (the holding was where my employer got all their funding and who would be the audience for that pitch in the presentation/Excel I was asked to make).

It was the first time that I ended up (literally) screaming with my own superior in a meeting for abusing his own team, and spelling out immediately why his behavior was abuse. 2/3 of my team left that very month since they were fed up and I like to think it was me that spelled out for everyone what they already knew but hadn't ever thought to verbalize themselves.

I also handed in my resignation a week afterwards since it looked like some people would be able to get away with it. The Holding Company brought in an external consulting / auditing team and fired the CEO and 2 others. Alas ... not for mistreating or overworking employees but for lying on the business plan. This October (2 quarters later) the same company filed for bankruptcy.

I don't know if I would be able to bring down an equally rotten place in a different jurisdiction. YMMV sadly and I am sure many people try in other places but all they ever achieve is that those responsible get a "stern warning". But I totally believe the linked article to be plausible

EDIT: rediability

> Alas ... not for mistreating or overworking employees but for lying on the business plan.

Business plan can be easily marked a “mistake out of sloppiness” if you don’t want to fire people.

Abuse is bad for the image and evidence collection takes ages (and hence is expensive).

Lying to the board works much better to get rid of people fast. I would bet you weren’t the first startup to do a bisserl of Zahlen frisieren.

The disbelief and learned helplessness in this thread is a really disheartening view into the state of modern american work

Reddit in particular is infected by this kind of toxic thinking. One on the one had, I think individuals hate being fooled, and so there’s a rush to decry any remarkable or interesting anecdotes as “bullshit”. In this case in particular, I suspect the disbelievers are stuck in soul-sucking jobs they hate, and one way they cope with that is by truly believing that everyone else in the world is in a similar situation.

Its such a strange, depressing way to approach content imo. Did the story happen? Maybe, maybe not, we can’t know for sure. Do I want to believe it happened? Yes. Are there valuable aspects in the story that I can learn from and potentially use in future? Yes, absolutely. Is there any harm in me choosing to believe his anecdote is real and it’s actually made up? No, I don’t think so.

There’s actually a whole subreddit on this topic https://reddit.com/r/nothingeverhappens

Also, don’t get me wrong — there is plenty of fake content, or implausible content, that is worthy of skepticism because it has a nefarious agenda, fosters misinformation, etc. But sometimes people just need to chill out.

An argument that it's plausible that almost all remarkable or interesting anecdotes that you read on Reddit are fake: https://slatestarcodex.com/2016/12/12/might-people-on-the-in...

I'm not sure if I believe this, and I certainly don't think it has much to do with the existence of r/thathappened (which does indeed seem much more rooted in people's fear of having been a sucker). But it's interesting to think that the basic intuition of "true stories are more common than fake ones" might be misleading with respect to Reddit in particular, because of the specifics of how Reddit works.

(The point about it being harmless is unpersuasive to me; I want to believe that a given story is true if and only if it is actually true.)

Wow, thats a truly excellent comment. Everyone who manages people should read that IMO.

If only it had any basis in reality.

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

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

run, hide, fight

The three A's line up perfectly with the options presented in the influential book "Exit, Voice, and Loyalty".

https://en.m.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty

Not implying this is the case for OP, but there is also:

3. Acquire potential competition to get rid of them. There are cases where the parent company never intended to develop the startup's product, but simply wants to keep the startup from competing with them.

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.

if your startup ever makes it to any sort of scale, it will likely have the same problems -- they all do :)

and you're lucky if you can actually tell what the real problems are, because mostly I find people are chasing symptoms these days.

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.

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.

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.

true, I've done similar in my career. IME your growth potential and earnings potential can peter out when you do this though. YMMV

SpaceX seems to do just fine?

do you work there? would be interesting to hear how you believe it's different and why. if not, then I think "just fine" is probably conjecture, and I'd imagine they have the same problems as everyone else at scale.

SpaceX clearly has no problems innovating and moving forward fast. Something you don’t see in more bureaucratic organisations. I saw an interview with astronauts who has worked for both NASA and SpaceX and they said that the big difference was that what would take a year for NASA took a day for SpaceX.

Sorry to say, but there are plenty of companies with absolutely atrocious internal cultures that still manage to innovate and move forward fast, I've had the misfortune of working for a few LOL

I can believe that. What does that have to do with working for a bureaucratic organisation? NASA innovates. It just takes forever compared with non-bureaucratic organisations.

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.

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.

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.

> Established businesses are trying to keep employees from knocking over that functional house of cards.

And usually also spend the next 10 years cleaning up the total mess of a house of cards from the startup phase into a more manageable and stable house of cards.

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

Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the company gets sued? Your $BIG_COMPANY is not putting this change request through ultra-scrutiny just to frustrate you.

First, the team needing to do the work has about 10X as much work waiting in their queue than they can possibly do given their staffing. So your request either has to be more important than the existing work, you need to get a VP to expedite it, or you need to wait. It's not like there's an engineer just sitting there picking his nose browsing Facebook waiting for work. And even if you just yeet them a patch, they will need to set aside engineering time to review that patch, so back of the queue it goes, too.

Second, that work needs to go through (sometimes multiple) code reviews, have unit and integration tests written, and be able to show those test passing more than once, it needs to get reviewed by legal so it doesn't expose us to legal liability, it needs to get reviewed by security so my 9 year old can't use it to get a root shell, it needs to get reviewed by privacy/data protection so we know it's not leaking some user's personal information, it needs to get a systems review so we know it won't disrupt other critical revenue-generating services. I mean, what are you expecting, just type the code in, run a few tests, any yolo it into production?? No way.

A fantastic and experienced reply. OP, please listen to this

> it needs to get reviewed by legal so it doesn't expose us to legal liability

I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?

Usually it is more like "legal needs to be notified anytime third party dependencies are updated with a list of the licenses to make sure we aren't accidentally using GPL or proprietary code".

Other times legal gets involved earlier at the planning stages in case a feature or product falls under HIPAA or similar regulatory framework.

Actual code itself doesn't cross legal's desk anywhere that I know of.

The setup I saw is: there is an IP plan that documents whatever 3rd part IP you are using in your product (open-source or not). Someone has to sign-off on that plan, and sometimes developers do self-attestation that they have not deviated from it. Additionally, the binaries are scanned for certain things to avoid escapes of pre-release information, etc.

Our legal team has to review parts of our application to ensure we were in compliance with certain government programs such as ITAR and EAR. They don't do code level review but they do review business processes, UI's and messaging to make sure we're in compliance.

There is no code review by legal. There is a talk, usually multiple talks, between legal representatives and the engineers + manager delivering something. It's the engineers and manager job to explain what the piece of work will do and help legal understand its implications so they can gather knowledge and come up with their assessment given their skills in Law.

I think you read it too literally, legal will review what is the impact of some changes in compliance and so on but you, as an engineer, is responsible to translate what the code/feature/system is doing to something that legal can understand and reason about, it's part of your job if you are anywhere senior+ level.

I had to interact quite a lot with legal in my past couple of jobs, it wasn't ever an issue because the legal department seemed to be staffed with smart people that would understand what I was telling them, or would ask relevant questions to clarify their understanding, it's a two-way street, not a button to push on the PR to "ask for legal review".

Let's also not forget the value of having a person sitting there doing just the bare minimum needed to have some familiarity with where things are and what does what... so if something does blow up (and it will), (s)he can instantly step in and take emergency measures to restore service.

It's called 'reserve capacity', and some people think it is helpful

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

To be honest, SME remain the economic backbone of most modern countries and the size of SME still allow them to operate somewhat effectively. Most large companies are either slowly drifting to irrelevance, surviving on a steady diet of acquisitions from teams who could previously achieve things or milking a business line they established when they were smaller and somewhat nibble. Large companies successfully growing by building what you call important stuff without acquiring are the exception.

Working backwards from your label, what signs leading up to Facebook's recent outages could we have used to evaluate them as being or not being a "mature company"?

I think, perhaps, that being siloed, bureaucratic, large, profitable, and management heavy are not the best or only qualifiers of "maturity".

Given that the entire tech industry is built on making money with tools and services that are not useful to the society, it's only fair their employees take the mantra and apply it to their professional sphere of influence.

Totally agree. Would love to hear more about what you're thinking about. Didn't see your contact info listed. How can we keep in touch?

As much as this sentiment feels natural for an engineer there are a few things to keep in mind:

* you get exposed to a wider range of technology at a startup and can work on different things; that's more fun for you personally especially when you're under 30 yo and still learning the ropes; political indoctrination is mostly non-existent

* many startups at best get acquired; so all your "useful" efforts could end up in /dev/null or be completely replaced after the next VC round

* a minority of startups are doing real tech that's worth tolerating small company inconveniences; for every Imply/Rockset/Starburst there are many more companies building another web app, likely using inferior programming languages

* Big Co compensation and benefits are unbelievable for people coming from startups. Work/life balance cannot be compared too. Unlimited PTO could actually be European-style 4 weeks. I believe there were not so many posh places to work at ten years ago and so it was less realistic to join one.

* there's no question that startups and large corporations require dramatically different mindsets/habits. But you really get paid a lot to tolerate that smaller-than-a-tiny-cog feeling.

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.

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.

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

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

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

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

As a former SRE and tech lead for some OPS teams, I agree.

Sometimes they are actually little but will create divergent states for your code/infrastructure, increasing complexity and cognitive load on the team maintaining infra, slowly but surely.

In my experience with infrastructure on larger organisations it will require, at some point, to standardise practices and processes, and it will be painful for teams that don't fit squarely with the standard. You always aim to embrace 80-90% of the components in the organisation (or at least 80-90% of the most profitable/important ones) and take the hit that 20% will require modifications, as extensive and costly as they might be.

It's always a juggling act, engineers with the mindset of building whatever/however they want will feel less empowered when their favourite set of tools, tools that they might be using for a while, isn't supported by the standard. Some teams will take a lot of the load to adapt to whatever was agreed as a standard, churn will inevitably happen in those teams so it requires a long time deliberating what is acceptable or not. The job is always to strive making everyone as equally unhappy as possible because it's impossible to please everyone.

Those little requests might also have impacts and implications much larger than what the requester thinks about, when your infrastructure system is supporting 200+ teams any change is bound to cause ripple effects so you have to be deliberate.

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

Away team work is standard at Amazon. Of course you still may have to go to office hours and sign up for busy teams.

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.

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

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)

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

> * There is no compliance reason why OP couldn't have read access to look at the source.*

At a guess, I would say you have never worked with DRM integration. Getting access even to the binary SDK's can take months, and if you ever need the special license to work with the thing on source code level, prepare for a delay of several quarters.

Long time ago, Nokia was integrating Microsoft's DRM. I got to witness first hand the red tape needed to allow a new person to even see the source code the team worked with. And this was thanks to requirement MS imposes on their licensees.

The other code I know of that was heavily siloed were Nokia's DSP codecs. Pretty sure there were other corners with similarly absurd external restrictions but at least I was never exposed to them.

My closest experience was working with SDK of CCTV system. Which, after six months of waiting for legal, ended up being the ugliest and most obtuse codebase I've ever seen.

Thankfully, it was an optional side project at work, so I was able to step away and make more progress elsewhere.

But it also substantially reinforced my opinion that... if you need to keep a codebase secret... it's probably not a good thing.

And yes, I realize it is sadly endemic in the embedded world, for reasons both good (firmware secrets) and bad (artificial moats and controlling integration and compatibility).

The real reason is that the manager doesn't care at all, and it takes a lot less effort to say no than yes.

Or having worked on a platform team - you still need resources to at the very least review the change.

And it is on you and not these folks if something breaks in production.

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

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.

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.

Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)

The full explanation is on the inner source patterns website: https://patterns.innersourcecommons.org/p/30-day-warranty

Heaven forbid someone introduce a popular feature into an internal tool. I do know the concern here, but it seems to miss the forest for the leaves on the trees.

At scale, if you let everyone do this, suddenly you're maintaining 50 features that were contributed and are each used by...two teams. Ownership with contributions requires really strong culture. (this is the same reason that you don't always see a PR just approved to an open source library.)

You mean just like when someone thought it was a cool feature to have JNDI lookups in Log4J ?

Are you going to assume ownership of that change if it breaks in production at any point and the team needs to provide support? Because I surely don't like owning pieces of critical code that wasn't implemented/explicitly maintained by my team, doing code archeology while putting out fires caused by 3rd parties' code is in the not-so-much-fun category of work.

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

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.

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

If the other team lets you do the work, who's going to review it, explain the codebase to you and, by FAR the most important thing: who's going to maintain it when it breaks? Are you commiting your team and your time to a response when a bug appears with your code or when it needs to be migrated?

That's pretty much the same issue as FOSS maintainers have with random drive-by patches - someone needs to still maintain that stuff in the future and in 99% the original owner fscks off by that time leaving the original team to deal with their artsy hacky creation.

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

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.

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

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

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.

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.

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

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.

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

I also said:

> Similarly, the work OP is doing may be much less important than they think it is.

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

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

How can OP, as an engineer, or anyone else, that just joined a much bigger organisation, have any clue that a company is doing work that they shouldn't be doing AND they are doing it in a wrong order?!

Good leadership that sets clear direction and initiatives followed by good middle management that takes these initiatives and disseminates it into something relevant and actionable by the teams doing the work. If you're lacking this then its worth trying to ask for this information to help inform your decisions.

For the record I fully acknowledge that this may not be possible and they very well may need to work within the system in a less-than-optimal state. Understanding the root of the problems help you navigate and ideally enact change even if it's more localized.

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.

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.

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.

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.

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

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

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.

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.

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

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.

Ahh the lifer life.

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

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.

It's both funny and sad you've got to remind that to people who post on HN of all places...

The end of a for-profit company, I will agree, is to profit, but what end is that for humanity? You imply that moral corruption toward profitable ends is of no difference to those where righteousness in action creates profitability to the owners of the business firm, e.g. honest income. What if the managers you advise working for are evil? You seem to affirm that it is not your problem so long as you are succeeding at making money. That there is no difference in profiting at a usurious bank than a charitable one, indeed to participate in the usury because it temporally rewards more, when in fact there naturally is.

I think you missed the part where I said this was not moral or virtuous. Don't go looking for virtue. You won't find it.

If the managers you advise are working towards evil (say, they're having you find zero-days to deploy against human rights advocates in the service of murderous autocrats), by all means, stop working for them! But that's very different from the managers not being able to process your feature request until Q2 and asking you to fill out a Google Doc. This is not evil, nor will it benefit humanity to send in some patches to the other team's code and get it shipped tomorrow. Don't go looking for virtue there, either.

To reiterate my point - I'm not saying it's good that the things I'm claiming are true. But I'm saying they are true, and you'd better start by acknowledging the world as it actually is if you want to effectively improve the world as opposed to just ineffectively keeping your conscience clear. Expecting to find virtue at a for-profit business that isn't deliberately opting out of the system (and a startup that decided to be acquired is deliberately opting in) is misjudging reality. But in the same way, so is expecting to create virtue by making your employer a little more efficient at migrating VMs.

>I think you missed the part where I said this was not moral or virtuous. Don't go looking for virtue. You won't find it.

That's like, your opinion, man. There are plenty of businesses that run with integrity as a necessary motivation to sustain their future profitability. This ends up causing a more virtuous society where people do not need to tolerate evil in order to survive.

I don't buy into your argument for "effectively improving the world", i.e. one can keep a clear conscience and do extraordinarily well in life, metabolically speaking. And that's the point: the goal in life is not measured by temporal goods. But that's like my opinion, man.

What do you mean with "securing your place within the system of being successful"? Just keeping your job? Or are you talking about abandoning other goals than monetary success? I'd say that getting a win/win is more than a achievable within the "system". I.e. I get to do something I enjoy doing, while also getting payed for it. The company gets the output of my labor for a reasonable price. Everyone wins and no one is sacrificing anything.

I just mean keeping your job, but to the post above, I mean realizing that because there is no inherent virtue in a for-profit job, there is also no "corruption" simply because there's too much bureaucracy. The bureaucracy is typically in service to a functioning large organization being able to remain large and reliably make money; it's fine.

If you want to do some good in the world, it's a lot better to put up with the bureaucracy and instead direct your energy to some worthy local political cause or something. Trying to make your employer a force for good is a poor plan, because as an organization whose goal is profit, it will never be sustainably motivated by the desire to do good.

Or quit and find a workplace with a level of bureaucracy that you are comfortable with. Surely that's an option as well?

Of course you should try to adapt to a new workplace and its processes. I can't understand how you'd have a different opinion. Coming in as an outsider and trying to lead some sort of office revolution is sure to backfire.

The OP's situation is unfortunate because they didn't choose this workplace themselves (as their startup was bought), but "not being compliant" seems like a poor solution to the problem. Quitting seems more reasonable.

Reply on news.ycombinator.com