Hacker News Reader

OP, there's a lot of wisdom in this comment. I suspect you might be 20-something instead of 30-something, and in hindsight I wish I'd relaxed more. And I especially wish I'd learned to play the politics game, or at least pay attention to it. Your alliances will make or break your career at BigCo. You should make sure that your manager feels like you're directly advancing their career, not just yours.

I suggest channeling your ambition into your own projects, hobbies, and interests. If I'd spent more time making my own game engine rather than working on theirs, I'd still have it today.

Early in my career, I wasted way too much energy and emotion getting upset about things that I probably couldn't change and just didn't matter. I'm not talking about just going with the flow on everything! But I did get unnecessarily upset and angry at people way more often than I should have.

OP, I’m also a twenty something that moved from a fast paced start-up to a Behemoth.

It’s been 7 months so far and throughout the first 6 months, I have fought and resisted how BigCo operates—it left me tired and even more miserable. Within the last month however, I have stumbled across the same advice as has been given by the wise members above. This advice is invaluable, accept that within these organisations a lot is outside of your control. Rather, focus on projects, learning and hobbies outside of your work that bring you joy.

If your feelings remain unchanged within a couple of months to a year then consider making a change to another Co. Good or bad, these experiences are invaluable in helping us to decide on how we wish to pursue our careers.

Do you guys ever think there's more to life than being really really really ridiculously well compensated?

When you have a wife and kids the pressure is on earning. It’s fucking expensive to have a family.

But do both you and your wife have to be at BigCo? Maybe you could take a more flexible, fulfilling job that lets you have more time with the kids while she focuses on money. Break those gender stereotypes?

I will simply not do that

It's expensive to live in the bay area and try to do everything well.

Nobody in my family ever made more than $10/hr growing up. I turned out okay. I think. :)

There is. That's what the ridiculous compensation is funding.

From MediumCo I will say: there is a lot of friction, quite intentionally, when you go off the rails. As a backend engineer, messing with things like VMs and SSL certificates yourself is definitely way off the rails. We want that to be hard. You are supposed to be creating and iterating on services using the standard application frameworks, deployed to the standard shared clusters, communicating through the standard service mesh, etc. where all of that is handled automatically.

Make sure there's not a golden path that you're missing? Or that your reasons for departing from it are really insurmountable?

work at managed service provider

everything is a ticket

ssl is expiring,

- make a ticket for the customer,

- request a quotation,

- wait for approval,

- finally issue the cert manually,

- finally deploy it (manually, using some tool of course)

Seems totally reasonable to me.

If you can have such a structured, rote process then why isn't it just automated/self-serve? That is one thing I like about my medium-sized (public) company, you can't necessarily touch things yourself but you only wait in line for human attention if your request is somewhat unusual or actually calls for discretion and creativity.

"let's encrypt is not good enough, our customers are "enterprise", bla bla"

"Because our users are irresponsible, and will order 1000's of dollars of externally signed certificates..."

shock horror maybe they might actually ... get more done and therefore need more stuff :D

Reminds me of when our license for ElasticSearch was expiring, the process took so long (we wrote a countdown application to test out our local PaaS) that it had expired, and just silently turned off secure auth.

> One answer is to accept the way things are at BigCo and to just coast along in your role, which is not necessarily a bad thing.

Sound advice.

The HN community (rightly) skews towards entrepreneur hackers who have a general distain for BigCo employment.

I love this quote from Prof G on joining BigCo:

https://youtu.be/ffDVe-NgFt4?t=662

You're going to have access to what is the greatest wealth generator in history and its called the US Corporation.

On a risk adjusted basis, you're better off working at a Big Corporation

> The HN community (rightly) skews towards entrepreneur hackers who have a general distain for BigCo employment.

On the contrary, I find that most work at bigco or smaller companies and come to HN to play out their dreams of what it would be like to take the risks that people with lots of wealth can make freely

Also probably true.

Seems like the more wealth you have the harder it is to make risks…

This is a great comment. I urge OP to take this on board

Look at the lifers at BigCo, and how they roll with it. They choose their battles carefully, they don't fight the system. They are good colleagues, and they are paid well for their long service. They also go home on time!

Not disagreeing but you can't just give up and coast along either. Don't get me wrong, I've been doing it for a couple of years and getting ready to quit my job because of it. It gets frustrating and a tool that's not used frequently loses its edge.

I'd say do a couple of things -

a) Provide constructive recommendations on the specific friction points. Sometimes, especially coming from a small company background, you fail to realize the need for a process or review. It doesn't mean it can't be improved but resist the immediate urge to hate it.

b) Plan ahead. Once you get familiar with how the processes work, set aside time to raise request before you actually need the resource. I was terrible at this and it came to bite me many times. Anticipate and plan ahead.

I've worked at a few startups that have this problem too. Mostly because tech leadership came from a bank.

I would never hire someone again if they have worked at a bank for more than a couple of years.

That's a huge bias to bring in an interview.

Sometimes you work on some cool project for a while, then it becomes boring, etc. Or sometimes you're stuck with that job because of lack of other local opportunities. Or whatever other reason.

I agree, big bias. I'm not totally being serious. But I have had really bad experiences with people working at banks.

I think that working at a bank is fantastic so long as a person can internalize the good parts.

The bank I was at had the best data practices of any company I’ve worked at by a mile. They wouldn’t hesitate to write huge checks to make sure that the hardware systems and teams supporting those systems were perfect. Software management was a bit procedural but the results were consistent and high quality.

I have worked at 2 really big banks and they have many very talented, well-rounded people.

The friction is there to protect the firm.

It's true, though, that upper leadership tends to be incompetent. Don't hire them.

But finance tech VPs and ExecDirs are often highly skilled, smart people.

A lot of the friction in the banks is for legal reasons - they HAVE to abide by certain protocols. If you treat that as an extra challenge rather than a hindrance it will be more rewarding.

Yes and no. There are teams and people who protect their headcount and interests under the guise of compliance. But very often they're enforcing one interpretation or implementation of the law. And very often, they're audited as to whether they follow the process they designed and not the process itself.

Navigating the regulatory landscape to introduce change is high skill and art that I've rarely seen but does exist.

I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process for any work that would take more than X man hours. They'd shut you down because you didn't have have approval for the budget. Yes, even though they're paying you to sit at a desk, you have to get executive sponsorship for the budget to cover the wages that they're paying you anyway. But if you know your way around the incident / problem / change management processes and you know enough of the userbase, you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem", you get pulled into the next problem review meeting and asked what can be done. You think about it, tell them you have a solution but it'll take a few weeks to build and test. And either you skip through change control because it's a production incident, or the problem management team do all the process for you.

> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem"

This is an interesting perspective but perhaps crosses the line.

Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle.

After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets.

Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!"

All that from taking the ITIL course seriously. If you're going to hack the system, understand it

In Norway it seems you could have an exception for people who worked at Sparebank1, everyone I know who have worked there has been great to work with or listen to.

(I never worked in a bank myself.)

I found that the more I delivered and the happier I made senior people, the more I could ignore the rules and process and friction and get stuff done. Probably a year or so in I barely paid any notice to most of it.

I had a huge amount of freedom, really. But after a bit over a decade I finally moved to the world of startups. I’d never go back.

So while you can definitely work on removing your own personal frictions, and it’s absolutely worth selectively breaking the rules, I’m not sure you’ll ever be as happy as you could be in a different environment if that’s how you feel now.

>I found that the more I delivered and the happier I made senior people, the more I could ignore the rules and process and friction and get stuff done.

Yeah, I agree with this. My strategy has been to figure out what my boss wants to do, figure out what I want to do, and figure out what my job duties actually are. Then focus on the intersection of the first two and doing the minimal work necessary for the third. This means trying to get around process for your boss's pet project or to work on what you want while making your internal customers go through as many hoops as your organizational structure allows when they want you to do your job duties.

This probably comes off a bit cynical and I do have some pride in doing a good job, but this is kind of my basic corporate strategy.

The important thing is that job duties often don’t have to stay static.

Especially if you are already doing a good job at what you want to be doing and keeping someone senior happy, it’s often possible and sometimes even surprisingly easy to evolve your official/main duties in that direction too.

It took me a long time to figure this out, but the BigCo friction does come with benefits. Particularly benefits of scale and risk reduction. Need your app localized? Surprise, that happens automatically with BigCo processes. Didn’t think about GDPR compliance? Surprise, part of the delay you’re experiencing is that review. Need an awareness campaign? There’s a whole marketing team to help you with that.

Thing big and slow, and you’ll work it all out.

Yup, exactly.

The complexities of both running a large operation and operating globally are vastly greater than a small operation. Simply the number of nodes that must communicate has a combinatorial explosion. So, there needs to be a standard way of dealing with that, or entropy also explodes. So, bureaucracy happens, with processes that sorta fit everyone but rarely exactly fit, so friction increases.

A saying I heard from Africa: "If you want to go fast, go alone, if you want to go far, go together". GP is going far and together, and yes the other people will necessarily slow you down vs going alone.

The decision is whether one really wants this journey, in which case, learn how to work within the large org, or actually wants the faster but less secure career.

> A saying I heard from Africa: "If you want to go fast, go alone, if you want to go far, go together".

Love this! Definitely gonna use this sometime.

Indeed - it was very memorable for me too the first time I heard it !

> Another answer is to work at an early-stage startup or a small non-tech company where you can move fast. The tradeoff there is lack of job security and lesser pay.

I work for a very small "non-tech" company, have been here 12 years, and have a great income. The tradeoff I had to make was a much higher level of responsibility. (I'm at the very top of the tech stack - if something isn't working, there's no one for me to blame, aside from a vendor like AWS)

Lesser pay is not always true.

This is corect analysis. BigCo comes with pros and cons, but the pros are typically job security* and a life outside of work. My son was born three months before my father died and wow did that rapidly change my perspective on the relative value of an agile but single threaded rocketship vs. a megalith taking a a six year ootm call option on a few months of brilliant work.

Relatedly, best advice I received was that the grass is green and brown on both sides.

*standard disclaimers about at-will employment

I have worked at several big companies, including BigFatHugeBank and heartily agree with the above comment.