Bobbie's Blog

Boys be ambitious.

Y Combinator's Startup Advice: An Academic Perspective

Y Combinator (YC) is a startup incubator that had launched many successful companies including Airbnb, Coinbase, Dropbox, Reddit, etc. YC’s founder Paul Graham wrote an inspiring article, “Do Things That Don’t Scale,” that gives solid advice to startup founders on what they should focus on when starting a business. I find it interesting that when I read the article through the lens of academia, Graham’s advice appears to also be useful for people heading into an academic career, such as myself.

I have noticed that there are a lot of similarities between building a startup company and building an academic career:

  • Both startups and academics strive for novelty (i.e., being correct is not enough, you must also be different)
  • Both startups and academics get to attach their names on their work (i.e. unlike in the industry, things an employee built are owned by their companies.)
  • Both startups and academics need to promote their work themselves (e.g. founders do marketing, scientists write papers and give presentations)
  • Startup founders and junior academics both have flexible schedules in their workdays, but they both need to work really hard or they fail.
  • Both the startup world and academia have high probabilities of failure.

YC’s startup advice, the academic version

Disclaimer: I am writing these as an exercise for myself to think things through. If you are a junior academic searching for career advice, please take them with a grain of salt.

In the business world, people know the economy of scale. But Graham pointed out that at the early stage of a startup, it is actually important to focus on things that don’t scale. Here are a few pieces that I think are also valuable for academic people. I will state the original advice from Graham, then map it into the academic context.

  1. Recruit users manually. People don’t automatically come to you just because you have built new products. People may have other things to be busy with, or they may not appreciate or trust what you’ve built (e.g. think of Airbnb in 2008). You have to go out to find users, one by one, and help them use your products. Likewise in academia, new ideas don’t just get accepted; you have to go out and discuss with and persuade your colleagues, give seminar talks, present at conferences. In particular, you’d like to discuss with the few people who are most interested, they are the initial “users” of your work.
  2. Act as a consultant (who builds something just for a particular customer). Sometimes YC would ask founders to pick out a single user, help this user solve their particular problem by using your software yourself on their behalf. This can be an effective way to know what it’s like to be using your product, what is lacking, and how it can be improved. Likewise in academia, if you have invented a new method, one thing you could do is to go out and help people (who may be in a different field from yours) solve their problems. This is not only a way to stress test your method, but you are also more likely to get quality feedback and get inspired to do further studies.
  3. Manually build your prototype from ground up. Sometimes, YC would advise hardware startups to assemble their machines maually. By going through each tiny step, you get better knowledge and will be able to tweak your design faster in the later stage. In the academia context, “hardware” may correspond to our own brains: you should spend time to understand the fundamentals before doing anything high-level. For example, when writing your own code, try not to use the existing libraries at first, but write everything from scratch and get better understandings of each component. The knowledge will later be helpful when you want to optimize for more serious work.
  4. Go out extra steps to make your users happy as far as you can. Extraordinary customer service is what startups can do that big companies can’t afford to do. (I happen to know one perfect example: try order a Klein bottle from Cliff Stoll, he will make it a best day of your life.) Another reason is that any products can’t be perfect from the beginning, so spending time to make users happy is also a way to get feedback. Interactions with initial users are what keeps the startup fire from going off. In academia, your “users” are your collaborators, your peers, your mentors, your students, and people who use your methods. Great “customer service” in academia means to contribute to discussions, to give people their due credit, and to be thoughtful and responsive, etc. At the end of the day, we are human beings. We like people who are helpful, respectful, and easy to work with. We are more willing to help such people as well.

The roadmap of startups or academic careers is multi-dimensional: you strive to do novel things, but you also need to do unscalably laborious things, especially at the early stage. Graham suggested to think of this multi-dimensional task as a vector rather than a scalar. I made the following diagram to illustrate this idea:

Some people (including myself) tend to focus solely on doing research and hope everything else will take care of themselves eventually (path A in the diagram), but in reality we often need to also do the unscalable things in the other dimensions, such as to improve our skills to present, to communicate, to collaborate, and to help others (path B in the diagram). After all, scientists are humans; career goals are social, not just personal. Building a career is not just about personal gains, but also about helping others and making the world around us better.

Comments