Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Moving from a startup to a big co, what should I be aware of?
180 points by 1729 on June 9, 2020 | hide | past | favorite | 159 comments
To add more context to my question, I’m currently in a product leadership position at a ~300 person SaaS company and I found my way here by way of a semi-decent exit as part of a startup’s founding team. However, I have been considering a switch to a much bigger company (Microsoft, Google, AWS) of late. All I’ve ever learnt over the last decade has been by operating in a capital constrained environment. Moreover, I don’t have a lot of reserve energy in the tank to direct it at another startup after 10 years of blood, sweat and toil.

I often find myself thinking of and seeking out experiences from my peers at these behemoths on how decisions are made and products get built there. On one hand, I’m scared of slowly going further away from all my learnings as an entrepreneur (a lot of which haven’t come easy!!!) but on the other I feel like not having had relevant experience in the right BU/product within a big co is limiting my field of vision. What are some things I should consider before switching?




Here is what it means to work at a big company:

* Things work slowly, so relax. There are many people that have a hand in every aspect of a product decision.

* At a startup you are actively changing the world. That’s done now. Put that completely out of your head. You are cog in a machine. Instead focus on your assigned product, help your teammates, and just learn to relax.

* You, the individual, are not important. The product is important, the department that delivers the product is less important, the teams that comprise the department are less important than that, and so on. Again, accept the reality and just relax.

* Do your best. Unlike at a startup, generally you will have time to get things correct. This is the difference between competence and others who struggle to get things right and always appear to be in a hurry. There is no reason to be in a hurry.

* Expect insufficient test automation, lots of regression, and plenty of repetition. Also expect everybody to be an expert that is in a hurry and things in a unique way. Just be patient, politely nod, and just relax.

* If you are good at systems automation then learn to automate away as much of your job as you can. Use the now increased free time to contribute to documentation and internal knowledge repositories. You will find that a lot of the documentation can be automated as well.

* My employer has something like 270,000 employees so it’s forgiven if you have no idea what all of those people in your cubicle farm do. You need to actively spend at least 2 days a month answering those questions.

* Just because you are at a big company does not mean you are safe. I have been in a large established super well known .com that failed. People get laid off even when big companies are healthy.

* If you don’t like being bored and are highly risk adverse you might find the big company life highly depressing. A lot of my advice here is to just relax, but I hate relaxing.


Some counter experiences, just based on my own annecdata.

> * You, the individual, are not important. The product is important, the department that delivers the product is less important, the teams that comprise the department are less important than that, and so on. Again, accept the reality and just relax.

Working at startups I have never felt less important as an individual. The product is #1 and I only exist as a cog in the machine to produce that product and make the founders money. In a big company I was encouraged to pursue professional development, my professional goals and dreams were catered for and I felt like I could make personal progression.

> * Expect insufficient test automation, lots of regression, and plenty of repetition. Also expect everybody to be an expert that is in a hurry and things in a unique way. Just be patient, politely nod, and just relax.

Again, opposite experience, startups don't have time for test automation whereas big companies generally do.

> * If you don’t like being bored and are highly risk adverse you might find the big company life highly depressing.

I'm often bored at my startup though never lacking for work. It's just that the work can often be monotonous work because the startup doesn't have time to automate it or hire someone to do it. At a startup, its rare that you're encouraged to explore something new that might not work out. There's just not the time or budget.


Maybe it's that employees are some sort of cog about everywhere and test automation is also bad almost everywhere.


Truest comment here. I’m co-founder at tesults.com and the biggest reason we discovered for dropping off the product is because upon integrating they realize their test automation is in such a bad state there’s no need for the service :-) It’s a shame because regression is commonplace. I wrote about why I think it’s done badly on the blog (https://www.tesults.com/blog?id=why-automated-test-projects-...)

I’ve worked at companies with 100k workers down to 10 people companies and the employee is generally a cog everywhere unfortunately but you learn different things. I started out in big companies and learned nothing about the business side of things whatsoever in those years. I did learn solid technical skills and practices though. I think smaller companies are the way to go if you intend to do your own thing one day. Bigger is better earlier in the career to learn technical skills or later on if you need a comfortable/well paying job when raising kids for stability.


I think what you are describing are startups past the early stage. It's the worst of both worlds IMO.


>was encouraged to pursue professional development, my professional goals and dreams were catered for and I felt like I could make personal progression.

I think this is because instead of giving a pay raise, they offer these benefits.

It costs the company nothing.


This is all fantastic advice. I spent the first 26 years of my career working at startups and small companies before taking a job at a big, public tech company last year. This advice is spot-on.

I find that I'm actually working much harder here but my work is more focused and in a single lane. I'm not bouncing around all day between 20 different things. I'm grinding for months on end on one tough, big problem. It's not bad, just...different. The pay is much better here but you are expected to _be_ better.


This all sounds perfect!

At {current_job} it feels like I'm slowly developing faux-ADHD from the "priority 1" task changing, often, multiple times a day. Personal projects are a bit of a respite from it, since I get to focus on the one clear, long-term task for good stretches at a time, but recently I've been too burnt out to do even _more_ programming after yet another hectic day.

I feel like I'm a competent SWE, but the nature of the work means everything is a ticking time bomb. If you're rushing all the time, code quality, testing, and all sorts of other sanity-restoring factors become a distant dream. I'd love to take ownership of a few aspect of a large system and slowly improve whatever I can. But the grass is always greener on the other side, so I'm sure this would come with plenty of negatives too. For one thing I feel like I'm too early into my career to be acting as a faux-CTO and being the go-to for all big tech decisions, infrastructure, etc, as well.

Would you say there is an inflection point at which startups stop being like this? 20, 50, 100, 500 engineers? More?

Sorry for the ramble!


At the beginning of a startup, there are no "big tech decisions" per se, only a whittling down of your problem space and target market. If that can be done with zero technology, all the better.

What gets to be called a "startup" is highly debatable, as some billion-dollar companies have still been called "startups". However, you will only get to be faux-CTO if you get in really early, or start one yourself. Best of luck!


* Things work slowly, so relax.

The extent of this is hard to grasp outside of bigco. At oracle we had layoffs/reorg - no real work was done for ~7 days, and it took 3 months to figure out our new roles/responsibilities. Some people were paid $40k+ in that time period and did very little work.

Things occasionally move very very slow. Twiddle your thumbs and be happy about your huge salary, don't quit like I did!


Seriously. I heard big companies were slow before but I didn’t realize the magnitude of it until I joined one. Most people where I work either only produce real work for anywhere between 40 to 10% of their time. The rest is either filled by busywork or twiddling your thumbs (depending on individuals)


Or meetings, meetings, and... more meetings!

My 2 cents:

As a contractor, charge a lot. They either have budget and want to spend it RIGHT NOW or they don't. The manager engaging you doesn't really care about your daily rate (relatively speaking).

Above comments on automation is spot on. Test suites might be terrible, so the care required to make changes without breaking things is your responsibility, hence the slow pace. What is in your control is the ability to automate your own testing.

Integration with poorly defined APIs is an important skill. You generally won't have another team maintaining and improving a nice API. You will have access to obscure data stores dumped untransformed in the data warehouse from another megacorp's expensive and poorly documented product, possibly with myriad ETL nuances (read: bugs). Learn to work with this and you can extract gold.

If you have a Windows SOE system, embrace Cygwin/similar.


> Learn to work with this and you can extract gold.

Curious if you have any tips for this stuff? My instinct would be to just poke and prod things, writing tests or documenting things as I go along. "I wonder what happens when I do X" -> write a test, get a result. "I wonder what data looks like here" -> examine it, write a summary of what I found. Etc.


I have been a contractor/consultant for the last 7 years. What I've seen when you try and go down that "write a test" path is. Oh there's a 2500 line stored procedure with hardcoded network paths for production data in it. Or, this api only runs on the 2nd Tuesday of the Month but only after 8pm when the day of the month is also even. There's so much do-it-live embedded in the legacy systems it takes months to make enough seams to even test things in isolation outside of production. But, if you can get buy-in to make those changes, then exactly what you are talking about helps a ton.


Love being a contractor. I'm currently unemployed but gave multiple years of savings.


It's such a nice feeling to be inbetween contracts and not have to worry about how you're going to pay bills. I feel like I've only just now gotten to that with my business. Congrats and hopefully not unemployed for too long (unless thats what you want!)


The last 6 months I worked at a large for profit education company all I ever worked on or "released" were simple configuration changes. it was a struggle to find things to fill my day with.


They say "Oracle is where startups go to die" for a reason.


Can't agree to this more. And depending on the size of the company, it might not be just few weeks, things which you would think should have been done in a month might take up to a year. And meanwhile everyone WILL keep talking about moving fast.

People will keep coming in and going out and you would end up have the same conversation with many people many times. And everyone will try to suggest "one change" at a time.

And there is nothing wrong with all this. This is just how big companies work, you cant fast-forward any of it.


I came from multiple startups to a FANG and this advice is really good. Seriously, you’re going to need to relax.

Also I recommend reading “corporate confidential”. I was confused initially why being an excellent engineer who could “deliver” didn’t make me shine at bigco. The book helped me get on a better path.

Also relax.


I found 3 corporate confidential books on Amazon: by Susan Dephillips, by Barath Surendran and by Cynthia Shapiro. Which one do you recommend?


You want the Susan Dephillips one. Very eye opening, if you've never worked in a big corporation before.


Thanks. I have actually for many years and up to 150k head count, but never learned to properly deal with it. Moved onto a mid-sized company which is growing into a conglomerate of its own. I did like Erik Dietrich's Developer Hegemony, but his style of dealing with big co felt a bit too cynical.

https://leanpub.com/developerhegemony


It's worth noting that there is a culture change in some big companies where small teams given more latitude and budget to explore innovative solution (I know because these are the teams I mostly sell to). Also Intrapreneurship is a thing too. Way better place to be in than a medium sized mono product startup to be in if you ask me.


> A lot of my advice here is to just relax, but I hate relaxing.

Hit the nail on the head with that one.


I had the same experience and the comment about relaxing resonates with me.

Coming from the startup to the big company I could not understand why people leave the office at 5pm. There would be another few hours to work.

Also lots of meetings.

As the previous commenter said. Relax.

I guess you will have a broad skill set from your background and actually in big Corp the nice thing is that with this broad skill set That you can engage in so many different projects. And it is tempting to do so. But you only have this much time a day, and it will not be easy to accelerate your pace. This frustration can be bad for your mental health.

So my advice is relax. But also don’t forget the thoughts you had when joining the big company in the first months. Maybe keep a journal. Because you probably had good ideas but might get overwhelmed by the complexity of the big Corp.

If you have not read the “Accelerate” book, I would recommend this as well.

Also you can observe Conway’s Law in its beauty.


Why would I find it depressing if I’m risk averse? You sound like the only risk is getting fired for a random reason, which could also happen at a smaller corp.


I am so used to using the phrase risk adverse because is the more common phrase in my military side job. In the real world the common phrase is risk averse.

The first means a personality type that doesn’t perform risk analysis normally or does but simply disregards high risk concerns. For example it doesn’t make sense to jump out of an airplane or leap into combat. There is a preference for people who can weigh those risks and override the common sense factor that results in terror. In the business world this could mean investing your life savings into a start up idea knowing you might likely fail with nothing to show for it.

The second more common phrase refers to opposite personality types that cannot proceed in the face of uncertainty. These people are terrified to make a decision where the outcomes are unclear and thus hesitate waiting for increased certainty or for someone else to make that decision.

https://en.m.wikipedia.org/wiki/Risk_aversion_(psychology)

My personal approach to these terms is to simply make a damn decision even with insufficient evidence, because then you are at least doing something. If you later discover your decision is wrong then simply shift direction in the face of new evidence. People who sit there waiting for clarity, feels like an eternity in hell, makes me sad.


I think they meant risk-adverse, like able to tolerate risks well.


Both adverse and averse mean pretty much the same thing (thanks English language), but otherwise you are completely correct.

https://www.merriam-webster.com/words-at-play/adverse-or-ave...


I guess I was thinking of “well-versed”, thanks.


Well that all sounds terribly depressing.


This nails it.


> At a startup you are actively changing the world.

That sounds very exciting. Can you point to one startup that's changing the world?


I didn't take that literally - rather that at a startup, most of what you do has an immediate and obvious impact on the company.


There are legit startups out there that do change the world. Most of them are not companies that you've ever heard of.

I think that companies that change the world satisfy the following criteria: 1 - their work is very hard to replicate. Not impossible, but it would take a competitor a long time to reproduce their product or service. 2 - people would notice a tangible impact on their life if the company disappeared tomorrow.


We won't know which small startups right now are and aren't until several years from now.

All of the big cos right now that have changed the world were a startup not long ago. Yes, not all of the startups will succeed, but there will be yet another trillion dollar company some day which is today somewhere in the realm of early stage startups.


Something tells me this question is not asked in good faith.


Stripe


SpaceX?


SpaceX was founded almost 20 years ago and has 8,000 employees. That is not a startup (today) by any reasonable definition.


Are they though? They're almost 18 years old at this point, so I feel like they don't really count as a startup.


How old and how large has really nothing to do with being a startup or not . It just means a fledgling business whose revenues are expected to change rapidly and is developing a product/ business .

This is in contrast to stable or blue chip like companies who have stable revenues and their product lines are very well established.

The distinction is important for two groups of people .

a) investors - Risks and rewards are fundamentally different , therefore valuation methods are also different t you would use something like a Discounted Cash flow for stable corp you might look at IP, ARR , DAU or any number of other metrics for a startup whose revenues are not stable enough to use DCF etc

b) employees - change or innovation is far more deeply grained culture in startups , What worked yesterday may not work today, that requires different mindset to be successful at

Amazon , Uber are still startups despite what you think about their sizes , ages and current revenues . Building a AWS is only possible if you can completely rethink what is that you sell .


"just relax" good advice.


[deleted]


I feel this paints a far uglier picture than reality. In my limited experience (been with two fortune 500 companies, one of then in the top 10), you can expect maybe one of these issues(or two if you're really unlucky).


Remember when you used to ask your Mom / Dad, "Why?" and they'd respond with, "Because I said so." It's like that, but subtly more infuriating because it's never a single identifiable person saying "no" that could be spoken to, understood, and reasoned with. The answer that you'll get at a big company is, "because that's the way it is".


Having worked at Big Co and then on my own company for years, this is exactly what I was thinking.

You'll lose professional autonomy in exchange for a good salary, job security, and resume bling. And you probably won't have to work as hard or as often (again, probably).


"you probably won't have to work as hard"

For me, it was a question of: do I put in 40% to get 90% completed, or do I put in 150% to get 99% completed?


I'd like to echo this, along with the "relax" sentiment from other comments.

I worked incredibly hard to open source a project at a faang. I was even given a customer obsession award for it. No promo.. and no promo level projects for the next year or so... and now this open source project is "too old" for promo consideration.

I've learned to relax and give just enough to not be marked LE. I now have a lot of time to dedicate to other pursuits.


LE?


Low Energy I think.


How was business impact measured when deciding to open source the project?


Probably too late to respond, but just in case.

We were measuring the number of similar support requests that came to the team. Our library would allow customers to resolve these problems on their own. We had a good estimate of reduced requests, but not a good estimate increased time to maintain the open source library.


That is so accurate and succinct.

I'd say 40% for 80-85% from my experience.


Yeah, I think that's accurate and reflects the low level of polish in many newer Google products


In my career, I've had almost the opposite experience.

At $bigco, it was possible to beg/borrow for 100k to solve some problem, or hack together some tooling to solve a problem the team was running into. Need some servers and licenses, and it's near year end, partner with a program manager who hasn't used all his budget, help solve their problems, and get things done. I ended up spending something like $250k before the VP was even aware of the side project, and when it got to the VP level, it was how do we spend more to fix the gaps and have proper resources so it's not some toy side project. It was that way anyways, up until $bigco decided to emulate the way it thought the FAANG companies worked, and the management their started trying to micro-manage everyone in a large culture shift.

At mid-size growth company, getting things done was still available, but you sort of had to tiptoe around decisions or solutions Co-Founder/CTO or employee number 10 had a personal interest in or battle it out on particularly poor tech decisions. Most progress was made in areas that the team didn't have an interest or expertise in (IE security), but it was ultimately possible to make progress.

And in startup life, probably the least autonomy of all. The engineering manual literally says you only should work on what you've been assigned, as doing anything else creates chaos. Implying, you don't want to be a chaos maker in the eyes of your employer do you? So it's more difficult than anywhere else I've worked to tiptoe around these emotional investments, have any level of autonomy, and move the product forward.

Anyways, I think my overall message is, companies are far too varied to have any idea on what to expect from moving from startup to $bigco. There might be some general trends, but the environment varies so much, you're not guaranteed to see any general trends when making the switch. All that can really be said, is it will be different, and you may have to jump a few times to really see any of the generalizations apply to you.

Note: Using throwaway account to avoid any blowback.


I agree with your overall message 100%. Big companies are like cities. There are "good" and "bad" areas and different people may draw that distinction differently. If you have mobility within the company it's not too difficult to move into what you consider a good area over time. As a consultant / contractor I didn't have that luxury and often got saddled with the teams that needed to change the most, but resisted every opportunity to do so. Had I been a full-time employee and participated in some politics I think I could have greatly improved my autonomy and satisfaction.


> up until $bigco decided to emulate the way it thought the FAANG companies worked

thought being the keyword here, As somebody who works for FAANG, we are allowed a lot of leeway to do what we think we need for the goal set.


Depends on where you go. I work at a BigCo and IMO if you see a "because that's the way it is" and you don't like it, you can change it if you can justify the change.

Everything has tradeoffs and sometimes the cost to change something is higher than the benefits gained, but the people I work with are always willing to listen.


Yeah, same experience. You can't change all of the things but you can change like 1 thing at a time that's really peeving you off, iff you have a good reason & can make a good argument & it's worth your time & effort.


Change at startups means convincing 0-1 people. Change at a BigCo means convincing 5-10 people.

Those require very different tactics and skillsets.


Tip top real estate on the Dead Sea. ;)

http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...


No, that's not the way it works at big companies like AWS, Google, Microsoft (source: me, I've worked at all 3). A large company attracts various types of people. It's not homogeneous like what you describe. Also, there are plenty of opportunities to practice "intrapreneurship" within a large company with lots of resources to impact the world in a positive way.


I don't think he was saying that the people are homogenous, but he was saying that you often get put in a position where somebody way over your head makes a decision that affects your work, and by the time it reaches you, that decision is non-negotiable and unexplained.


I spent 17 years at another tech megacorp and spent the bulk of my time there as an intrapreneur. For me, it was a series of "anointed" roles where I was dependent on (and tied to) a particular sponsor. The sponsor operated on different levels of transparency with their leaders. While I liked the idea of being a "cowboy," it ended up being a serious detriment to my career at that company. The work I did was mostly director and above level, but the recognition/salary was far less. My last sponsor made enough enemies in the "establishment" that he got RIFfed and I got hung out to dry and was RIFfed on the next round.


“Intrepreneurship” is a nice euphemism for “here, you can work on your cute little side projects and then we will keep the IP and patents.”


You can always quit and bootstrap it yourself to capture all the upside. Just beware selling a software engineer salary’s worth of anything is fairly challenging.


Still sounds better than being a feature factory for someone else's vision.


I think you may have read the first word in my comment as “entrepreneurship”; or do I misunderstand what you mean?


“…and give you money”


You are correct. Companies of a certain size are most always extremely heterogenous. There are good and bad places to be in a company and everyone has a different opinion on where those places are.

It also seems that you have experience working at big tech companies. It's not always so diverse and you can't always operate as autonomously as a team at a big company that just needs technology to operate, but doesn't claim to be in the business of producing it.


That's well put.

I did some contracting work for a very large organization last year. It was my first experience trying to navigate the rules inside such a large organization. The interaction that I found most amusing is that I would ask for something that would require crossing an organization boundary and the immediate response would be, "No.", followed shortly by, "Wait, why do you need that?" This happened several times and was just part of the dance required to find the right person to sign off on my plan.


That's a constant.

As an external consultant, do remember you have the power to play the expert.

"Well that's how other Top50 companies I've worked with have done it" isn't the worst card to play.

Usually though, it requires hitching your wagon to whatever VP brought you in, and trying not to burn them with blowback.

Although honestly, most of the time I think it was "No" on the basis of inertia / resistance to change, more than actual disagreement. So technical arguments can win the day there (with other engineers).


There will be plenty of this, and occasionally sub in "that's unprofessional". Requesting to work from home will be unprofessional. Taking PTO will be unprofessional. Coming in at 9:02am will be unprofessional. Requesting the 1-year raise that's in your signed employment agreement will be unprofessional.


I've had this exact argument:

Me: "I'm going to be working from home tomorrow."

Them: "What? First I'm hearing of this. We need everyone here tomorrow."

Me: "I'm confident that I can do the work from home. I have an obligation that I can't go back on. It's been on my calendar as well."

Them: "Not acceptable."

Me: "Alright. I'm taking PTO tomorrow."

Them: very mad "Fine. Work from home if you can."

Ended up winning this one pretty easily considering there were no expectations / limits set on work from home. The just enforced no-work-from-home against people ad hoc.


Also like working with your parents, it is always better to ask forgiveness than to ask permission.

Getting permission/authorization for anything is often a bureacratic nightmare with people who neither care enough to help you, nor wanting to authorize something that might get them in trouble, nor even knowing who's the right person to get authorization from.

As long as you're not breaking important, just do it.


Once when I was frustrated with my current Job at a large corporation, an experienced friend told me the secret.

He said, they'd value "predictability over excellence".

Meaning, talk about your goals, give an estimation and arrive exactly on point. It doesn't matter if it's your personal project or projects/processes where you take the lead.

Being faster than estimated, or finding a better way and switching while your doing it will not be appreciated.

This really unlocked a lot of success and explained many glass walls i've been running into before.


I joined a large company about 9 months ago, coming from startups, and while I knew things would be slower, your quote seems to make explicit something that I've observed in my time here.

I think I had the mentality of "putting out fires" that is always the case in startups, and so for a few months I was stressed that I wasn't doing enough, since my workload was lower than I'd experienced at startups.

But I've learned that the work that is value most is the work that helps others, and what helps others seems to be anything that is highly predictable. So, "showing up" and consistently being responsive and available during work hours. But also writing automations which are visible, reliable, and have a material impact on a team (or many teams).

Thanks for your insight, I think I'll keep that more front of mind in the coming weeks


Well my journey was a bit different than yours. I was Lead Dev at a small startup (<10 people) and went to a non-FAANG Fortune 500 and assumed a Sr role on a team. Things I didn't think would bother were a dress code. It does, it does bother me. Especially in the Summer. I was surprised on my first day that I didn't get to choose my own O.S. I really miss Linux, it really effects my productivity being in Mac. I thought projects Jira tasks would be better planned, they are not, they barely have any information in them. Documentation is a joke somehow. Onboarding was a joke. They just kinda stuck me in there. I couldn't believe I had better processes in place at the startup. Things move slow. Some days I barely have any work, its not much fun. There are things that can't be beat though. Chance to move around. Better benefits. With that said, I'll be looking for a smaller company after I've reached my year mark (they have me in relocation expense cuffs).

I hope your experience is better. If you're going to a FAANG I imagine it will be. This place is much more buttoned up.


This rings a bell for me. Before I started at a big firm I assumed they'd be super optimised to get people going fast, as its a common occurrence for them. What I didn't realise was that you sitting waiting for equipment and logins for 2 weeks doesn't show up on anyones spreadsheet so its not a real loss as far as they're concerned.

Plenty of time for self improvement though if you're just using it as a stepping stone.


Again I've never had less motivation at a job in my life. And yeah, no computer and no licenses waiting for me.


> I find myself seeking out experiences from peers at these behemoths on how decisions are made and products get built there.

I think you will be mostly astounded at the lack of things you can learn from the way decisions are made inside big companies. Which is to say, they aren’t super rational organizations.

As a multiple FAANG alumni, I can tell you that decisions made are often strongly influenced by politics, individual executive “hunches,” and legacy tech concerns instead of raw cost/benefit or actual data.

The fact is, you’re going to make a lot more money doing much less work at FAANG.

However, very little of what you learn about how the organization runs will be valuable outside of the big organization itself.


* Things move slowly.

* You need to be able to play the game if you're going to move up, if you want to stay in the same role don't make waves.

* Other people are playing the game. Sometimes if you're trying to make changes, even if they're going to be beneficial, you are going to run into people who have a vested interest in you not improving things. Don't let it get you down, pick your battles.

* You are way easier to replace than you think you are, don't start fights with people that can let you go. Most won't hesitate to remove you if you make their life difficult.

* Make the most of the perks and don't bust a gut, if anyone notices it'll be because you're making them look bad. Going above and beyond will earn you a pat on the head but nothing more.

* People will be doing everything they can to cover their own ass, don't let them use you for cover.

* Don't get too attached to projects, things get killed or mothballed. Years of work can just be binned without much warning. Make sure you're not defining yourself by what you're doing at work.

I've done my time at a couple of big firms and had people working with me on teams that want to be a 'craftsman' or don't really understand these workplaces, the thing I tell them to remember was "don't fight the waves, just let it wash over you". You can't win, you'll just knacker yourself out and drown.

Don't feel bad if you hate it or want to leave, it's not for everyone. Also don't feel bad if you love it, plenty of people have much better things going on in their life than work and are happy to coast along at a big firm doing what needs to be done.


I can tell that this is hard-earned wisdom from lived experiences as I nod my head in agreement. Thanks for sharing.


here are some things I've learned:

* politics: yes, they exist everywhere, but tend to be amplified at larger companies. polish your political skills, and one thing that I've learned is that it's important to "show, don't tell"

* fiefdoms: there are more of them, some more welcoming than others. be prepared for those that value power above all. you can't take it personally, or you'll go into a very dark place; "be the rubber duck", that is, stay floating no matter what and let the negative wash off of you like water off a duck

* duplication of effort: there likely will be tons of duplication of effort (even parallel projects doing the exact same thing), sometimes it's easy to work with others and come together for a common solution, sometimes it just plain won't happen (see fiefdoms). no real advices here, just that you need to be aware

* technology stacks: sometimes some groups will be stuck with what seem to be very old technology stacks, or things that don't seem to make any sense. look at the group you'd be joining and who they interact with, find out about the pain points before you join so you aren't surprised. even a small change can affect a lot of people at that scale, so approach changes and modernization gingerly.


> polish your political skill

Genuinely curious to know what this means.


Big companies can end up driven by incentives that are at best orthagonal to basic economics which means you often can't convince people to do things that make sense because they make sense.

If individuals are judged based on results against goals declared at the start of the period, they will tend not to do anything other than that. You can't say "the users want this", or "this will save $5 trillion dollars", or "we can't do our job without this" because those things don't matter to individuals. Instead, you have to argue for it to be put on a roadmap, or convince your management to convince their management to push them to do it sooner than 18 months from now. And you have to do it with a light touch, or there will be resentment.


let me provide an example of where more polished political skills might come in handy:

scenario 1, small startup - you're used to working very closely with a small team, know each others skills, strengths, and weaknesses, and can instantly drop in and say, "hey! it looks you're doing in a way that can be optimized, I'm doing the same thing, let's work together and do it right" without ruffling any feathers or destroying relationships.

scenario 2: big company, larger team, lots of cross-team work, same issue. "hi, I noticed that we're trying to work on the same thing and attempting to improve performance in similar manners. I'd hate to have us both duplicate this effort, do you have time to maybe bounce ideas off of each other so we can come to a better solution?" and knowing when to drop it when the answer is "no".

it's a difference in communication styles, which might be more difficult to adapt to when coming from a smaller organization.

does that help?

(note that I could also have said, "well, duh, just learn to communicate better!" but that would have been counter-productive in this case :) )

editing to add that I gave an example for one type of communication, sibling comments to this did a fantastic job of providing probably better examples.


In a startup you may be only needing to convince yourself, or, maybe, a co-founder. Comms are mostly 1-1.

In a larger company you'll need to persuade a set of people to greenlight your project, or convince your executive chain that your team is providing value, or convince other teams that they should support (or at least not actively hinder) your project or team.

Politics can be toxic, but with the most rose-colored glasses, it can just be the practice of working effectively in a larger community.


The biggest thing is that you don't really know anything.

_You weren't in the room when the decisions were made and there is oil tanker momentum based on those decisions.

_You don't have a clue as to who is who. People within the organization know each other in non-obvious ways. There is an invisible informal network built of many years, organizational structures, and projects.

_You don't know which project is whose baby. Two equivalent approaches are not equivalent when one has backing and the other relies on natural selection.

None of these is bad. It's just the nature of blindly encountering an elephant. Good luck.


If you end up in a 'bad' company you may make these experiences:

- there are feuds between companies or even departments in the same org

- decisions are not based on facts but on political circumstances

- the outcome of an analysis is often predetermined

- not the best idea/project/etc. win's but the one with the best connections

- decisions are made that are damaging to the company just to deny someone else in the org a success


"You are welcome to visit anytime to provide input on how we can improve our improvements-processes."

and

"Everyone got heard."


This can be true at companies of any size. Sadly.


Spot on


I worked in small company (50-100 employees) and lead team of 7 people before. After company went down, I joined as IC in big corps. Few things mentioned below might not be relevant to your position. But adding them for every one. Not all orgs are same, so take this with pinch of salt.

- Relax, don't boil the ocean. (This is first advice given to me by one of the director after raising concerns over dev practices being followed)

- Learn presentation skills. Charts are important. Executives don't understand technical language but only charts.

- Stay humble but be political. Avoid heated arguments. Give logical choices to people and let them choose instead of proving them wrong. Make sure to get all discussions on mail. So if later blame game starts, you will be saved.

- In such orgs, some folk stays for decades. They don't care about product or team. Deal carefully with them. But then again you can find some real gems with decades of specialist experience. Learn from them as much as possible.

- Learn proprietary technologies. Most of time such techs are not available for individuals or very pricy.

- Get certifications. Big corps provide very expensive certifications with huge discounts. (But before working on them make sure there arn't any traps. E.g. In my org, you had to stay for atleast a year after finishing certifications or pay back)

- Understand KPI well. (e.g. In startup, you may get appraisal on working hard in weekends and shipping. But in megacorps, that won't happen. You may get some praise but not appraisal)

- If you want recognition, try to conduct department wide technical sessions. People will respect you in (those never ending) meetings.

- Don't invest your emotions in projects. Sometimes they get scrapped quarterly.

- Welcome to world of VMs. Organizations are tuned for operations not for engineering. (I miss my Linux)

- Even though your performance is good, you can get canned. Layoffs are done based on budget not on performance. Keep an eye on Gartner index. Also manager plays key role in almost all decisions. So think once before messing with him/her.

- And last but not least. Don't go in comfort zone. Always keep an eye on market & opportunities.


This is an accurate description of most of the negative aspects of BigCo.


>Moreover, I don’t have a lot of reserve energy in the tank to direct it at another startup after 10 years of blood, sweat and toil.

>...What are some things I should consider before switching?

Take a break if you can afford it. I think that will serve you better than almost any other thing you can do, work related. I've felt this way, and took a few months off, I was champing at the bit to get back to work and start making something happen. You'll think a lot clearer about what you want to do next with some time away.

After you get out of a serious relationship, you need time to heal, regroup, re-find yourself, re-learn who you are, etc before you start dating again. It's similar with jobs you put a lot into.


I hard agree. Startups can burn you out a lot. I've been there myself. The best position is if you can line up a start date a month or two after quitting.


300 is already pretty big. I went from 20 years where by far my largest company was 16 people, to Microsoft, and I'm pretty happy.

The biggest transition for me was the amount of cross org digging and asking and such required. So much is constantly in Flux, and internal integration points are often poorly documented or have apis based off protocols from a decade ago, or whatever else. You spend most of your time doing that, figuring out how to integrate with various old, half supported systems, getting pushback that the integration won't be supportable, etc.

This is in strong contrast with a small company where you are generally working with public, well documented tools, and everyone you work with shares the same goal.

That said, I'm happy now that I have gotten used to it. The scale of things you work on is much greater.

One thing I'll say is don't sell yourself short by taking a job at the low end of where you think you should be and telling yourself that you can work your way up. I made this mistake when I was unemployed but not desperate. Your project could be canceled or there can be blockers or reorgs or whatever else that keeps you back. So wait for the offer that you want.


I've done a startup, a couple of midsize companies (~4k engineers), and AWS. Just my 2c, a lot of the advice I'm seeing here applies more to the midsize companies than at least my corner of AWS.

In my Amazon experience:

* Some very high level project requirements would come from above (e.g. after this date, internal technology X is being deprecated, so you should have a really good reason to put out a project with X).

* Otherwise, decisions were mostly made at a low level, documented, debated with the wider team for an hour, then implemented. This was a little more structured than at the startup, but most of it was that documentation and debate happened before implementation, rather than after implementation at the startup.

* Project managers were somewhat active with the team, but a lot of the features we worked on came from the engineers watching what was used, forum requests, or customer requests through other channels (e.g. conferences).

* There was a focus on getting products out quickly, but tech debt/tests/reliability was a much bigger focus than anywhere else I've been.

* The team was fairly small, and encouraged to make heavy use of other team's internal tooling/native AWS tools for anything that didn't really need to be custom. Interactions with those teams was pretty straightforward and mostly supportive- "We're using your service to do Y, and would like to do Z too, but that doesn't seem possible without some tweaks to your API/service, is that something you can put in the backlog to investigate?"

* An individual team could be quick to change, but the organization as a whole has a lot of cultural momentum in the way things are done, and it's not clear who to talk to to make recommendations. For example, at the startup, I could go to the CEO and express concerns about the newly restrictive information security policy. At Amazon, I'm probably not going to email Jeff Bezos and suggest six-pagers be made available in advance of meetings.

* Transferring teams in Amazon is mostly extremely easy

* Conversely, Conway's law applies hard in AWS- it didn't seem straightforward to offer products or features that weren't obviously under one team's purview without forming a new team.


Having gone the other way, from Microsoft to entrepreneurship, I would say you are better positioned for success. For the most part your skill sets will transfer over to product management in a large company fairly easily. Some things are different though. You will typically be responsible for either part of a product or one product in a portfolio. As such your product or feature's future depends not just on how it is doing in the marketplace, but how it does relative to other products and features in the the portfolio. So you need to work with your managers to evangelize and promote the product within the larger organization as well. You'll have be able to justify its existence, very robustly with a lot of data. Much of the mid-level product managers function within a large company comprises of this activity. This may seem wasteful to you, coming from a startup, where the verdict of the market was everything, but this is how large companies determine how resources are allocated. Eventually the market will determine the future of the product, but for many product managers in large companies, that success or failure will not occur in the duration of their tenure. So one thing you need to focus on a lot is networking with the internal power structures of the company to build support for your self and your team. You have a huge advantage in this respect as an acquisition. They have paid good money to bring your team in, so there is significant awareness of who you are. If you are careful, and politically savvy you can leverage that awareness, and initial goodwill into strong long term support for your team and product.


- Domain mastery is more important than being a jack of all trades.

- Realize you are signing up to be part of a bigger machine, and there are things you will have less control over. This is both limiting and empowering.

- Both people in small and large companies can be smart, but they are typically a different flavor of smart. Learn from them accordingly.

- You should plan to have a much longer lead in terms of getting things done if it requires a dependency on a team you don't work with frequently.

- The team you work on is far more important than the company you work for.

- Be active rather than passive about finding opportunities and projects to work on. You can easily get stuck working in a role you might not be a fit for or a manager you don't click with.


I just started at Big Co!

For my first assignment, I had a question about an API I was supposed to use. I was told to email Bob.

me: "Do I do A or B when using the API?"

Bob: (cc's his manager my email)

Bob's manager: Is your team suppose to be using API? (my manager cc'd)

Two weeks of infighting later, still no answer to A or B, and my task is now past due.


Now you know not to ask that type of question there. Next assignment, just focus on hitting your due date and use whatever API seems right to you... ask for forgiveness later, if needed. Since you're new, you can pretty easily get away with 'sorry about that, I didn't know I shouldn't use that API. Thanks for letting me know!' The more important lesson I would be noting from this experience: there's far more CYA than clarity. (typical big co) So keep your head down and stay out of the line of fire.


Here is my list.

* Things work a lot more slowly in big co's.

* There's a lot more ego involved so prepare for a lot of ass lickers(I really can't think of a better term).

* A lot of "meetings", "discussions", "planning" and so on, which often are just means to kick a can down the road.

* More time to relax.

* Nearly impossible to change the status quo, not impossible but a very slow and painful process.

* Often more freedom to experiment with technologies and proprietary solutions if you find a way to justify them(which is often not a difficult task).

* Plenty of ways to squeeze out training, seminars, certifications and whatnot, just make sure you read the tiny font at the bottom.


There are systems and processes for everything. The plus of that is that there's a lot less winging it, and that you can just hand a bunch of stuff off to people that know how to do it. The minus is that you have to learn who those people are and how to activate them, and it can take longer than just doing it yourself.


Great topic, and I’d say there are already some signs you are asking the right questions. A few of my own thoughts:

Use your capital constrained mindset productively, but be attuned to when to shut it off. Being able to do a lot with a little can be a positive trait inside a larger company (e.g., early days on an unproven project), but you need to recognize when capital should be applied so you don’t risk unknowingly playing small ball.

There is something to be said for another commenter’s suggestion to “relax” a little bit. You’ll need to, because larger companies move more slowly. Be willing to push, but recognize that there are limits to what a large org can do in a short amount of time. That’s just reality.

Try your best to adopt a longer term mindset. In a smaller company you are often focused on what’s happening right now - larger companies have more space and more runway to think over longer arcs of time. What are the implications of what you are doing now a year, or even three years out?


"Corporate Confidential" by Cynthia Shapiro is an excellent book in explaining the various motivations stakeholders at a large company may or may not have.

Although the book can be considered bleak, the point is not to train you to suspect your employer, but rather point out various possibilities of politics and power play that may be going on under the surface that are not so obvious from the get go. I.e. it's a survival manual of sorts to a new and sometimes semi-hostile environment.


> All I’ve ever learnt over the last decade has been by > operating in a capital constrained environment.

Even in big companies you will be constrained by budgets, and possibly even more than you're used to. The big companies have money to try many different things, but normally products start small, and can be killed if they're not going to be profitable enough. Especially if you're ina leadership position, you're going to have to convince people to fund your products.

The other big thing to consider is politics. Don't get me wrong, politics are everywhere, even in startups, but there's a difference. You're going to have arguments with people that you can't go have a beer with after work, and you have to consider how that will affect your relationship after the argument.


The biggest difference I've seen is around product maturity. At a startup you typically have something very new and no reputation. You have to move very quickly to build it out and expand, and you sacrifice a lot to make this happen.

At a big company you're typically working on something much more mature, making lots of money, with many users who rely on it. You still need to make it better, but it's now much more important not to break what's already working. Even if your project is a new one, you still have the company's reputation to protect so you don't hurt existing products. Different companies handle this different ways (I lean towards investing in efficient end-to-end testing and experimentation) but all the options here trade velocity for reliability.


Politics.

You better brush up on your social engineering, learn when to smile and when not to, and watch your back. Rationality and intelligence will not get you far on their own, because the game isn't about who's the smartest or who has the best ideas, it's about leverage, prejudices, cliques, "prestige", and ultimately money.

Remember you're there to play with some toys, occasionally commit code, and get that sweet money.


lol, that last sentence is me rn!


Office politics.

Culture. The fact that it doesn't matter what the company says their culture is and that their culture is defined by the behaviors that they do and don't allow in the workplace. Culture can vary from team to team and department to department.

Deadweight. The organization is going to be full of dead weight.

Get ready to feel under-appreciated and under-valued.


We refer to the dead weight as riders. they're just riding along for the journey but they don't actually provide any actual value to the company. At a startup, those are the first people to go during layoffs or during other downturns. At a larger company they can stick around a lot longer.


Watch Office Space [0]. It'll teach you everything you'll ever need to know about big corps.

There will be office politics, somebody will always either be too hot or too cold in the office, connections will be much more important than talent... yeah, especially that last one. If you want to get anything done in a big company and have any sort of leverage anywhere, connections, connections, connections.

You might get a meek yearly review just because someone in your echelon has cozied up to somebody in a higher echelon and wants a raise.

There might be a company-wide call for product-ideas with the promise of leading your own team should your idea be selected. To be fair, that does happen but the best ideas will be rejected by the committee and then resubmitted as their own.

Whichever company you pick, read the glassdoor reviews and look for stories on reddit and HN. I don't have any links handy but over the years there have been quite a few on reddit about the company structure in GAFAM (Google, Amazon, Facebook, Microsoft). These pictures [1] remind me most of those.

[0]: https://www.imdb.com/title/tt0151804 [1]: https://www.greenm3.com/gdcblog/2011/7/5/organizational-char...


Half the job when trying to get something done, is working out who to speak to.

You'll find out this stuff by a sort of osmosis, there isn't really one person who knows stuff, you just sort of bump into the useful person eventually.

Keep track of names and acronyms, there will be lots of both.


You didn't mention your role and I expect the experience to be somewhat difference depending where you end up in the hierarchy. Generally I'd say that the higher you are the more bullshit and bullshit work there is.

* In big corp there are a bunch of people who are actively just making a living and career out of shit talking and being in the right spot of the machinery doing very little actual work.

* There can be lots of redundant work and other inefficient waste. For example double/triple bug/task tracking systems, several different repositories with half assed mirrors etc.

* There are "gate keepers" who have been at the BigCorp for a hundred years and have managed to put themselves in a position where they get to act as the gate keeper of access to some resource. Examples are some "enterprise" level CVS tools like ClearCase where there's some "merge/release manager" who gets to do branches and merges and releases etc. These people will vehemently resist any change to make these processes more efficient. (see the point about efficiency)

* Some people exist in the organization just to make a career using whatever means possible including bullying, politics, (passive) aggression towards others (trying to sabotage their work, take credit for it), ass kissing, nepotism etc.


From your context description it sounds like you need some extended holidays to put things in perspective.

For me, the biggest difference is that processes in a big co are designed for any single individual to be replaceable. As a consequence, everything is bigger than you and slower to change even if for the best. This is exactly what you're trying to achieve in a successful start-up as it starts with everyone being irreplaceable (to some extent) where you can make a fundamental difference in the future of the company.

Being part of a successful company sounds exciting and you can learn valuable information to apply in other settings but I found that in start-ups you have a lot more room to learn than in a big co. This is because instability in a start-up is very visible and directly accessible (you'll run out of money in X months) so you must timebox everything. However, in a big co instability is more implicit and you can't fail as much. Also unless you can get a fairly high level position at a big co, you won't be able to get "very" relevant experience into building/working the right product because a lot of strategy is not discussed bottom-up in those companies.


A large company generally has more money. I work for a faang, and appreciate that it doesn't take much to spin up big ec2 clusters as personal sandboxes, get licenses for pricey productivity software, fly out to conferences, or take costly risks. If you're creative, you'll find niches of freedom in a big company (flush with cash) that is hard to imagine in a small one. You could feel like a cog in the machine, but that's a matter of perspective. Your team's goals can be subsumed under the obscure goals of the entire company and you may feel distant from an actual impact, but you can choose to view your team as a machine, and not a cog, with its own set of constraints. In a way, even if I don't comprehend the 'why' of a certain goal, I will take it as a given, and still find it fulfilling to problem-solve my way towards it. I don't get why so many people insist on being able to influence goals, directions, etc of their company. I say give me a puzzle to solve, and if it's fun, I won't dwell on the 'why' for too long. It may seem apathetic. My passion doesn't have to be visible all the time.


Prepare for the performance review from day one. Create a folder in your mail client or google doc to keep quotes providing feedback to you, or to keep track of what you have to say about others.


Don't just dive straight into whatever you're asked to do, take a bit of time to understand the department/division/company structure. Try to get a mentor assigned for the first six months, ideally someone from a similar role but NOT your department. Get them to help you navigate and understand the organisation/policies/procedures/key players. In a large company you can be hammered for not following procedure, if you are following procedure you are safe.

This is my own advice to myself, after changing industry four years ago I'm moving to a new company but same industry next month. These are some of my biggest take aways after going in to recover from a everyone got hit by the metaphorical bus scenario with not hand over and little support. I'm probably a bit on the negative side but I think the advice holds up either way.


Try to intuit what your boss and your part of the organization really values. By that I mean what they like and reward, not what they say is important. Understand the difference.

Having a quirk or two is fine, it shows confidence. But you cannot be out of step in too many things, even if it compromises your effectiveness.


Ask people around you, what would they expect from you and your role? (Remember you're new here and unfamiliar with this position and role!1)

If they don't expect much, focus elsewhere. Prepare for disappointments, but if you can keep asking and looking, there'll be no lack of opportunity later.

There may be different periods in your worklife, where you focus on different aspects of work. Don't be disappointed in yourself, but recognize different skills and tools are needed to fill the toolbox. What is important to the corporation is getting the jobs done, not fill your CV. Nobody will care if you do it right or not, but doing it wrong will hinder further development. So getting stuck in quagmire or bubble, is poor job-protection, as at some point in time things will be changed from under your feet.


Your personal development is your responsibility. Figure out how the system works and make sure to take advantage of it.

Any big org will have its system for personal development and advancement. These vary wildly in how well they work and how fair they are. You will have a line manager who's job is in theory to help you develop. They also vary wildly in how helpful they are (middle managers who benefit by keeping good people on their team and so preventing them getting promotions is a classic bad big company problem).

Understand the development system. Understand the metrics and make sure that you do work to check the boxes. Just doing your job well probably won't work on its own to get pay rises and promotions. Every metrics system has its weaknesses - game them to the degree that you consider ethical.


I'm not primarily a developer but from the perspective of going from a very small firm for almost 10 years to a multi-thousand person company. (I also worked for a similar order of magnitude firm in a prior life).

-- There's lots of machinery to support you in various ways. You don't need to do it all yourself. This makes it possible to do things at a scale it's often hard to do at a small company.

-- It depends on the role of course, but harnessing that machinery, coordinating, and getting the word out about anything across the company takes a lot of effort. People are specialized and it's hard to get them to pay attention to things that are not of immediate importance to their job.


I have no idea if you're anything like me, but when I moved to a big megacorp, the thing that caught me off guard is how often you're expected to check and respond to emails.

In a smaller environment, if you have an email that slipped past you, typically someone will just ping you or bother you in person to ask you something, but in a megacorp that's simply not going to fly.

We can actually abstract that a bit; if you're not used to having a lot of imposed structure and restrictions, moving to a megacorp is going to be initially difficult for you. I've been at mine for about two years, and I only recently feel like I've found a workable pattern.


Everything moves slower than you're used to, probably by a tremendous amount. You don't have to have those expectations for yourself, and you shouldn't have them for the people around you.

Politics are the most important thing with respect to large groups of people. Your ideas will matter less than who you are and the clout you carry. Always be paying attention to who is asking for things and why they might be asking those things. At bigger companies, people's personal agendas may trump company agendas, and you may have to pick and choose which projects are worth taking (after understanding the who and the why).


Having gone through a similar experience, I would say that your experience may vary depending on org culture, sub-culture within individual teams, and the traits of your manager. That said, there are always loose ends that will need ownership and that's where your "entrepreneurial" chops would kick in. You approach to execution would/should reflect on the lessons you've learnt.

Startup - Enterprise does not mean a paradigm shift in everything. Yes, there are some aspects that would change. And then there will be a lot of scope for applying your self-made learning and leanings.


Work is not everything, learn rest of "political" skills if you are not good at them, like presentation, speaking, writing.

Most big corps have done really smart people, don't be afraid to actively seek to learn from them.


This is good advice, these are all areas where I have improved.


Endless meetings with too much people, nobody listening and taking responsibility

Everybody CCing the world to cover their asses

Being switched from a project to another because of reorganisation

Your project being cancelled because “not a priority”


Like others have said, RELAX!!!

You don't need to push too hard to succeed. Not rocking the boat (too much) is more important than anything else. You can push teams to greater efficiencies, products to better outcomes, etc. but do this in a slow and methodical way. You won't get any benefit from being frustrated and neither will those around you.


What I did most recently was to start out as a contractor and get a feel for the place. I found a good fit with some other skills (started out as a Vertica admin and got drafted to do some C++/SIMD work, and some stats, and now DW design/dev).

In the end I looked for the same things you would at a startup: growth, revenue, and technical fit, and found a good opportunity within a huge multinational. I've since filed a couple of (provisional) patents, and we're growing like crazy, so our exec got promoted.

We still have a lot of issues like others describe here with Conway's law, inter-group coordination, and so on, but we have clear goals and metrics.

In contrast, I had a previous job at Microsoft that completely stagnated, even as the rest of the company was booming. It really depends on the opportunity.


Bias. A huge deal in these corporates. You’re going to have to either learn how to navigate it or to live with it.

On the other hand, you will get a ton of exposure learning from others and knowing more people. That’s always there for sure at large organizations. Above all, a sense of being a part of a cult.


Competence is irrelevant, popularity and being on message are all that matter from here.


It’s all about trade offs. You will have a tremendous amount of leverage at a big co. Customers who would otherwise not give you the time of the day at a startup will be happy to talk to you. Take advantage of this and learn from them.

On the other hand you will also have to pay taxes at a big co. Big co got that way in many cases because they have an integrated solution for customers. Integration is expensive but worth it. It takes a lot of people to be in alignment to make integration work. And that takes time; you need to be patient and look for opportunities to make a difference.


My experience has been work life balance is better at big co. Benefits typically better. Total comp typically better. Work satisfaction is worse. Innovation is worse. Security, hosting, open source are worse.


"All I’ve ever learnt over the last decade has been by operating in a capital constrained environment."

That won't necessarily change in a big corporate environment. Management can be surprisingly resistant to approving funding requests.

We had significant problems getting the purchase of android and iOS devices approved for product testing, for instance. I'm certain that the human time spent getting the purchase approved cost far more than the actual purchase.


I don't work in the tech field, I work in a large university, and so much of this advice rings true. The university truly is a corporation.


Lots of people are arguing really valid points. I recently switched to a Big Co after 4 start-ups - so I get /it/. I'm just wondering what part is due to inefficiency creeping in VS due to the size of an organisation.

Point being: what about SpaceX, Tesla or Stripe ?

Are they also slow ? with politics and no transparency & co ?


I'd love to read some studies on this to be honest. My guess would be that a certain size its impossible to not have the kind of bullshit this thread is full of.

I'd wonder if it's a related to the age of the company though, or maybe the speed of growth. It's always felt to me like a company seems to hit a critical mass of, shall we say less than productive people, that then work together to hire more people like them and drive out people that want to make changes. Then it just snowballs.


A large company provides lots of opportunities to acquire diplomacy and political skills. Large companies do not move at such a reckless pace so you have time to learn and reflect. Large companies tend to move in a slow, consensual way without taking risks. Sometimes this is actually a good thing


Read this to get familiar with the environment

https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...


I wrote a little about this here

https://zwischenzugs.com/2018/10/02/why-are-enterprises-so-s...


Not everyone you meet has good intentions for you, your projects or the company.


This post is relevant and made it to page 2 recently: https://news.ycombinator.com/item?id=23305216


I find a lot of these things you can expect, are just symptoms of an inefficient company. I wonder if there is a big company out there that moves quicker and cares about their individual employees more?


I personally think that one should always look behind from where they are coming and focus on tomorrow. This will help them achieve their goals, both short terms, and long terms.


What is your goal? Make a career or build cool stuff or ...?

These are very different activities, not in the activities and efforts so much but in choosing where to focus those efforts.


You will probably have less freedom, less authority, and more bureaucracy.

You might have a leg up when it comes to keeping your budget low. Upper management is always happy with that.


I once worked at a Fortune 50 company where keeping your budget low was something that upper management (at a certain level) was not happy with. We once built a hadoop cluster because we needed to "burn" some money (~$150k) left in our budget. In this company coming in under budget meant you didn't do a good job of forecasting your needs so you were punished with budget cuts the following year. That led to so much waste. Coming from a startup where saving a few hundred dollars/months was something to celebrate it was mind-boggling to see all of the waste.


In lots of places, getting anything done can take so long.

You may also fine that there are people with many many reasons why you can't just do things, a fear and inertia.

Good luck!


Expect some resistance for very productive and crazy ideas


My background: I spent most of my career (starting in 2008) working at a few different startups, but have spent the past 4 years working for one of the big tech companies.

There's actually a lot that's the same. If you were hired by a large tech company, they think you can do your main thing (write code, think through product strategy, whatever) well. Most of how you do that thing doesn't change.

You're still working with people. People everywhere are more-or-less the same. Some bosses do a good job encouraging debate/disagreement, some less so, but that's true both at large companies and start-ups.

There's a lot of pressure that comes with working at a startup where a release determines whether the company will continue to have money, something you don't have to worry about as much in a large company. But life in a large company is often capital constrained in a similar way. In a large company, the set of pressures is different (keeping costs down in order to be more profitable, as opposed to being limited by what check VCs wrote), but you still have some budget you're working against, timelines, and the possibility of your team being defunded.

At a big company, you have to distinguish between where your team is in the product lifecycle. Some teams are developing new products. Working for these teams feels a lot like working at a start-up, and comes with many similar challenges. It does have some other challenges - you have pre-defined standards for what it means for something to be ready for launch, but you also have a larger network to draw from in order to get you there.

For established products at a large company, the tolerance for risk is much lower. Other commenters have said "well, you're just a cog in the machine now," but this risk tolerance indicates the opposite: your one-line code change or that feature you designed can make life better for thousands of people, or it can make life a nightmare. There's a lot of individual responsibility that comes with that.

At a large company, be prepared to spend longer thinking through your ideas and defending them to others. This comes with trade-offs: you are forced to think through your ideas, making them clearer and better along the way (good), but also may spend less time on that then writing code (bad).

At least at the large company I work for, I've found the standards are much more consistent. I spent the first 8.5 years of my career defending/recommending/arguing for the use of unit tests (of course, being pragmatic with it, when it's helpful, and all the other caveats that ought to come with that). I have not had that debate in 4 years - engineers here understand why we need unit tests (and code reviews, design reviews, coding standards, linters, automated builds...). I think this has a lot to do with the culture and one group of employees learning the lessons from a previous group, but for whatever reason it might be it does make life easier to take certain standards for granted.

At a large company, the access to experts is pretty amazing. If you don't know how to do something - how to fix an issue with your service, how to get started in new technology, conduct a particular kind of user study, etc. - there's very likely someone who does know that is an email send away. At a start-up, even a larger O(100's) people start-up, your network is more limited.

At least at the large tech company I work for, when people are ready for something new, that usually means moving within the company. This isn't usually an option at a start-up. This means that all that stuff you learned about the company's special ways of doing things maintain transferrable for longer.

I've found an entrepreneurial approach can be valuable at a larger company. At the company I work for, it's not unheard of for new ideas to go to market in the matter of months, but very often management looks for successful milestones at a rate not that different from what startup management or VCs look for: some kind of 2-3 year plan of where you want to end up, and with a milestone release within the next 6-12 months, closed betas before that, etc. All the same things apply about knowing your customer (who, in this case, might be someone else inside the company), understand the customers' needs, start with a problem and not a solution, and all that.

One of the biggest differences has been navigating the corporate structure. At a 300 person company, you probably know who to go to for any possible problem you can imagine. At a large tech company, you probably don't know who to talk to, and you might not even know who to talk to in order to find out who to talk to. Finding the right person to talk to is more of a skill in these larger settings, and it helps to understand the corporate structure, what are the different teams working on similar kinds of things as your team, and all that sort of thing.

So, that's a bunch of things, let me know if there's some other aspect of the switch you're curious about.


Patience and Compromise are your two new best friends.


I just left Google, for facebook about 3 months ago. In case you are interested in comparison, i can help.


if you have a soul, losing it.


I worked about 3.5 years at 2 huge companies, one as an employee (company #1) and the other as a consultant (company #2) as a developer.

There will often be inertia, delays, and even silence when having to go through organizational processes. It took almost 2 weeks for me to receive my laptop at company 1, and then I sat waiting for a week for word of security clearance for a piece of software. At company 2 I started applying for internal full-time positions a month and half before my contract was not going to be renewed (more on that later). I got a single in person interview (after waiting a month for pointless phone screens) my final week. The first few weeks after I left I was getting pinged asking for phone screens on positions I had applied to earlier.

There will be key people who carry tremendous weight politically, fiscally, and operationally. Finding them and making yourself visible/useful will be tremendously beneficial. I was lucky that both people who interviewed me fit this bill. I ended up getting moved into better, more enjoyable roles as a result. The security clearance I mentioned previously was resolved within a few hours of my direct manager emailing the security team manager (who she knew) asking what the status was (I was denied and they never bothered to inform me). These people are valuable for getting you where you want to be in the company, and tend to be more visible internally which is likely to make you more visible as well if you working with/for them.

There are going to be organizational decisions that are inexplicable, and there are limitations to the power of the people I mentioned above. At company 2 the first team I was on was one of 5 that were working on a single web product. The product lead was invaluable due to his domain knowledge and product skill. When I talked to him my final week he told me he was being moved onto another team during a key phase of his current product. The final team I was on myself and another dev was ineligible for FTE because we weren't physically located in one of the 3 areas the team members were located, even though the entire team itself was remote and they had been unable to hire new developers for the past couple of months that we were there.

Sometimes the company is rigid to the point of it being painful, and you're told "That's just how we do it here". We were expected to release a fully fleshed out, bug free product by a set date with zero wiggle room. This happened despite not having anyone to onboard it to for almost a month after release, after which it was barely used because the company decided to focus their efforts elsewhere.

Make a point to have a solid grasp of what is going on in other teams and the company at large. This will help you in seeing any funding/resource changes coming that will directly impact you.

Be mindful of politics and pick your battles wisely. You may not want to do one or both, but knowing who pulls great weight and who is aligned with who should keep your role cleaner.

There are likely going to be people who don't pull their weight, and they can even be above you in rank. Often times this is well known and there are reasons why, even if it's something as silly as the company doesn't fire FTE.

Meetings. There will be more of them than are needed, longer than is needed, and where you aren't needed.

Sometimes teams/groups can have drastic culture changes from the company at large. It can be remote vs in-office, everyone on the team works daily together in a large office (ugh), communication styles (email vs chat vs phone), lunch together/alone, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: