Coming from smaller companies and startups just got a job at #BigCo in the Bay.
The one thing I'm noticing is that it's miserable to work here because EVERYTHING has friction and takes days to get done and has to go through numerous teams and approvals just for the simplest stuff like a new VM or an SSL cert from their own in house CA.
I get great satisfaction at work out of accomplishing things and this is just rediculous to the point of making me dislike working.
To get anything done is emotionally exhausting.
Anyone else dealt with this?
Anyone have any type of jobs where friction is minimal?
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.
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.
Don't ever expect to move fast at BigCo. It's a BigCo for a reason. By moving fast, you could upset the cash cow, hence the friction placed in front of you. But this can work in your favor. Excellence will not be expected of you at BigCo, and if anyone complains about why nothing is getting done, you just repeat exactly why. As long as the company is making money and you haven't made any enemies, the chances of you getting fired are slim to none.
IMO, you have to look at the big picture. If you ignore the friction factor, is life at BigCo so bad? Are your hours reasonable? Do you like your coworkers? Good pay? Learning to let go your frustration with how you think the company should be run may be the most favorable choice. Remember, all jobs suck, more or less. A year after you change companies, you will find things to hate about that one as well.
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.
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.
Deleted Comment
Make sure there's not a golden path that you're missing? Or that your reasons for departing from it are really insurmountable?
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)
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
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
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!
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 would never hire someone again if they have worked at a bank for more than a couple of years.
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.
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.
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 never worked in a bank myself.)
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.
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.
Thing big and slow, and you’ll work it all out.
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.
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)
Relatedly, best advice I received was that the grass is green and brown on both sides.
*standard disclaimers about at-will employment
It's normal that a single developer is maybe 20% as efficient at a big company compared to at a small company. What you used to accomplish in one day will now take you a week (after team processes, code reviews, deployment requests, etc, etc).
But the trade-off is the big companies have figured out how to keep thousands of people productive. They might individually be less productive, but as a whole they accomplish more than a small company can accomplish. Some do it better than others, but no big company works like a small company.
That's just how it is. It's easier to solve problems with small groups of people than large groups of people. If the problem takes a large group of people, it will be a lot less efficient.
I would even say that working at a big company as essentially a different skillset than working at a start-up or small company. In a big company, your main job is to get other people to do things and you are successful based on how well you can do that. In a small company, your job is to do things yourself.
If you really hate the big company world, you should consider moving back to a small company. It's never going to not be like that.
I just switched job from a big company to a fast-growing startup which doubled their engineer team size in one year. I was unhappy with my productivity in the new company, thinking I was not doing enough, but my managers said they were quite happy with my performance. I think I was comparing my productivity with the peak productivity in my previous role where I already spent years working on the system. But what the managers really measured is your relative performance compared to your other peers. So as long as you are doing okay relative to your peers, albeit all being unproductive, you would be okay.
1) Cultivate an attitude of optimism and gratitude despite the challenges, perhaps through a study of Stoicism and a cultivation of patience via a study of Buddhism. Gain more pain tolerance. Learn to not care so much about the outcomes, and care more about your own presence and the excellence of your contribution. Learn to care more about other people, rather than just getting the job done. Learn to have more fun, while also "digging the digital ditch". Being calm and steady despite feeling uncomfortable is an invaluable life skill essential to growth and doing big things.
2) Learn to politic. Recommended reading (and there is a lot) would be How to Win Friends and Influence People, as well as Robert Greene's The 48 Laws of Power. Navigating people and political systems is also an invaluable life skill and essential to growth and going big things.
3) Develop your life outside of work more fully. Consider getting more involved in helping your family, your friends, and your community. Volunteer opportunities abound. Perhaps they need a speedy hacker like you to help them with some part of their tech?
4) Study the challenges of BigCo for startup opportunities. Lots of startups are created by people who ran into a big challenge at a big co, then broke out on their own to solve the problem, then were able to grow by selling back to their previous employers to solve the problems with tech.
At one such company, no names, they had a rather large consumer facing website. I was told it had no analytics other than a homegrown solution (which was terrible). Then it turned out that had Google Analytics (Enterprise) but everyone had forgotten about it. They denied it at first, but I showed them screenshots of the Network tab in Chrome where it was pretty obvious. Suddenly I had access. So far this is 3 weeks or emails.
With access I realized the implementation was botched. All view states were being handled by a hash in the URL so all Page Views in GA were reported in one URL.
I requested a minor code tweak to account for this. I was told by the dev team it would take 6-8 weeks to implement such a change. I was assured this was rather complex and they'd need to free up people too to work on it so that could take longer.
I told them the code change was already written and I'd included it in the initial request. I referenced the template file within their system where they change would live and included tests. They still dragged their feet. It got completed in my last week. Copy/pasted exactly as I'd written it.
It was utter madness.
There will be people who insist that you should “focus on the most important thing” but if it’s blocked what’s the point?
The other thing to do is make a lot of friends in related departments. It’s amazing how much faster things will go when someone does you a favour. Expect to be doing favours in return.
For what it is worth, I am at a BigCo and while yes it is true you cannot just hammer out 4000 lines of unreviewed code and push to production without someone else being involved, you also benefit because people aren't just changing stuff willy-nilly. E.g. your project you've been working on wont suddenly stop working in production out of the blue because Clive decided to totally change the database table schemas at 4am on Wednesday morning and nobody told you about it etc etc
It can. I worked at a 2400 person company. 'Dev/tech' side was... ~150 or so, so not thousands of devs, but not just '3 folks in a basement' sort of place. Lots of 'process', but only for some people (like me). Other people - people who were dating management, for example, could make whatever changes they wanted.
I would need to have a formal meeting with 2-3 "sr" folks to request a database index, then have to do a presentation about why it was needed, then wait for 'review' ("this might break something else"). But then other folks would literally just go on the database (because they had direct access) and fuck with whatever they felt like.
And... I'd be dinged because my deliverable was late because... "well... you should have planned your project better" (when... I had no hand in planning or setting deadlines). Not in my wildest dreams did I think requesting 2 indexes on a couple tables that only our application used would require 2.5 calendar weeks and multiple meetings, so... unsure how I should have raised a flag earlier that we might hit some roadblocks.
But yeah... hey, if you already had access to prod dbs, you could just go in and make live changes without testing or documentation ("it's OK, Steve used to be on the database team - he knows what he's doing").
Process/overhead isn't necessarily bad, but applied unequally, you wind up with hypocrisy and resentment (and people like me leaving in less than a year).
Regardless, I'd probably argue that a company with only 2400 employees let alone engineers is not what most people would consider "BigCo". In my mind, BigCo are thousands/tens-of-thousands of engineers - think FAANG, major Investment Banks, major technology companies (e.g. the IBMs, Microsofts, or Samsungs of the world). The sort of places that people (rightly or wrongly) aspire to work at, or at least have some common mind-share amongst the average person on the street.
At a fruit-themed Bay Area company I can register a domain name behind a load balancer, issue a new cert, kickoff a VM to host it internally all in the same day without any approvals... so long as it is below a certain scale suitable for testing, skunkworks projects, etc. Approvals and meetings only become necessary if I want to deploy a production service, a large-scale service, or both.
Requests for a new repo or Confluence space are fulfilled same day and give me complete admin control over it. I can kickoff custom OS builds and generation of installation images via a self-service portal. I can create new email-enabled LDAP groups via self-service. I decide if the group itself is self-add or not, etc. Anyone else in the company can do the same. Many other things are as simple as direct manager approval.
You don't have to put up with bureaucratic nonsense, it just happens to be common in corporate America where management doesn't trust the peons to make decisions. Or perhaps where everything is driven by division P&L so no one wants to be responsible for spending money outside their fiefdom?
I prefer an environment where individuals have responsibility and yet where we accept mistakes will be made. As long as you learn from a mistake and don't continuously repeat it there is no need for a new process in response to it.
This.