Onboarding New Engineers: Pros And Cons Of Common Strategies
Bad onboarding makes a bad first impression and sets a tone that you don't want within your company.
- Missing out on good people who could have become productive engineers given better guidance
- Not identifying bad hires quickly enough, as you're unclear about their level of work
- Losing productivity due to it taking longer to ramp up to peak efficiency
- Increased stress and reduced happiness of new hires
But when does it make sense to define a structured onboarding process? Certainly not day 1, but not year 10 either.
When a startup initially starts hiring, the onboarding process is understandably ad hoc. It might start with the simple document with the basic steps like paperwork, new user accounts for tools, and how to set up the development environment. Then it’ll go through multiple iterations as new people join and give their feedback on the process.
That's the point we are at now here at StatusPage.io. As we’ve grown, we have tailored our onboarding process for each new hire as we try to figure out the best way to ramp up new engineers and impart our company values.
But we are still actively learning this process. What works now as a team of 10 won’t work as we grow more quickly, to a team of 20, 30, and beyond.
To learn more, we’ve asked the CEOs, CTOs, and engineering teams of growing SaaS companies how they’ve dealt with onboarding as they’ve grown, and how they spin their new engineers up to speed, instilling their company’s values along the way, and get them cranking out code.
Here are 5 of the main strategies that we and they use when onboarding new engineers, along with things to look out for during the process.
Deploying Day One
*“Day One? Commit and ship at least one line of code!”* — Robby Grossman, Director of Engineering @ Wistia.
Having engineers up and running by the end of day one is vital. In fact, every company we talked to started the onboarding process way before the new hire turns up.
At Wistia, a SaaS startup that hosts video for businesses, new hires are sent a style guide before day one, and are asked what else they’ll need — a new laptop or other peripherals — to get going first day. They’re also sent information on any tools and technologies that the company uses that the hire might not be familiar with.
Other companies also make sure that the new engineers have access to any resources or accounts that they’ll need — setting them up with an email account, or inviting them into the Slack channels they’re going to communicate in — well in advance of their first day.
This is all so they can hit the ground running on day one and be productive immediately. That first day is almost exclusively taken up by 2 things for new engineers: setting up their development environment, and meeting the team.
Setting Up Their Development Environment
*“The first thing we have new engineering hires do is to set up their development environment. SumoMe is a pretty complex stack so there are a lot of dependencies to install.”* — Chad Boyda, CTO @ [SumoMe](http://sumome.com/)
Companies automate the setting up of a new development environment to different degrees.
At StatusPage, we have a script that does most of the set up for new hires, so they are ready to go within an hour. This type of automation helps get new people started quickly, but you might not want to invest in this if you’re only onboarding a new engineer every 6 to 12 months.
Pure automation has its drawbacks. For one of our engineers, Tyler, we had his development environment set up for him on a laptop before he started. This meant that he could start straight away, but also that he missed out on an opportunity to learn about the code dependencies and system architecture.
On the other hand, giving new hires time to set up their own development environment with a senior engineer works nicely as a primer to learn the tech stack.
SumoMe is a set of tools for marketers that powers over 170,000 websites. It's a complex stack so they use a Slack chat room for all of the engineers to communicate. This Slack channel introduces the new hire to everyone and they’re encouraged to ask any questions and for help if needed.
A common theme was to provide new hires with a wiki containing the documentation they need regarding the environment setup process and coding style standards. Some have conventions and company practices written down on Github so that they’re always accessible.
Meeting The Team
*“My first day I sat down with Colin [CEO] and Rachel [Office Manager] and went over company policies and culture. Most of it was stuff I knew from our fairly in-depth interview process, but it gave me plenty of time to ask any questions I had.”* — Matt Cox, new Engineer @ [Customer.io](http://customer.io/)
The other major component of day one is meeting the team.
You might think that you’ve got to know they hire, and they you, during the interview process, but getting to know someone during interviews is different than getting to know them as a fellow employee.
SumoMe has a small celebration at the end of their first day with the entire team, where everyone is given the opportunity to meet the new hire and ask questions to get to know them on a more personal level.
What To Watch Out For: Too Much Too Early
The first day should be about meeting the people you’re going to work with, as well as the code you’re going to work with. Though deploying quickly is a great way to get working with people and code, rushing through set up procedures to just get to one line of code might mean the engineer is missing out on something vital.
Packing too much into the first day can mean chores get in the way of the important aspects of establishing a solid foundation for code comprehension and relationships. You want to ramp up the new hire to production quickly, but ultimately you want quality, not quantity.
Mentors & Buddies
*“Pairing sessions are meant to share knowledge, encourage social support and ultimately deliver enhancements in our app. In this way we make sure that a senior member is pairing with a new hire to ensure that this happens.”* — Alvin Crespo, Senior Frontend Engineer @ [Customer.io](http://customer.io/)
Partnering a new hire with senior team member as a mentor was another common feature of the onboarding frameworks. Companies encourage pairing as much as possible, which helps both members of the pair stay on track.
When Tyler started, he paired with a senior engineer for 2 days, then they switched to side-by-side desks. If he got blocked, he could quickly ask for help.
At AdEspresso, a Facebook ads manager that helps you optimize your Facebook ad campaigns, new hires usually work together with one of the senior developers on smaller tasks to learn how the project is structured.
What To Watch Out For: Burn Out & Bottlenecks
There can be problems with this approach. If you’re a small, growing company then the ratio of senior engineers to new hires is going to be low. This can a) cause bottlenecks, and b) lead to burn out among your senior engineers.
Having an assigned mentor means all questions are funneled through him or her, creating a bottleneck.
Mentoring can be a difficult process. Not only are you performing your own job, but you are now also the go-to guy for someone else’s problems. If a wave of newbies join in a short period, this can lead to mental drain on your senior engineers. It also leads to interruptions and too much context-switching, which take them out of their flow.
A solution to this is to have the most recent hire tutor the newest hire. For the new hire they are learning from someone who has only just been taught, with a fresh perspective and fresh knowledge, and who knows what it’s like to be the newbie.
*“Having me dive in head-first was fantastic, it gave me a few early commits which helps feel like you are contributing off the bat.”* — Matt Cox, Software Engineer @ [Customer.io](http://customer.io/)
Every engineer wants to get going with the code as soon as possible, and the whole point of the onboarding process is to get the engineer spun up to speed and contributing to the codebase as quickly as possible.
The framework for ramping up to a fully contributing member of the team is similar among all the companies we questioned:
- On the first day, they’ll have to commit something to the codebase, whether that’s just updating some out-of-date documentation or deploying a line to production.
- In the first week, they’ll start on bug fixes and internal commits to learn the code and company standards under the guide of their mentor or lead engineers
- Within the first month they are expected to have started on small to medium projects within the company, but still with code reviews from mentors and other engineers. They might be pair programming on these projects rather than full-solo.
- After a few months they’ll be seen as fully-fledged engineers and working on main projects within the company, and ideally taking a lead on their own ideas and projects and bringing them through.
All along the way they’ll be working with their team and mentors to perform code reviews and any pull requests.
At Auth0, an identity-as-a-service SaaS, new hires have something to work on after day one. They’re closely coached by their manager and peers but they quickly start working on a backlog feature. During the first week, they already ship some production code.
Other companies have new hires writing tests for particular features or fixing a small/medium sized bug that currently exists. When Dylan started at StatusPage, his first project touched on a lot of different things: some front end code, a third party service, tests for it, and some Rails code.
What To Watch Out For: Sink or Swim
Don’t get caught up in the short-term pressure to produce code.
New engineers need to get a handle on the codebase, environment, and standard as soon as possible so that they can perform their jobs effectively. But, as with deploying on day one, pushing new hires too quickly into writing production code and leading major project initiatives can mean that they miss vital information.
You and they want to contribute immediately, but pushing too hard leads to bad outcomes. Your code quality will suffer and you’ll have sacrificed long-term quality for short-term quantity.
At Asana, instead of having new hires jump into production straight away, they have standardized starter projects that all new hires work on to learn standards and code. They build a chat program over their first few days using their in-house framework. This exposes new engineers to the core concepts of building an application on the Asana framework.
*“We find a depthwise first, breadthwise second approach is best -- let them get familiar with a certain part of the code, and gradually expand their domain of knowledge.”* — Robby Grossman, Director of Engineering @ [Wistia](http://wistia.com/)
All the companies we asked set a schedule for checking in with new hires every few weeks to see how they were progressing. Then they relied on feedback from the engineer to assess their progress and what they needed to be doing.
At Single Grain, they set out a 90 day plan with specific goals at 30, 60 and 90 days to make it easier for the new hire to stay on track. Both they and their supervisor then know what is supposed to be accomplished within the first months of work.
Ideally this plan should be put together by the supervisor together with the employee. That way it can include things that are specific to the new hires strengths and weaknesses, and what they want and need to improve on. On the frontend, are they interested in API communication, performance enhancements, or animation? On the backend, do they want to work on metrics, tooling, or testing?
Short-term milestones at StatusPage might be to create a pull request, create a concern shared between two models, deploy to production, and write a test. Having all this decided early on in the process helps to set expectations.
When does onboarding end? For Wistia, onboarding takes a month:
*“Onboarding should be done within 30 days by our process. I continue to check in with everyone each month but not as part of onboarding.”* — Robby Grossman, Director of Engineering @ [Wistia](http://wistia.com/)
Once that first 30 days is over, the new engineer is no longer part of that process. However, they continue to check in with every engineer every month for feedback, just not as part of the onboarding process.
The bigger point here is that the ideas that are structured in an onboarding process — technical, personal, and cultural development — should infuse your entire company culture. Everyone should be in a continual cycle of development. Wistia’s onboarding may end after 30 days, but all the engineers at the company are constantly learning and teaching. They have weekly engineering shows where people can demo a new project or a new idea, going in-depth into a technical issue for their fellow engineers.
What To Watch Out For: Real Expectations & Feedback
Though having defined goals and expectations for a new hire is ultimately a good idea, not including any fluidity and feedback in the process can lead to difficulties.
Once you have written goals, it can become a mission to meet those no matter what. But in the fast pace world of startups, goals and objectives can change quickly.
At iDoneThis, the founders meet each Monday to discuss a new hire’s progress, and then share this feedback with the new engineer. That engineer can then respond, and share their own thoughts on the evaluation, and ask questions on what they need to do to move forward.
By making sure you are getting feedback from your new hire, first once a week, then once a month, about how their development is progressing, means that not only can you constantly evaluate their progress, but you can also change goals and expectations depending on what they and the company are working on.
Instill Company Values
*“I think company culture is something you breathe everyday, not a slide deck you receive the first day you arrive.”* — Massimo Chieruzzi, CEO @ [AdEspresso](http://adespresso.com/)
All the companies we asked had a lot to say on how to get developers ingrained into the broader company culture and values, and saw company culture as super important. Massimo at AdEspresso has been hiring technical staff for 13 years, and says “after the first interview I immediately know if someone will be a good fit in the company or not.”
The same goes for all the other companies, including ours. As much as we are looking for great coders during the hiring process, we are also asking whether this person fits into our company ethos, and is going to be a good hire for the company as a whole, not just for the development side.
Don’t take culture for granted
Daily lunches, weekly happy hours, and annual retreats are all approaches to get the team to work as one:
*“Once per year, we do a company retreat so that everybody can meet everybody. Last year, we all went to Playa del Carmen in Mexico. Nothing better than Margaritas to bring the team together :wink:”* — Martin Gontovnikas, Director of Customer Acquisition @ [Auth0](http://auth0.com/)
Strongly relating the product to the customer is something we’ve incorporated into our onboarding process at StatusPage. Within their first month, a new hire is expected to take their place in the Sweeper rotation. Sweeper is a week-long duty rotation everyone in the company participates in handling front-line customer support and success.
This role introduces new engineers to the customers and gives them a sense of our momentum both from a growth and product perspective. They hear customer feedback — both positive and negative.
*“The only important thing that we want everyone to understand is that our goal is not just to make a great product, our real goal is to make small and medium businesses successful.”*— Massimo Chieruzzi, CEO @ [AdEspresso](http://adespresso.com/)
When you’re a small company, you’re not just onboarding new employees—every new hire is going to change your company in return. That is why finding the right people, with the right character as well as talent, is incredibly important for growing companies.
If you find great people, but don’t bring them into your company effectively, then all their talent and character will go to waste.
But incorporate them into your company correctly, through an effective onboarding process, and not only will you get a great developer, you will also get the next step in the evolution of your company culture.
With thanks to:
- Chad Boyda & Nat Eliason @ SumoMe
- Robby Grossman & Chris Savage @ Wistia
- Massimo Chieruzzi @ AdEspresso
- Martin Gontovnikas @ Auth0
- Janet Choi, Matt Cox, Stephen Young, & Alvin Crespo @ Customer.io