When does it make sense to join a startup?

Silicon Valley is booming with activity, but excited software engineers often get burned by joining the wrong startup. Startups of all sizes are hiring and, consequently, if you’re looking for your next opportunity, it’s very difficult to wade through the noise. Based on my experience working at, advising, and leading startups through acquisitions, as well as hiring people throughout my entire career (both in and out of the Valley), I would like to offer some guidance around when it makes sense career timeline-wise to join a startup.

Why join a startup at all?

Startups, compared to larger, established companies, can rapidly accelerate your career and propel you in directions that you didn’t expect. The professional and personal bonds you may develop working in close proximity with your colleagues, unlike those at large companies, may very well last a lifetime. Not to mention, the high of building a product and company from scratch and looking back many years from now (if you are lucky) to have gotten something large and sustainable off the ground is one you obviously can’t get from having been one of many at a larger company.

Pros

• Smaller, more intimate work environment and a chance to make a large impact.
• Meet and network with incredible individuals (founders, VCs, fellow colleagues). These individuals can be lifelong acquaintances who may end up investing in you, co-founding a startup with you or just be team members whom you follow to new opportunities elsewhere.
• Understand different facets of building a company that you otherwise may not ever gain while working in a larger firm. For example, an engineer can learn more about marketing, sales, product management simply because s/he sits next to those employees on a daily basis and perhaps interacts with them at lunch. The same is true for non-engineers wishing to learn more about how engineering runs.
• Creative problem solving due to resource constraints (can’t always throw money at a problem, must come up with creative solutions).

Cons

• Less job stability than a more established firm (especially with earlier stage startups). Since roughly 90% of startups fail (for any number of reasons such as inability to close the next funding round or failing to meet expected user growth targets), you might be looking for new opportunities more frequently than if you were with a larger firm.
• Company most likely is focused on a single thing/idea and perhaps if the startup pivots to a new idea, you either like that new idea or search for a new opportunity elsewhere.
• Compensation may be more geared towards equity than cash compared to a larger company since generally the promise of startups is the chance to make it up on the options and the skills you gain while working at a startup.

Finding the right company, and more specifically the right team within a company, can be one of the most important decisions in your life. Just like choosing the right life partner, it can have profound long-term ramifications and path dependencies. The experiences you gain from building a team/product/company, the relationships you build with fellow like-minded individuals, investors, executives, board members etc will shape the rest of your career.

Consequently, it’s best to focus early in your career, while you’re still developing relationships, best practices, and general career direction, to joining a seasoned team. For some, this may come from joining a small company founded by startup veterans where you own large portions of the technology/product, hire and manage folks, and develop best practices yourself, while for others it may be best to join a large established brand and work with those who have similar experiences and more specific responsibilities.

The best way to summarize this concept is with a picture. Figure 1 shows my opinion of what stage company I would recommend joining based on your years of experience. Both dimensions are subjective, of course, and your own mileage may vary, but I believe the overall concept will be useful in many situations.

Dimensions

Years of SW Engineering Experience

This one is relatively straightforward to understand but difficult to define. How long have you been writing/engineering software that’s used by others? This need not necessarily mean how many years have you been working as a software engineer at a company because it’s easy to have “1 year of experience 10 times.” Experience can include independent side projects or significant open source contributions.

Company Stage

Similar to the years of experience, this one can be a bit blurry but let’s try and define it a bit more:

Seed - Series A: Initial team has funding to develop initial version and find/solidify product-market fit. Some of this risk may have been mitigated earlier, some of this risk may still be there depending on the stage of the company. In either case, the team is furiously working to either build or refine an initial version of the product to demonstrate value to their current and prospective customers.

Series B: Company has found product-market fit and is scaling to round out the product to satisfy the market needs, continue delivering to existing and new customers, scale the team to continue iteration on the product, and maybe start expanding (geographically perhaps). Here, distinct engineering teams may start to form as there are more niche needs that need to be filled. Here, the company may also be looking to scale sales and ensure they’re in a big enough market.

Series C+: Growth. Company is expanding to conquer the market and needs capital to grow team, open new offices, continue building new features to satisfy the market demands. Individual teams should be more solid and should “look” (structurally) like a larger company with distinct teams and roles etc. The pace should still be frantic though! Note: This can include companies who are already public!

Startup “skills”

If you’re new to professional software engineering (e.g. a fresh grad from school), then unless the startup is your own or that of a close friend of yours (because working with friends can be cool and rewarding) and you have significant stake, don’t join an early stage startup.

Why? At this stage, the company is in a race against time (and possibly other competitors in the space) to capture market share, close new customers, build and ship new product as fast as possible with limited resources. As such, most startups at this phase are looking for generalists or “full stack” engineers who have experience across the stack including production deployment and maintenance (since stuff always goes down at 2AM). Also early stage startups may lack the necessary time and resources to properly teach you the “fundamentals” of software engineering (and no the fundamentals aren’t necessarily about how fast you can reverse a singly linked list).

If you are thinking of joining an early stage startup then you should have a basic knowledge/understanding of all, and a deeper understanding of one (or more) of:

• System Design - how pieces of a large system (web application, database etc.) talk to each other, what should live where etc. You should be able to evaluate tradeoffs between a micro-services vs monolithic application architecture
• API Design - How to design clean APIs that are consumable by others. This may include library/module APIs, remote API mechanisms (be it RPCs through Protobuf, Thrift, AvroRPC etc) or REST). Which ones to use and why.
• (Web/REST/JS) Frameworks - Rapid development of a product usually happens with the assistance of frameworks. Most companies build their web application with the help of frameworks such as Django, Ruby on Rails, AngularJS, React etc. You should have an appreciation for the features and tradeoffs that frameworks provide.
• Databases (mostly for backend engineering) - Yes Postgres/MySQL is still a valuable tool for most startups since scale isn’t a major problem yet. Know how to query a relational DB (SQL should come naturally) and how to use the tools on top of it. You should know what the ORM is in the web framework of choice what the tradeoffs are and when to use/not use them.
• System Tooling - This is an absolute must. You must have fluent knowledge of a shell environment, scripting within that environment (for simple automation), version control (e.g. git, svn) and IDEs if necessary (depending on the language that you code in full time).
• Software Development Process - There should be a structure for how software is designed, built and shipped and you should have some appreciation for this. Examples here could include knowledge/appreciation of agile techniques (scrum, standup, stories), waterfall (although not always used, certain aspects are), or other development methodologies.

Furthermore you should be:

• Independently capable of building large systems with minimal supervision. This means that you have a good design sense and can pick the right technologies based on some amount of intuition and research.
• Able to work on multiple things at the same time and not drop the ball on any of them.
• There are going to be too many projects going on at the same time for you to drop the ball on any one of them. If you can’t multi-task effectively and deliver more than one thing at a time quickly, then an early stage startup isn’t for you.
• Recognize that requirements won’t be known up front. This isn’t your CS class where you have the requirements for your project spelled out explicitly. You most likely have to sit with your colleagues and/or customers (so long as you have a solid relationship with your customers) in front of a blank screen or whiteboard and think about and quickly implement what it is that is minimally necessary to satisfy the current product requirements.
• Able to write large amounts of “reasonable quality” code in a short time (this is why I talk about frameworks earlier.. they enable this). I say “reasonable quality” because there will be tech debt that you introduce. You won’t get around it. There are going to be modules that you write that you know is a giant pile of #!$ but it gets the job done and you can refactor it later. Accept this and move on.

If you don’t have a reasonable grasp of the above skills, then join a larger company (preferably a late stage startup that is still growing or an established, brand name company) where you can apply what you know but learn from folks who can teach you what you don’t know. There, you can learn the various aspects of navigating (or perhaps not navigating) an organization, learn from senior leadership, hopefully gain a mentor (or few) and also learn the fundamentals of software engineering and other best practices. When you decide to ultimately join that early stage (rocketship) startup, you can more confidently set technical direction, hire others who may either complement or supplement your experiences, and be a more effective engineering leader.

Conclusion

Working at startups can be one of the most rewarding experiences of your life, regardless of the direction the startup takes. The relationships you build there can carry forward for the rest of your career. Working at early stage startups can offer you a 360o view into the inner workings of a building a company and product from hiring, budgeting, fundraising, planning etc. You can quickly learn how to build a business from scratch, learn from those around you and also network with some very influential people.

Despite these benefits, joining an early stage startup isn’t for everyone and it’s important to determine when is the right time to join. While some may say there is never a right time, there are some (engineering) skills that are necessary when considering joining a startup and your contributions (and reward) will be greater if you have a grasp of these skills. If you are interested in joining a particular early stage company that you’re excited about, it’s never too early to start the conversation so that you are connected with the right people so that when the time is right the interview process can be much more smooth and both sides benefit from the move.