Ask HN: New job at BigCo. Everything has friction
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?
218 comments
[ 1.9 ms ] story [ 313 ms ] threadI am not happy to bring bad tidings.
Edit: no business gets “Big” without a good paper trail and this implies that no action is performed unless some previous paper work has been carried out.
What do you think would be the best types of jobs to target for lower friction? Startups I guess.
I guess a good indicator is the size of the legal Dpt.
But I work at academia so I am not your best counselor on the topic.
Notice also that you are going to learn A LOT about “due process” and “due diligence”. This will be very useful in your future positions.
It's hard to quantify that way, I feel it would depend on how "wide" the structure of the organization is. Perhaps "layers of management" between where the money is actually made and where the decisions are made is a good metric. Two or three, in my experience, have been the best places to work.
Anything more than that and the friction exponentially increases.
Why wait? Working at big tech is a bankrolling operation. I show up and collect my dough, nothing less nothing more.
That is to say Big companies can be OK if you land in the right department.
There was a team that was responsible for cohesive look-and-feel across the gateway (front page), but mostly they trusted us to do our thing.
The principle of a team completely owning their little bit of territory within a page on the Amazon site was a very good one, IMO, and helped cut down on what could have been a bureaucratic nightmare. Of course it had its downsides: some teams didn't pay as much attention to presentation or browser compatibility or interoperability in a range of scenarios as others did; and by its very nature, this team organisation led to pages which were divided into not-particularly-cohesive slices, each its own little fiefdom.
Still, there are some BigCorps which do at least pay attention to optimising processes, even if it's only in a particular direction. (Shipping stuff at Amazon was easy. Want to talk at an open source conference or ship open source software? ...ooh, we'd better talk to the lawyers.)
This might have been true years ago, but my recent experience has sadly been the opposite. e.g. on the projects I worked involving the website, testing locally has been virtually impossible.
Once you realize its all about work tracking, basically, it becomes either more of a hurdle or easier to understand and manage, but thats basically what you're up against here.
Welcome to BigCo. That's all there is.
One thing you are mentioning is the friction around the dev experience however and there is perhaps an action you can take, if you're willing this early in your tenure there, to put your neck out on the line.
My very firm belief is that a bad dev experience results in a high cost of experimentation which means people don't try new things out and innovation stops. The only way things get done is through massively coordinated efforts. If you can associate a cost of the gate keeping with productivity and then directly back to the money it costs the company, or money that could be saved, or feature velocity to be gained, you can make a case for improving the experience. Making the case and seeing this all through will take you 6-9 months.
Both can be lucrative journeys.
rantish story
I work at a BIG Co (think 700k+ global employees) and we work for other Big(ish) Co as more or less data & code wrangling consultants.
How did I end here? I worked for a small(ish) agency with around 500 people. We moved fast, we build cool stuff, we already to worked for the Big Companies and Banks in our market (Germany). We were at a point were quite a few more formal processes would have been necessary to put into place to fulfill compliance regulations of different markets (think banking or automotive - these require a lot of stuff in terms of compliance from their vendors).
But we got lucky (?) and bought because BIG Co was not able to build their own agency - so they bought a lot of agencies to build a new one.
In the "good ol' days" I knew whom to ask to get anything done. There was an official process and the ones in the know knew how to navigate the short cut. Ask the right person, receive special treatment and be on your way flying fast.
OK - it made the process longer for the lowlies who didn't know the right people. And that is exactly the problem. There already was a two class society of workers. Because we already were too big for "no process" and too small for BIG Co process (and that drags us down nowadays). But the people following the process unbeknown to them got blocked by us knowing the shortcut.
So yeah - it feels shitty and slow and probably as if someone wants to gauge ones eyeballs out with a hot branding iron.
maybe helpful POV
But think of it like this:
Try to transport a 20 foot container on a high power speed boat. The speed boat will be way faster, more agile, more flexible. But if a somewhat bigger wave appears it will crash. And it will also not be able to deliver that much impact (containers) as the big ship once it arrives in the harbor.
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.
Nobody in my family ever made more than $10/hr growing up. I turned out okay. I think. :)
I would never hire someone again if they have worked at a bank for more than a couple of years.
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.
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.
Navigating the regulatory landscape to introduce change is high skill and art that I've rarely seen but does exist.
This is an interesting perspective but perhaps crosses the line.
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
(I never worked in a bank myself.)
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!
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.
Love this! Definitely gonna use this sometime.
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
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)
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)
shock horror maybe they might actually ... get more done and therefore need more stuff :D
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 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.
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.
Relatedly, best advice I received was that the grass is green and brown on both sides.
*standard disclaimers about at-will employment
I imagine that the majority of white collar workers are employed by large corporations, and so the majority have to deal with this.
Given the number of startup layoffs happening, I imagine a lot of people will be having their first experience with large corporate bureaucracy.
> To get anything done is emotionally exhausting.
Onboarding as a new hire is usually the most frustrating period, because you need to request a lot of things and can't get any work done in the meantime. Eventually you have enough access that you can at least do work while waiting on other requests.
One thing that helps is knowing how to use the corporate tracking system to know which individual specifically the request is stuck on, and then relentlessly following up with that individual via email until they approve your request.
You should also track your tasks and identify the ones that are stalled because you're waiting on a request, and then regularly show the list to your manager (along with your follow up efforts). That way you have a solid reason for not getting those tasks completed.
All Over the world, workers yearn for breathing time - A few minutes away from the the production line. They wish their tool breaks and the management takes a long while to provide a replacement.
What’s your issue, op? You seem very excited to generate shareholder profit.
If only the most unfortunate person in the world can claim injustice or dissatisfaction, if only their problem can be solved, progress will grind to a halt.
> Life is more than serving your boss in the office.
Sure, I don't think anyone's saying you exist to serve your boss. But if you have to work a job, why not find one you actually like doing? I think what the OP describes would be a complete drain of my energy, even if I could read a book occasionally; working on actual code during my workday gives me an opportunity to be paid to learn new things and is honestly actually energizing. Why work on a tiny Nix environment on a toy project when I could be setting up a real-world Nix development environment that's deployed across tens of developer laptops, y'know?
This kind of oppositional attitude is toxic. I'm glad not to find it in my coworkers. And I would not accept an environment where coworkers displayed it.
I left defense and I'm now in a BigCo. and loving life because things only take days at most. Appreciate what you have?
Yes - there's lots of friction. Bureaucracy is inevitable, given the cost of turning the ship/the risk level if something bad sneaks through.
That said, there is a ton of potential leverage at BigCo - the scale is extraordinary.
It is a trade - you get a far bigger lever, but it takes way longer to pull.
Deploy a vulnerable VM at startup you configured wrong? Probably nobody will even notice. At #BigCo, risk an advanced persistent threat that's actively scanning your infra finding it immediately and compromising a massive amount of data.
The company is paying you to work to their schedule, and unless you're working on "efficiency" or workflow improvement - just take it as it is and keep on top of it with your calendar.
Yeah, it's silly to file a ticket for a self signed cert, but it also puts the onus and responsibility on that team ,not you. Yes you'll miss out on small wins like that, but really - it's a cert in the end, and once you raise it up - let the team deal with it.
I'm a PM for security at a CI/CD company, and adding "friction" comes up as a feature request in 50%+ of calls with customers and prospects. As companies grow to a certain size, as a practical matter you can't trust employees to not do bad things. Also, in order to win more business you have to comply with more regulations. Access controls, separation of responsibilities, etc.
Restated, one person's friction is another person's compliance.
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.
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.
For me, it's things like lots of marketing program people, public relations, analyst relations, competitive analysts, designers, editors, etc. They can offload a lot of work (and, in many cases, can do that work better than I could). But it's a lot of people to keep informed and coordinated.
I guess it depends on the role. I don't think startup developers do any of these (except maybe design) :)
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.