A few weeks ago, a friend starting her internship at Google recounted to me the response that people in the Harvard “entrepreneur” community gave her when she shared her decision to pursue a summer job in Mountain View. She was told that going to work at a big company, particularly as a creator and innovator, constituted selling out, and that little of value can be learned. “You’re wasting your time” is a frequent line. It resonated with me as something that had come up for me when I decided to work at Google — accusations that I was giving up on the dream in exchange for a well stocked cafeteria and playful t-shirts.
While the lack of constant updates on this page might suggest that I have indeed “given up” on creating things, that is far from the truth. I’ve been learning a tremendous amount from working at Google, and it’s worth considering this when considering the criticisms of startupists.
Starting your career at an existing technology company might give you:
Experience with diverse parts of the product adoption curve.
Almost by definition, when you’re working on a startup, your customers and users fall 100% into the “early adopter” camp. If you’ve read the insightful book Crossing the Chasm or studied technology product cycles generally, you’ll know that markets for technology go through a lot of phases, from the initial innovator and early adopter crowd, through the pragmatic users, and onwards to the laggards and skeptics of technology. Working at an established company means that you’ll experience the needs of each of these diverse sets of customers, which would be difficult to get in a small startup.
Understanding of business process.
Process is important. And I’m not talking about Dilbert-style bureaucratic busywork — but the processes that make tech businesses sustainable, like managing information or hiring employees. It’s surprising at first, but just putting a bunch of smart people in a room doesn’t mean you’ll make anything work — there are dozens, if not hundreds, of other things that you need to get right in order to have success. There are legal consequences to decisions made, there are existing customers who need to be supported, there is research to be done into what works and what doesn’t work in the market, there are spammers who will take advantage of you, and there’s a whole news- and blog-osphere that needs to know what you are (or aren’t) doing.
Even from the point of view of code itself, there’s good hygiene you can learn from a large, existing codebase. The startup ideal, as I see it, is just rockstar engineers hacking away into the night, adding features as soon as they’re concocted, and stretching scarce resources as much as possible to cover for spikes in traffic. But writing code is just the beginning. When will it run? Who will be responsible for keeping it running? What style will it be written in? Who makes decisions about refactoring or deprecating certain components?
This goes not only for tech startups, but for other industries as well. As a writer in college, you don’t gain much insight into writing beyond writing (drafting, typing, correcting) itself. But it’s just one part of the puzzle: researching, fact-checking, copy-editing, publishing, and networking are all integral parts of the writing world that you can learn about in an accelerated manner by seeing the internals of an established player.
Another point is that if you’re working at a startup, chances are that your personal point of view is just a consumer. But, Businesses are customers too — B2B sales of products and services are a sizable part of the economy, and seeing what is important to existing businesses might help you out if you ever want to sell to enterprise customers.
Understanding the impact of design decisions.
I’ve learned a tremendous amount about tradeoffs in engineering and design having seen firsthand the consequences of particular design decisions made months or even years ago. The blogosphere is littered with posts “MongoDB vs. Redis” (really, X database/framework vs. Y database/framework for all X and Y), but very few honest or complete accounts of the history of particular technologies and what has worked and not worked.
I learn about this all the time working at Google. Seeing the infrastructure for particular applications, and what works and doesn’t work about them, provides a great learning platform for when you’ll have to make these kinds of decisions yourself. It’s like learning from the mistakes of others — but instead of through abstracted generalizations, you will see firsthand the consequences of these decisions and how they affect what’s possible today.
It’s no surprise that Bret Taylor (former Google APM turned Friendfeed founder and eventually Facebook CTO) put a lof of thought into the design of database setups : I don’t know him personally, but my hunch is that during his time at Google, he got to see how various systems worked and where they failed.
Diversity and specialization.
Pretty much every startup I know is hiring for the position of “generalist”. A company like Google also hires generalists. But what Google will do is put those generalists to work on a very concrete and specific problem domain. I am blown away by how nuanced and detailed my conversations are at work — people are given the opportunity to specialize and truly master a problem domain, and just being around them (as long as you have a “sponge” attitude) has taught me an incredible amount.
This specialization isn’t just in terms of focus area — it’s also about background and experience. Chances are that most of the people working at a startup would be more or less the same age as you, with the same background as you, in the same city as you. But at a larger company, you might experience a broader swath of humanity and backgrounds. In particular, working with people internationally is incredibly valuable in breaking the bubble that we surround ourselves in. Similarly, learning about online defamation law from a coworker who has been doing it since before “online” was a thing sometimes feels like being in law school myself.
Examples of good and bad management and teamwork.
At any company with more than 10 people, you can’t really say that everyone truly “knows” everyone else. And you’ll see a whole variety of management and teamwork styles to either emulate or avoid.
Management styles are like hairstyles — there are an incredible amount of them, and the same style might appeal to some people while cause others to abhor it. Seeing a variety of management styles, from the detached and laissez-faire through meticulous and exacting, you can choose how you want to shape yourself as a leader, but not only though intuition or second hand.
The same goes for collaboration in engineering and design. It’s qualitatively different to work at a place with a handful of engineers in one room, and a team even just twice that size. Exposure to myriad ersonalities and work styles will teach you about making effective teams. Some people plan everything meticulously, are very talkative about design tradeoffs, and work at a constant pace. Others might work more independently, seemingly silent for weeks while they tinker and toy around, only to submit their code right when it’s needed.
Time to pursue interests.
This might seem a bit contradictory, since a common criticism of working at a company is that you have to adhere to a schedule without personal time, but in my experience, working within boundaries has allowed me to pursue my interests more deeply. I’ve seen some people at startups, like my college roommate Kuba (working at Lore ) work every day of the week late into the night. This is at the cost of being able to pursue explorations outside of his work. I too have “burned the midnight oil” working at Google — but a nice part of company life is that weekends are mostly respected. I’ve found the work/life disctinction to be critical to my holistic development — I’ve been able to read a lot, explore side projects and new technologies, and get back in touch with old hobbies like photography.
Caveats.
Of course, there are many reasons to not work at a large company. It’s clear that you won’t have as much ownership over your own work, the direction you’re going, or the impact that you make as an individual. You might have to defend decisions that weren’t yours, even if you disagree with them. You might have a sour manager, or you might have a distant manager who leaves you wondering what your contribution is.
Ultimately, the meaningfulness of what you do depends on your own input and effort as much as the place where you work. Creating your own business, joining an existing startup, or going to work for “the man” are all great ways to develop as a person, and none should be discounted categorically when considering what you want to do after graduation.
