Ask HN: Is it really so dull to work in huge company?
I have changed job lately. And this is my first time in really large company with ~300k employees worldwide. So this is my first, first hand, experience in large company.
My first impressions is that everyone knows only quite narrow field of the project. And it still surprises me as I'm used to opposite.
Next thing that really struck me was how hard is to just approach someone and get to know him. As there are people sitting next to each other that have way different work. So you never know if what the guy next to you actually does, also it is hard to approach someone since most of the people spend large amount of time on online calls. Therefore you really never know if you can approach someone and don't look like an disturbing idiot.
And lastly I feel like we are dealing with not that much of complicated technical products, but the complexity of work is created by all the processes (SAP, etc.).
I mean the people are actually pretty nice, they are not stupid at all, but everything just seems so dull. And I have feeling like it really does not matter if you are really good or under average. You just learn all the processes that company has and the execute them. I feel like I'm in huge ant colony that's somehow producing results. And suddenly can understand why startups can undercut such behemoths. I mean I read about it plenty of times, but it is very different if you are living it.
My question is. Is that really how big companies operate? Or are there exceptions? For me that means that I have to accept to just provide defined outputs to some defined inputs (for decent wage). Or avoid such companies if I'm not able to accept it.
87 comments
[ 3.7 ms ] story [ 147 ms ] threadMy favorite anecdote was when the company basically told us that we could not talk directly to the person next to us, and had to route everything through the project systems.
Small companies, more folks are "on the line", and thus more engaged in the entirety of it, rather than their own little niche. Similarly, you have more access to people for discussions, problem solving, etc.
Yea, "it's interruption". And that's just where you need to learn personal boundaries on the individual level, rather than corporate structured boundaries that simply dropped on the team.
In large companies, more and more people are "doing their portion", "not my job", etc. I'm not suggesting everyone needs to work insane hours and burn the midnight oil, but it's the ability of build a local culture rather than have on mandated upon you from up high.
When you're empowered and have agency, you're (I am) more motivated to participate and grow and engage instead of checking my boxes for the weekly TSP reports.
I have a similar anecdote, but at a medium-sized company (a famous, now-defunct computer game outfit).
They had a rule that you couldn't talk about your work to anyone who wasn't on your direct team. In practice, what it meant was that nobody talked to anybody about anything other than trivialities. I found it so alienating that it's the primary reason why I quit.
However, working in a huge company does bring all sorts of things, including many you list, that I dislike. As a result, I very strongly prefer working for smaller outfits.
But everything's a tradeoff. There are different upsides and downsides to huge companies, tiny companies, and every size in between. the trick is to be clear with yourself about what tradeoffs are best for you.
But then again, you might find some really fun and interesting pockets within those big companies.
I'm a project manager for a small software product at a large company. I like to think that my little space within this huge company is an enjoyable place to work. While I am responsible to stakeholders to make sure we accomplish certain major tasks, I get a bucket of funding to allocate as I please. My team and I can decide on our own what tools to use, what languages, how to structure our development schedule, etc. It's all very not-behemoth-like.
But go across the hall (figuratively speaking -- my team works mostly remote) and you might find an abundance of process and bureaucracy. I've been there too. And admittedly, that may well be what the majority of the company is like. But if you can find a project / group / etc. that suits you, you may be happy working there even if the style of the rest of the company isn't to your liking.
In such case you'll find yourself spending most of your time fighting to not become a complete bureaucrat, and eventually using only the minority (if any) of your time doing actual work.
However there's plenty of people that's there to "strategize", to "synergize", they're on online calls all day long, it's all career path and promotions and (hopefully) golden parachutes for them, so they'll call it exactly the opposite of "dull". What you call "dull" is actually _their goal_.
On the flip side, startup environments are way less dull but way more punishing, and may not be for everyone, or may not be for every stage of life.
That there's more streamlined processes to me is a good thing, because it actually frees my time up. Small companies just have so much more overhead and chaos relative to the size of the business.
Bonus points for "nobody being responsible for anything" plus a healthy dose of "yeah no, we don't have any budget for this this year"...
Maybe it's preference, but I much prefer to work in a small company where you can actually influence decision making. I've worked at some large companies and now I am independent and I also work in a very small company with half a dozen people. I much prefer it because it feels like there is real meaning in what I am doing.
Large companies can give you some meaning too but you have to fight for it there, and work against the bureaucracy, which I hate so I left that life behind.
If you're a plumber, do you want to be responsible for building a brand new skyscraper with top of the line pipes, or do you just want to show up to your dead-boring factory maintenance job, fix the things you know how to fix and go home to your wife, kids and/or hobbies - which is where you draw satisfaction from life.
Hackernews is slanted towards the "build the latest and greatest and be the best software developer ever". The people who are just average, or good enough for their job, but don't care about staying current with the bleeding edge of tech (like what's posted daily on HN) aren't here to give you a contradictory opinion.
sometimes you just wanna work at a small company that prints money, with a boring tech stack, say ROR, Golang -- but doing interesting work.
compared to big company where it's a lot of custom tooling, then other people bringing the latest and greatest tech to enhance their resumes or profile of the company through tech talks etc.
end of day -- it's finding what works for you.
Have you seen many new skyscraper-level sites pulling all-nighters constantly? And if you saw one, do they do it with the same people that was there at 7am the day prior? There's regulations (and sometimes unions) that make those the best-paying jobs for plumbers and also making sure that the plumbers can go to their families at the end of the day.
Again, this started as an "skyscrapers sites" analogy. If you have a guy working in such construction for 20 hours straight, you're calling for a (very possibly fatal or catastrophic) accident, and there's absolutely no insurance company that'll cover for that, among other problems you'll be calling for.
this is it. it's not that it's boring, it's that it's POINTLESS. the bigger a company gets, the more it's burdened by its processes. and that comes directly at the expense of your career and satisfaction, if you like, y'know, actually building stuff. if you like to wrangle process, which is a career unto itself, then well, enjoy, you're in the right place.
(and I'm sure its FAANG friends too)
I've done my time there (3 years as a college-hire) - still my favourite overall employer, I just had a sucky position (and undiagnosed ADHD... yah...).
P.S. If any hiring-managers in the OSG Shell team (i.e. Explorer.exe) see this, get in touch, there's so many small little bugs I want to fix!
Always remember MICE: Money, Ideology, Compromise, and Ego. You probably don't control the money and the only ideology is capitalism so compromise and ego are the ones you should focus on.
Honey pots work the best as compromise (especially sexual in nature) and you should always practice your skill of manipulating your coworkers' egos to help them along in the path to self destruction ("never interrupt your enemy when they are making a mistake").
These are people playing on the same team as you?
What kind of humans choose work environments where they're surrounded by foes?
Hoping this is winding down.
I can’t imagine anyone working in such an environment. The MICE acronym is from counterintelligence and espionage.
As a whole though I would say large orgs generally bring stability and stability can be boring to our brains that have evolved from thousands of years of living hand-to-mouth.
the amount of waste is unbelievable and utterly sickening. and that 50 million is just a drop in the bucket, compared to the huge waste of money and other resources worldwide, and not just in the software field.
This means one of two things:
1) You will work with similar independence to a developer at a smaller company—but spent 10-20% as much time directly working on code and related things, with the rest going to tracking down people and systems to get what you need to start/proceed/complete a feature.
2) Or, someone else will do all that for you, you’ll have far less independence, and will basically just be killing detailed Jira ticket exactly as assigned. But you’ll write a lot more code and such.
You go bigger. Business units now. Deliver consistent performance. All units is not Skunkwork. Just machine. Big unit. Transistor in company CPU. Eventually company as well is just transistor in nation CPU. Nation just transistor in Earth CPU.
As it takes a lot of time to go through the process of changing things, make sure to invest time in deciding what that change should be (and how to structure it in a way that it's easiest to go through the process) instead of making the change that you would do if you would work on the code base yourself.