Ask HN: New job at BigCo. Everything has friction

I your case, was the fortune a product of starting your own company or working at a smaller one?

Yes, bring the hacker ethos to the system. You’re not fighting code you’re fighting the system.

Need that SSL cert? Request it a month before you need it.

Need that column in the table? Request it long before you need it. Didn’t end up needing it? Sell it to another team, sure it might not be named what they want but they can use it today.

This sounds suspiciously similar to where I used to work, and was one of the reasons I left. Every project required working with 3-5 other teams for either help or 'alignment' (aka approval). Getting a new service live required many tickets, meetings, manual edits to configuration by other teams, etc.

I think large companies with low friction are the exception, not the rule. It takes MASSIVE amounts of work to build the infrastructure that thousands of engineers need (or be willing to spend millions of dollars for SaaS). I can think of only a few large tech companies with low friction (Google, Netflix, Meta), and they spend a lot on tooling.

There's a few ways to deal with it. What I noticed was that the 'effective' engineers would avoid the standard process and be 'noisy'. They were comfortable asking directly via chat or in person for what they wanted instead of filing tickets or having meetings. They used their relationships (which they did work to build) to skip the line and save time.

You also need some kind of perspective change at large companies. You've moved from rowing your own boat to a battleship. Process is there for protection from rogue employees wreaking havoc on the system, not to make you move fast. Think of it from a manager or platform team's perspective. How do you manage over 1,000 SSL certs (and renew them)? Prevent VM proliferation that needs to be accounted for and secured? Certainly it can all be automated, but at a BigCo's scale, that is a 4-5 person job, and that team is competing with other 'revenue generating' teams for headcount.

I would also recommend to give it some time. You will adjust and learn over time how to work more effectively. I noticed after a few years that I could grease the wheels a bit because I had spent time cultivating relationships with various teams.

Good luck!

I've worked at both relatively large (thousands of employees) and small (less than 10) companies. When I transitioned from small back to large-ish about 10 years ago, a couple things struck me. (Really, I was reminded of because I had worked at a similar magnitude size company previously.) There was so much "machinery" to support me in various ways. But the internal communications to take advantage of that machinery (and to inform stakeholders, the field, etc.) was a huge ongoing effort.

> accomplishing things

[I also ended up at a BigCo along with others from a small startup that pivoted multiple times after making v1 products that could have been successful.]

What I learned is to reframe expectations. At the startup, I could develop software and features rapidly with no impediments than my own lack of knowledge in an area. At the BigCo, the product is large, changes are slow, and processes are safe. The payoff though is that when you do ship that feature, it's being used by thousands-to-millions more users than it would have been at the startup.

At the same time, all the one-off things I used to do at the startup should have been streamlined at the BigCo so that I can think primarily about the problem I'm trying to solve and not the peripheral routine elements of every service that gets shipped. If this is not the case, perhaps the BigCo's processes are not very well streamlined.

I've found some ways to adapt, but some things still take much longer than they should, like PR reviews (but I'm also guilty of being a slow reviewer).

> emotionally exhausting

This is because you have an expectation that a certain thing should only take a certain amount of time and effort.

The best general advice is to work on multiple things concurrently, so that when one thing has delays you can switch to another one that's ready for work.

You have to decide whether you want to actively improve these inefficient processes, accept them, adapt, or move on. Anything else will be suffering. If you move to another BigCo the annoyances will be different more to your liking, or not.