This blog post is based on a recent answer I wrote on Quora.

“Sink or swim.” They weren’t the most encouraging words that Sean, Ooyala’s CTO and ex-Google co-founder, could have said to me as I was ramping up, but they did set the tone for my onboarding experience at the company and for my first foray into the startup world. No life preserver was coming – the expectation was that I would be struggling and had better figure out how to survive, fast.

From my first day at the 30-something person startup called Ooyala ¹, I found myself wading through a codebase laced with technical debt and augmented with little documentation and no unit tests, written in a Java-like language called ActionScript that I wasn’t familiar with. I had two weeks to build and launch a feature already promised to video publishers, a feature that would allow them to schedule when their online videos would go on the air. ² To hit my deadline, I needed to learn ActionScript, get comfortable with Ruby on Rails, and familiarize myself with Flash video and graphics libraries, all while tracing through code littered with obscure variable names like “qqq” and questionable function names like “load2” and “load3.”

I ended up pulling two nerve-wracking, 70-80 hour weeks to ship my first feature on schedule. The “sink-or-swim” onboarding experience remains to this day one of my most stressful and intimidating work experiences. In my early days there, I constantly wondered whether leaving the comforts of Google and joining the startup world had been the right choice for me. I eventually acclimated to the new environment and, with the help of the rest of team, the early untested and cryptic code has long since been supplanted with strong engineering practices. I learned a lot from the dedicated team during my two years there, but there’s no doubt that onboarding could have been a smoother and more positive experience.

When I later joined the 12-person team at Quora in August 2010, the onboarding process wasn’t that much farther along. Charlie Cheever gave me a few starter bugs to work on, but since there weren’t any paying customers, there was no time pressure other than whatever was self-imposed. Onboarding consisted mainly of me walking up to different people on the team asking them to explain things to me and maybe one or two ad-hoc whiteboard talks. My onboarding experience at Ooyala and two intense years in the startup world had made me battle-ready for anything though, so ramping up at Quora felt fairly mellow in comparison.

My onboarding experiences would later motivate and shape my later work in building Quora’s onboarding program, something that I’ve written about in detail back in November 2012: What is the onboarding process for new engineers at Quora?

Is it actually worth the time to invest in onboarding?

Startups have lots to get done, and many are racing against time to build a product and to acquire users and customers before funding runs out. So the first question is whether, and when, it actually makes sense to divert away resources to invest into onboarding. Many startups either don’t make or defer making the investment, and instead just rely on newcomers to ask questions and figure out things on their own.

While that might work, some risks of an ad-hoc, absent, or ill-defined onboarding process include:

• Weeding out good people who might have been productive had they been given a little more guidance, which would be a shame given how much effort is typically spent on recruiting someone to a company.

• Not identifying low performers or bad hires soon enough because there aren’t enough opportunities to evaluate their work or because you’re wondering that maybe you just need to give them a chance to ramp up before they become more productive.

• Losing productive output from the new hire because ramping up takes longer than it should have.

• Increased stress or reduced happiness of new hires, particularly those who might not have worked in startup-like environments before.

These risks increase as more people get hired, especially if your recruiting pipeline biases toward more inexperienced hires, like college grads in their first full-time job.

As a team grows, informal onboarding experiences cease to scale. Different employees explain concepts to new hires at different times, and without a standardized onboarding process, it’s easy for those scattered explanations to omit coverage of useful information. An engineer might not learn a key abstraction that would’ve been helpful because his initial projects were on peripheral features, and he never took the time to walk through parts of the core code. Or, if expectations aren’t communicated clearly, a new employee might spend too much time learning new things and not actually be productive until a month in. When a startup is small, there aren’t as many places to look and people to ask to identify what’s most important. As a company, a product, and a codebase get larger, the surface area of things to explore increases, and it becomes harder and harder for a new person, without any guidance, to figure out on his own what to learn first.

The onboarding process is an opportunity to direct the learning and the activity of a new hire toward what the team believes matters most. Designing a good onboarding process can increase the effectiveness of the rest of the new hire’s time. Moreover, the initial time investment to build a good onboarding program continues to pay off dividends with each additional hire.

Designing an onboarding process

During my time at Quora, I led the development of the onboarding program for new engineers and was directly responsible for areas like defining the role of engineering mentorship, organizing and scheduling onboarding talks, coordinating the creation of training materials, and holding mentor training workshops. I started working on Quora’s onboarding program in December 2011, when Charlie and I realized that we would have more than 10 new engineering full-time hires and interns joining that coming summer. Our team was under 30 at the time, with only 14 engineers, so we knew that without a good onboarding process, things could easily get too chaotic.

When first creating Quora’s onboarding program, I knew that I wanted it to be much smoother and less stressful than my own. I started by defining a set of goals for a good onboarding process before deciding on the materials, talks, mentoring, etc. that we needed to set up to achieve those goals. People on the team shared what they liked and didn’t like about their previous onboarding experiences. I also reached out to engineers at other companies (including my friends at Ooyala who had started building an onboarding program there) to get a sense of how they did onboarding and of what worked well.

The goals of onboarding may vary from startup to startup. I’ll walk through some goals that I think a good onboarding process for a new employee at a startup should achieve and describe some examples of what we did on engineering at Quora for each goal.

1. Ramp up a new employee as quickly as possible.

A startup tends to be starved on personnel resources, and taking time to ramp up a new employee does mean a short-term hit on productivity for those involved in the onboarding process. The sooner a new employee gets ramped up, however, the sooner she’ll be productive and contribute meaningful output for the startup. That’s better in the long run both for the startup, since more will get done overall, and also for the new employee, who wants to prove that she can be a productive member of the team.

One way that we emphasized the importance of rampup time at Quora was to assign each new engineer a mentor who’s responsible for the person’s success. We then built a shared understanding where it’s acceptable and, in fact, strongly encouraged for mentors and other teammates to spend time away from their regular work to train new employees. It would be expected that a mentor might lose 25% or more of her productivity training the mentee during the first few weeks. Mentors did things ranging from doing a mentee’s initial code reviews, picking out projects of increasing breadth and difficulty, outlining skills that the mentee should pick up to get more efficient, pair programming to teach tips and tricks, teaching strategies in prioritization, or helping to figure out the best way to work with different team members.

I mentored a number of people while I was at Quora, and I would explicitly tell my mentees on their first day that it was a higher priority for me to get them ramped up than to get my other work done. This helped establish the shared goal of ramping them up as quickly as possible and to set the expectation that they shouldn’t hesitate to ask any questions.

2. Impart the startup’s culture and values.

Every startup culture is different. While a new employee may have gotten glimpses of the culture through recruiting and marketing materials and through meeting team members during interviews, the onboarding process is a great opportunity to ensure that a new hire learns about the values that the team shares. Those values might center around getting things done, being data-driven, working well as a team, building high quality products and services, or something else. A prerequisite to doing this effectively during onboarding is, of course, actually having a shared understanding internally of what defines the startup’s culture, mission, and values.

At Quora, for example, the product lends itself quite naturally to a culture of learning. But there’s actually a tendency to focus too much on learning when first joining a company, especially for those right out of college, and not enough on moving fast and getting things done. To ensure that new engineers learned the company’s pace, we tried to have each new engineer push a commit to add herself to the team page on the first day and to deploy a bug fix, a small new feature, or a new experiment by the end of the first week.

This meant simplifying the first day’s activities enough so that a new hire would have enough time to set up her development environment, make a simple code change, run tests, and commit the change on the first day. It also meant that mentors needed to do some preparation to find bugs, features, or experiments that they thought new engineers could ship in the first week. Because there tends to be a lot of variance in our own project estimates ³ and in how long it takes new employees to ramp up, I generally advised mentors to pick starter projects that they thought they themselves would be able to finish in about a day, so that even if the project slipped, there would still be a high probability that it would ship in a week.

3. Expose the new employee to the breadth of fundamentals needed to succeed.

The complexity of the product, team, and codebase grows as the startup grows, which means there’s more and more surface area for new employees to wade through to identify things that every new person should know. During my career, I’ve also noticed that those engineers who learned the fundamental tools and abstractions well – whether it was because they did a better job identifying what to learn or had mentors or starter projects that encouraged them to learn the key concepts – tended to be much more effective many months later because they knew what was available and when to use them. A key part of a good onboarding program is ensuring that everyone starts off on a consistent and solid foundation with respect to those fundamentals, so that there’s less variance in terms of who learned what based on initial project or mentoring assignments.

Two ways at Quora that we accomplished this on engineering were by:

• Setting up a series of ~10 onboarding talks in a new hire’s first two or three weeks. These talks introduced the codebase, explained git’s data model, walked through testing expectations, demoed debugging and profiling tools, and covered a variety of other topics that we thought were important for new hires to learn in their first two or three weeks. The most important ones (like an introduction to the codebase) I would schedule every time a new hire started, even if it was just for one new hire, while some others I would batch together until there were more people.

• Writing codelabs to explain abstractions and tools at the company. Codelabs were a concept that I borrowed from Google. A codelab is a document that explains why a core abstraction was designed, shows how it’s used, walks through relevant parts of the codebase, and then provides a set of exercises to validate understanding. I spent about three days writing a good, first codelab that others could model off of, and then recruited others on the team to pitch in and write other codelabs on core abstractions and tools that every engineer ought to know.

These investments primarily involved an upfront, one-time cost to create a reusable resource followed by a relatively small recurring cost to update outdated materials and to actually give the talks.

4. Socially integrate the new employee onto the team.

At a startup, you’re likely to spend significantly more time with your teammates than at many other places. It helps to encourage more team bonding with new hires, especially the ones who might be more shy or quieter.

Early on at Quora, we relied mainly on mentors to help introduce the new hires around. Later on, some members of the team started organizing small group lunches to help give more structured opportunities to meet other folks on the team. Batching new hires to start on the same day also helps to create more of a sense of camaraderie.

These goals are just some examples of what you might want to think about in designing the onboarding process at your startup. As startups grow, onboarding goals may also change. For instance, based on some talks with engineers at Facebook (granted, not quite a startup now) who worked on the Bootcamp onboarding process ⁴, it was important to have new engineers decide which team they might want to join. During Bootcamp, the new engineers would try out small projects relevant to those teams. That wasn’t an onboarding goal until the organization actually had well-defined engineering teams.

It’s important to realize that building an onboarding program can and should be an iterative process. Maybe you’ll simply start with a document on how to set up a development environment with the goal of getting a new engineer ready to modify code after his first day. Perhaps you later realize that not all starter projects necessarily provide the same rampup benefit and decide to articulate a set of guiding principles on how to pick good starter projects. Maybe you notice that you’re giving the same codebase or architecture walkthrough over and over again and realize that it would be much more effective and efficient if you just prepared a talk for the topic.

Wherever you are in designing an onboarding process, think about your own onboarding experience and survey others on the team to get a sense of what worked well and what could use some improvement. Think about where new hires struggled and what things you might be able to do help them ramp up more quickly. Think about key concepts, tools, and values that you wish you had learned earlier during your time at the startup. Once you have some ideas, implement the most valuable ones, and then survey later new hires and team members who work with them to see if the changes helped. Rinse and repeat, and hopefully the onboarding for your new hires won’t be stressful as my own experience at Ooyala.

If you’re looking for more advice on how to build a good onboarding program, feel free to contact me.