Why You Need To Work For A Big Company
onstartups.com
onstartups.com
- Process is not the enemy, inefficient process is the enemy
- Project Management makes a huge difference
- Technical people make for bad managers
- Communication is critical, ego only creates conflict, learn to pick your battles, don't sweat the small stuff: how to deal with your work and other human beings
- Perks are the last thing you should worry about
- When nobody cares, everything turns to shit
- Not centralizing/simplifying management of resources makes everything take a lot longer to get done
- Salaries are arbitrary and 2 weeks of vacation is total bullshit
- Health insurance for non-corporate people is expensive
- Unless you want to fix the same problem twice, do it better the first time
In my experience, it's "some technical people make good managers". Some of them are bad managers; most of them are somewhere in between.
Kind of like regular people. :)
Companies which have limited advancement opportunities within the technical realm force technical folks with no desire for management into management positions that they're unfit for, leading to the conclusion that technical people are bad managers.
I see someone's already generalised it to the observation that systems grow until they are failing systems.
corollary : efficient process doesn't exist
Could you expand more on what you mean by the vacation stuff? Do you mean like it's total bullshit that you only get 2 weeks? I was not sure how literal to take that.
Companies strip away between 1/3 and 3/4ths of your personhood (depending on the person) and autonomy in the world.
Try not to get stuck.
This is in the US, of course. In a humane country you start with 3-4 weeks, and I think after a couple of years in some European countries you get around six months of vacation per year ;-)
I make iOS apps, and contribute to fairly large state-wide systems. Besides rote governmental/enterprise work, I also get to fool around and make interesting things because my role is also technically a "research" position. Did I mention I see/talk with my supervisor about 4 times a month, and he trusts me totally?
All that's awesome and everything, but there are downsides too. I am considered Junior, and will be for the next year (been there a year already). I make less than some of my coworkers despite being able to code circles around them (and architect systems better). Others are really, really damn good, so that's not always the case either Part of the problem is my degree - I have a Bachelor's in Art (of Arts too, but you see my point). This means that I'm fixed for at least the next year below my actual value, which sucks. My direct coworkers on the Mobile team are awesome, my age, share liked interests and we share a camaraderie that is probably absent at a lot of big companies and startups alike. Tradeoffs abound, but personal happiness and autonomous professional development are what I'm taking for the time being.
Don't sleep on BigCo or unusual positions just because it isn't sexy startup land in SV. There's a whole wide world out there too.
I've seen and personally worked at a company where 2 weeks was not only your vacation time, but also your sick time as well. A government contractor I had worked for gave out 4 weeks (which was also sick time). Currently, I'm at 3 weeks.
Most places use vacation as an incentive - stay with us x number of years and we'll give you another week of vacation. I personally haven't stayed at a place long enough to realize that benefit.
Often you end up burdened with expensive corporate-friendly technology as well as "official internal tools" which are in every way vastly inferior to open source stuff but you have to use them because that's what the company has chosen to use.
A great example in this vein is sharepoint. Other examples might be, say, team foundation as source control versus git, or IIS vs nginx, etc.
How much experience do you have with TFS? It's a different animal than Git, but my TFS-using colleagues really, really like it.
I've found that every workflow I can come up with is "wrong" in some way, but none of the documentation tells me what the "right" way is. Git may have been in a similar place when it was first released, but nowadays there are plenty of good tutorials that walk you through the way to think about it.
The GUI is clunky and requires lots of clicks to perform routine tasks. For example, to view a file's history, you need to open each changeset individually and diff the file in each one. The command line is no better, and makes heavy use of the "observe something to initialize it" anti-pattern.
The main draw seems to be its integration with issue tracking, unit tests, code reviews and project management. It's trying to be a one-stop shop for everything, but the problem is that each feature has a better stand-alone equivalent. So you either lose the synergy of having one tool for everything, or you sacrifice the features that you really want from your favorite source repository, code review tool, diff utility and bug trackers.
This has become quite a rant, but I'd really like to hear a good explanation for some of these things, or at least somebody to tell me what I'm doing wrong. The worst is when somebody knowingly says "come on, it's not that bad" without actually offering a more functional workflow.
Overall, TFS, as a source control system, is pretty decent, definitely in the top few of the best source control systems out there. However, it has a lot of downsides. It's a serious pain to administrate, and an even bigger pain to initially set up. It has a huge number of "quirks" that are really just misfeatures or defects for most users. For example, binary files are exclusive checkout by default (meaning only one workspace can have a specific binary file editable at any given time) which seems like a good idea naively but tends to bite you in the ass almost always in any real-world example. And most TF admins aren't smart enough to know how to change the setting for it, as far as I've seen anyway. Also, access control is like pulling teeth, you'd think it should be easy-peasy given that it's all GUI based and what-not but it's crazy. Similarly, things like triggers can work in completely non-intuitive ways that are really easy for, say, a moderately trained dev who's trying to be a part-time admin to screw up in ways that impact a huge amount of people very quickly (which I've seen happen routinely).
There are some nifty features, like shelvesets, and it supports a reasonable branching model with a reasonably decent merging system, though if you use it long enough you'll probably eventually run into one or another nightmare scenario that takes a long time to figure out.
For most projects I wouldn't recommend it over, say, git + github/gitlab or other free source control options. The one advantage that TFS has is that it's far more capable of handling extremely large code bases (e.g. hundreds of gigabytes of data, millions of files) as long as it's configured well, whereas git will pretty much just choke.
Also, the Visual Studio integration of TFS is pretty good, so if you use that as your primary IDE TFS will have a moderate advantage in ease of use. Of course all of this scales to how skilled you are with using source control at a low level anyway. If you're a dev who has zero interest in learning anything more than "checkout/checkin" and you hope that merges and branching and whatnot are handled by people who are not you then TFS is pretty much right at your level, it's definitely super easy to use for those common cases.
Also, see my question to parent.
Also, it doesn't seem to be 'true' FOSS because we get access to dirty HEAD code and not the code they use for the 'enterprise' version.
They further refuse to commit the name 'stable' to any of the community versions.
But who makes for good managers?
- Economies of scale #1: when you're purchasing 10,000 instances of something, people listen and new techniques of doing things become available.
- Economies of scale #2: Design changes when milking an extra $100 out of the design or manufacturing process means saving $1m at 10,000 instances. You get exposure to new design/manufacturing techniques as a result.
- Project diversity: I could find 20 projects in this office of 150 engineers, all significantly different. They range across design, asset management, PM work, maintenance/reliability, acquisition, etc. Each applies to a number of different targets - fixed plant, mobile assets, facilities, etc. If I grow bored of something I can reasonably rotate to something new and different within 6 months. More long-term, there's opportunities in multiple countries if I so wish to pursue them.
- Institutional knowledge: I can walk in to our drawing room and still find drawings dated from 1870. Some of the greybeards here seem almost as old, and come with a huge amount of knowledge (both specific and simply general 'tricks of the trade') that isn't recorded anywhere.
There's also downsides:
- Work sometimes feels like it's a game of thrones. The fiefdoms can grow tiring.
- Stuff happens slowly. BigCos carry inertia that can be cumbersome. Counterpoint: inertia can produce some amazing results if you get everyone paddling in the same direction
- Career advancement usually requires jumping ship to different companies. Said greybeards are in it for the long haul and unless a new position opens up, you're generally stuck below the glass ceiling.
+ People who have never worked in a megacorp often think that their literal internal decisionmaking model is "MAXIMIZE THE EVIL.", which is both wrong and will not allow you to successfully predict their behavior.
After you understand that, it's VASTLY easier to get Microsoft to give you money, and you might find that Microsoft (or whatever BigCo) you're dealing with considers More Money Than I've Ever Dreamed Of (TM) to be a fairly routine decision, in the same manner that you might decide to purchase a new keyboard.
In terms of communication style: learn to talk to business people. ROI and TCO over TDD and DRY, PowerPoint decks over README.md in your Github projects, wearing a suit when appropriate instead of making fun of people who own one, etc etc. It's really not hard to learn how to talk like someone if you listen attentively. You've done this your entire life in other contexts and other communities. Decisionmakers at BigCo are not intrinsically a more hostile audience than, e.g., your local freestyle rap club meetup thing, the rhymes are just different, yo. [1]
[1] I should stick to WoW metaphors, but you get the general idea.
I'm in the process to write a book about this. Are people (young people especially) interested in understanding how to position technology into the enterprise?
It's quite common for someone to jump ship and then turn around and do business (or even just recommend) their old company for something.
That's part of the reason burning bridges is such a horrible idea.. because it's a small world after all. It's a small, small world.
This is probably one of the hardest (and most valuable) lessons I have learned in college. If you don't take the time to develop your social skills, life is going to kick you in the teeth. Repeatedly.
Having worked at several small companies since, it's disappointing how often I get to watch teams find out the hard way why things are done this way, or not that way. Sure, I will point out the potential folly along the way, but few care to hear it, and instead wish to invent their very own wheel because their case requires a special kind of roundness.
Of course Microsoft is a big place and different divisions work differently. I'll never take the risk of landing in such a mess again, though.
That sounds horrible. Did you mention your concerns to the people who owned those meetings, in a way that made it clear you were trying to help improve them?
I've had success several times with this in BigCo, with various satisfactory outcomes:
1. "You're right, this meeting is BS! But it has to happen for various reasons X Y Z -- since you don't care about this area you don't need to come, we'll grab you if we need you."
2. "You're right, and other people feel tuned out as well, so let's try cutting it to 10 minutes / mailing out an agenda beforehand / starting exactly on time."
3. "You're right, this is an inefficient way to gather state so we're going to just swing by each person 1-on-1."
4. "You're right, this team is too big so we're splitting in 2/3 smaller groups"
I think the project I worked on was worse than average because it was the sort of cross-cutting change that affected a lot of different teams - six different products, I think? There were a lot of PMs involved.
It's worth testing the waters a few times. You'll know pretty quickly if they value your input, and if not you can decide if you want to continue working for them.
In particular:
"You see lots of very good ideas (like proper source control)" - you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?
"You get to work with lots of clever people" - no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves.
"They have lots of perks" - Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.
"You are not going to be sent on that week-long training course on using Oracle or have your part-time MBA fully-funded while at that boot-strapping startup." - Ok, starting to think this is a case of Poe's law in action...
Yeah startups (and small companies) come with their share of headaches, but I'll take it any day over the soul-crushing, creativity-stifling cubicle hell that is a big company.
"You see lots of very good ideas (like proper source control)" - you mean the group that still uses VSS 4.0 on a network share b/c they're terrified of moving their repo to Git (or even SVN)?
Unsurprisingly, companies that have millions of lines of code have to take extra precautions.
"You get to work with lots of clever people" - no, you get to work with people who work there for no reason other than they live close to the office and have spent the last 14 years building an impenetrable fortress around themselves.
This is a lazy dismissal.
In reality -- lots of smart people work at big companies and small companies. That being said, big companies will invariably have more people dedicated to research than startups. Microsoft Research alone has over a hundred people just doing brilliant things.
"They have lots of perks" - Yes, that one day a year I got to donate $5 to cancer research so I could wear bluejeans (collared shirt still, of course) makes it all worth it. I'll take my catered breakfasts, lunches, impromptu beer runs, work-from-anywhere policy and unlimited vacation days, thank you.
Again, this is lazy and untrue -- unless you want to say that Facebook and Google's perk packages are about wearing bluejeans -- but I think playing the perks game is silly anyway. Distilling things down to money (with some exceptions, like WFH) is always the smarter way to go.
---
Personally, I think the biggest difference working at a big company vs. a small one is that of depth vs. breadth. At a startup, its not beyond the realm of possibility to understand the majority of the code base: you'll be wearing lots of different hats, doing lots of things at once. At a big company, the organization is usually such that you'll spend your entire employment working on one little niche -- this has its advantages (you become an expert at that one thing) and disadvantages (you're only an expert at that one thing, after all).
Personally, I can't imagine why someone wouldn't want to just spend time at both types of companies and see which one they like more.
Which is why they drive to work in a Model T and rely on an IBM 7090 for their backroom stuff, correct?
Being cautious is the opposite of using technology which is inimical to good practices.
This is a goofy analogy. Whining that BigCo, Inc. won't shift their embedded "way of doing things" is like whining when it's not easy to up and move the Empire State Building... there's a ton of architectural complexities and in the end the building is still making money and housing people.
Not that I'm advocating the status quo just "because", but the reality is that big companies work via risk models that determine it's often better to stay with the SQ than move "forward".
In comparison, hopping around with tech in a startup is like packing up the RV and shuffling somewhere else... it's lightweight and easy to do so.
Perhaps my experience in each world was exceptional, but I have a feeling they were rather typical.
The big difference is that most "large companies" people will work at are not Google and Facebook. Name any other enterprise who's motto is "move fast and break things". That is a rare culture. Even Google, who's engineers report that they're catching a bit of the dread corporate-itis is still different from your average enterprise.
More commonly, enterprise is known for being a place where fast moving is discouraged, individuality is stifled, pointless bureaucracy is the order of the day, mediocrity is indirectly rewarded, and productivity and common sense take a back seat to political demands.
You'll take the startup experience you have had over the big company experience you have had. Crucial difference, there.
A lot of large organisations are quite aware of the world around them, and are entirely capable of taking the better parts of startup culture and absorbing them. I work for a big company, but on a small team (there is five of us) that is largely trusted to know what we are doing. There is no dress code, and I can work from anywhere if I so require.
On the flip side, I have many friends still in Startupland who are in working misery. Just because a company takes on the label "startup" doesn't magically make it a fantastic place to work- in some ways you could argue they're likely to be worse as there is considerably less oversight.
I have all of those perks at my 200 person company now, but with a fraction of the start-up risk. (Which may be a plus or a negative, depending on who you are.)
What it comes down to is every company is different, regardless of size; there are pros and cons to work environments of all sizes.
What helped, I think, is that I was part of a small team in that big company. At peak we probably had about two dozen programmers, with 8-10 on my team. That's not much bigger than the team I'm on now in a tiny company where I also get to work end-to-end.
I disagree with specializing as you get older: there's going to be a tendency to do that, but it's the last thing you want to do. Never stop learning, never stop broadening your skillset. Sooner or later you're going to be a 40+ year old developer looking for work, and if you're a specialist you're going to be looking for a long time. As an experienced developer with a proven track record of adaptability you'll be able to justify the salary that you're going to want/need.
1) You can actually get to work with a lot of companies. We acquired a ton of companies over the years, and I'd often go work in those companies post acquisition while it was still being run as a separate company. So these were smaller companies that were generally successful - you got to see a lot of different practices.
2) Once you are done learning a new job/role (or new company as above), you can easily get the opportunity to move to around to different departments or jobs. I personally did consulting, product management, engineering, architecture, sales operations and strategy (sometimes for the mothership, sometimes for the acquired companies).
3) It's not about smart people I wouldn't say - its about mentors. At a small company, there are just less senior people around, and they are often more focused on delivering. At a big company, more senior execs are really willing and able to mentor the superstars in their teams that make them look good. You combine that with moving about companies or departments, and you get a mix of different mentors with different styles and strengths.
4) It won't apply to everyone, but I personally must have evaluated 50 - 100 companies for M&A or partnerships. I know exactly how to analyze a business, where to look for skeletons, what works well/what doesn't, what a big company will look for (and what are red flags) in an acquisition, when you can/can't get a partnership and what you can use to your advantage in negotiations, etc. Will all be extremely useful skills when you're on the other side of the table.
Between the above things, you can learn so much. Stuff like the food/work environmental is so irrelevant compared to this.
Don't get me wrong - I have no intentions of ever going back to a big company again. But these were the big benefits for me.
that nailed it.
What the author doesn't mention and what I perceive as a great plus are the tools and infrastructure I get to enjoy. We've got a lot test equipment, machine shops and technicians a smaller shop couldn't afford.
On the other hand, I keep hearing managers say "we have to be nimble, like a startup". I think that's exactly the wrong approach, big companies should approach big problems that startups can't tackle.
Second challenge of big companies: trying to keep up with all of the latest project code names which change on a weekly basis.
I work at a medium-sided company now (~200 employees according to Wikipedia), and I love it. We have a great mix of technology and perks, and are all treated really well. I worked at a handful of start-ups during the first tech boom (and during the crash), and some were exceptional and some were meh.
I wouldn't rule out working at another start-up sometime in the future; it would just be one of the many factors I consider.
I work for a company with over 60k employees and the technology is incredible, and the people are interesting and super smart.
I learn an awful lot? Because I can't learn things otherwise? Come on.
I get to work with lots of clever people? No problem doing that now.
Large community? Ditto.
Perks? Uh... how does that translate to "need"?
You learn the art of politics. Great! What you're saying is, I need to work for a big company so I can learn something that's only useful when working for a big company. What?
You have time to reflect? Why assume that all small companies are balls-to-the-wall, 100-hour-week, venture-funded, Valley startups? Oh right, because this post comes from a fantasy world where the only two kinds of companies are gigantic Googles and tiny places filled to the brim with foosball tables, not actually the Earth where I live.
You get a baseline? What is this I don't even.
I don't see how you can decide open-mindedness based on a point-by-point refutation of what are some pretty blatantly silly points.
So, if your only gripe is the word "need," I agree. Your tone I think is a little reactionary though. There are legitimately valuable things to learn in an "enterprisey" environment (even if many of them are around what _NOT_ to do - you still learn something best by experience, not reading blog posts or books or chatting with friends or whatnot), and there are some surprising benefits, depending on your personality type (stability, sometimes pay, etc).
Just my two cents, YMMV
I worked for a time in banking IT & development at two large UK banks - both as a full timer and as a hired gun from a consultancy. I never wanted to but it happened out of necessity/luck. It was pretty dull work. That said I got a valuable insight into how these huge organisations operate, what makes them tick and how to communicate with them.
I now work for a small web hoster that focuses on hosting for businesses (SME and corp) and have done for a few years.
The eighteen or so months on the banking gigs (despite being dreary times) taught me a lot of non-technical skills that allow me in my current day job to deal with and onboard some customers that are fairly large organisations.
Unless you know how to communicate with large organisations, and often on their terms and with their sorts of business protocols, then the chances of your startup or small company landing a nice steady earner/gravy train from BigCorp are minimal. The only way to do this is to go and spend ~18 months on corp gigs - either as a full time employee or contractor. I wish I'd done it earlier in my career.
You don't know know what you are missing till the time you experience it. Dharmesh Shah is one of the more acclaimed entrepreneurs in the industry and I do believe his words more than someone who doesn't even know what it feels like working in an environment he is commenting on.
I have no idea who Mr. Shah is and don't really care. I am criticizing the article, not the author.
Yeah, I felt the same way about learning computer science fundamentals as an experienced developer, until I actually did.
They laughed at Einstein. The also laughed at Bozo the Clown.
Pointing out that a similar opinion about a completely different thing turned out wrong has no bearing, at all.
You're not going to acquire the experience of knowing what it's like to jump headfirst into fixing a build break during the runup to release on a billion dollar product unless you're working at a company that has a billion dollar product, of course.
Every CxO at every large company looks at startups as the model to emulate - lean, focused, full of feedback.
The benefits listed, every single one, are examples of overlooked, hidden or inefficient practises by the large company - practises they try hard to eliminate.
Do you think the CEO of Megacorp thinks that weeks "training" in Amsterdam was a good use of his money? Do you think he realises there are good passionate people trying to do good on no budget. If he found out he would either give them a budget or fire their arses for working in the wrong things.
As for your time for reflection ... screw that, reflect at home.
No - big companies are trying very hard to stop being a source of "informal" VC money, rest stops for the tired and weary or uncontrolled cash spenders.
One day they might succeed.
Would you mind defining success for us?
A large company that is efficient, fast to react to threats and opportunities, can monitor and measure each and every part of its own behaviour in real time, and have that feedback passed to all employees
Just a company that is large acting like a well run small outfit
If I had such a business, I'd be trying to figure out how to plow 25-50% of that profit into experimentation and expansion.
10 years ago we had "6 sigma" pandemic in the Valley, last 5 years - "lean" and now ... behold their monsterous progeny.
Still, some people just can't look at a rubric to help you organize your thoughts/analysis without dropping to their knees and worshiping it as the second coming of Christ.
Lean, 6S, TQM, CQI, not a single one of them has conclusively been shown to actually work long-term (post-6 months). But, on the bright side, it's a fantastic job for getting to see every last corner of operations in an organization. I'm using the position to learn the pain points of my preferred field, before going into start-up land to address their needs.
The dangers of informal VC money is another factor that drives experienced managers away from that strategy.
I would guess that projects of all stripes need some sort of escape velocity to fly by themselves. Things like initial enthusiasm, number of people who might be affected, likelihood of them complaining or ability to veto, degree of risk, reversibility - all of which means gravity at a large company is much higher.
Now if you want some definitive advice on where not to work. Don't work for a husband and wife operated company, ever. There you will encounter the worst aspects of a lifestyle business combined with nepotism (especially the unfireable but totally incompetent spouse).
Otherwise spend some time in a combination of startups and big companies. Both have their strong points, and remember 90% of startups fail, so its not as if startupland is nirvana.
Whenever we "rewrite" an application that has outlived any possibility of keeping it alive, we can't start from scratch: we have to continue meeting all existing customer needs. So even from day one designs are often bloated and frustrating. There is no "MVP".
Meanwhile at a startup you can "move fast and break things", and when an application starts to get stale either it can go away, or you can switch to another startup and begin fresh.
What? Not to disparage people my own age but that seems like hyperbole. Is this the image most people have of startups? Fresh out of college at 23 (a few months ago) I couldn't even find a decent startup (that I wanted to work at*) that was offering positions to new grads.
Worth keeping in our minds when discussing such topics, before passing them off as competitive or cultural failures.
I had to quickly learn how to present my argument in a non-confrontational way, get individual buy-in (and perspective) from all stakeholders before any meeting, and balance being transparent and forthright versus protecting your interests (it really helps that your interests aligns with company goals!).
To sum it up, "politics" IMO has made me a more effective leader.
Big companies have been good for: - Providing training - Formalizing feedback - Introducing me to a lot of people
But they also: - Stifle career progression ("We have you doing X, so we are sorry that you can't help on Y") - Are not nearly as safe as their size would suggest - Tolerate mediocrity
Other than that, I prefer the creative chaos of startups to the process and tools over interactions and individuals of large companies (even the ones that pretend they're agile)...