Imagine that it’s your first day on a new job. Before you’ve even finished standard onboarding procedures, your manager tells you, “You’ve completely f*cked everything up. Leave and never come back.”
That’s exactly what one Junior Software Developer heard after he followed the onboarding document to set up his local development environment, which inadvertently resulted in the clearing of the production database. U/cscareerthrowaway567 has since shared his story on Reddit and rightfully received a great deal of support and assurances that this catastrophe was not his fault.
If a manager is shouting profanities at a new employee on their first day or a new developer has the ability to wreak such havoc on your database — it’s not their fault. It’s yours....or more accurately, a fundamental failure of your onboarding process.
While we don’t know which organization u/csscareerthrowaway567 was unceremoniously dismissed from, we do know that such mishaps are not limited to nameless companies. Similar incidents have occurred with Amazon’s Elastic Load Balancing Service, and more recently GitLab, which suffered a loss of production data and hours of service outage.
When welcoming a new developer to your team, from the codebase to code standards, team workflows to team culture, and more, there is a lot to bring them up to speed on. By adopting strong onboarding practices, not only can you avoid the type of disasters mentioned above, but you can integrate your new developer as a fully competent, productive, and satisfied team member.
To help you achieve this, we’ll introduce some best practices for onboarding a new software engineer including:
Hiring may not typically be considered onboarding, but it is the requisite step. Get the hiring wrong and your onboarding won’t matter much.
Many successful hires begin with a referral — references and social proof in the form of a referral is a great way to verify the credibility of candidates. Referrals or not, you’ll want to review portfolios and past work. You can also review any open source projects they have contributed to on repositories like GitHub or SourceForge. Understanding their past work will give you a better idea of their technical skills and the types of projects they are most interested in.
Don’t underestimate interest. Finding a developer who is genuinely passionate about your use-case, business model, and technology will go a long way, not only in the first few weeks on the job, but in sustaining their motivation as a productive team member for the duration of their employment with you.
When bringing on a remote developer, interest and passion will be all the more important. Without an on-site manager and team members, it will be completely up to the new developer to immerse themselves in the new team and the accompanying challenges. Here at Codementor, we’ve had the opportunity to sit down with a handful of startup founders who run distributed teams. When it comes to hiring, they all emphasize the importance of passion.
Zapier’s CTO, Brian Helmig, told us that when interviewing a prospective team member, he prioritizes passion and knowledge. Helmig loves to find people that are already part of the Zapier community as users and are excited to bring their expertise to the product. He goes on to say what they really look for are “autonomous doers” who don’t need a social workplace.
Similarly, Hotjar CTO, David Darmanin, looks for passion and potential. For David, that means someone who has demonstrated growth in their career, is ready to expand their skill toolbox, and has a growth mindset. In other words, someone who is “hungry.” David says he’ll take hunger over experience any day:
Someone who has done it all, achieved everything — I don’t want to assume — but they’re probably going to be a little less hungry than someone who is still growing and coming up in their career.
Another often overlooked hiring tip is involving your current employees in the process. Depending on the size of your team, including project managers and internal employees in hiring decisions can help to build confidence, boost team spirit, and pave the way for successful formal onboarding. This type of transparency in the hiring process helps to neutralize any anxiety current employees may have regarding bringing on new talent, who can sometimes be seen as a threat. In addition, allowing team members to meet prior to onboarding helps to build the network that will be necessary to carry the new hire through onboarding and becoming a fully integrated team member.
For more tips on hiring, you can read this previous post: The Ultimate Guide for Hiring Freelance Developers. If you need someone to help you find an on-site developer, Staffing Agency Alternatives to Robert Half Technology may be able to give you some leads.
Documentation will be of paramount importance when onboarding a new developer, especially one working remotely. In our chat with Zapier’s CTO, he drove this point home saying, “information should dispense automatically by design, when it's needed.”
To provide team members with the information they need to do their jobs effectively, you should document everything: from user guides of commonly used tools, organizational charts, SOPs, common bugs and how to solve them, workplace setup, software tutorials, anything that requires step-by-step instructions, organizational charts, and contact lists. To stay organized, all of this information should be available in a centralized place, like an internal wiki page. To streamline the onboarding processes, some have suggested a welcome ebook or a tutorial series. While this would require some initial investment and planning, once launched, there would be minimum upkeep and it would be of lasting utility.
When it comes to developer specific documentation, you have a whole ‘nother realm to consider. Each dev team should have a standardized way to set up their local development environment and workflow procedures. Teams should choose the workflow framework most suitable for their projects and programming process — some popular workflows include GitFlow, Feature Branch Workflow, and Trunk-Based Development. As early as possible, you want to integrate your new developer into this workflow.
Repository documentation should not be overlooked. This should include a wiki detailing how to use the codebase, how it’s been designed, manifestos on core principles, and any other long-form content pertinent to the project. Also include a README, which should be a quick introduction to the project.
Mentorship can be an invaluable aspect of new-recruit onboarding and team building. Just because you have an efficient, knowledgeable team and a motivated newcomer doesn’t mean a mentor-mentee relationship will automatically form. Like all other aspects of new employee onboarding, mentorship needs to be thought-out and executed with care.
From day one, or even before day one, new recruits should have a person to reach out to who is ready to answer any technical questions, introduce the team, and even walk them through initial projects.
Don’t make the mistake of always assigning mentor duty to your most senior developer. Eventually, they are likely to get burned out and resent the additional burden AND the new team member. In fact, having a more junior developer take on the responsibility is a great way for them to put their knowledge to practice, give them leadership opportunities, and quietly check that they are up to snuff.
When onboarding a new developer at Codementor, our dev team transitions new programmers into their new development workflow by quickly assigning an easy task for them to complete using GitFlow practices. This helps the new dev gain a sense of achievement and contribute to production while learning the workflow. Tasks can include rebuilding dashboards, writing a new algorithm for a matching feature, updating or building new features, or any less complex task that helps the new developer start participating as a team member. In typical production cycles, it’s not uncommon for tasks to be defined as they are being built — however, this should be avoided when assigning introductory tasks to new developers. Initial tasks should be well defined and have clear scope to avoid confusion and frustration.
Here are some tips for mentors-to-be:
Even before work begins, you should start to include your new team member in communications: email chains, Slack channels, weekly updates, etc. There’s no need to pile everything on all at once — ease them in one channel at a time to let them get comfortable with your communication flows.
Once the developer joins your team, have regularly scheduled updates. Be prepared to answer their questions and address their concerns. Weekly updates can be done stand-up style where everyone reports what they have done in the past week, what problems were encountered, what needs to be improved, and what is on deck for the next week. Ideally, your stand-up meetings should be followed up with written notes that everyone has access to.
In addition to team meetings, you should use regular one-on-one meetings to check-in on new hires. One-on-one meetings are a good time for you to let your new team member know how they are doing and give any feedback or suggestions for improvement, but also for you to listen to them. Managers should encourage new engineers to give honest feedback, share what they have enjoyed, and anything they may be struggling with. Zapier has a useful meeting strategy to solicit two-way feedback we’ll call the four one’s. In sit-downs, one of the founders will ask the following questions:
Having standardized communication structures and clear performance expectations are important to onboarding, but integrating a new developer into your company culture will add a shot of stay-power. Encouraging creativity and spontaneity with team building activities is a great way to help your new developer feel at home on your team.
One way Zapier does this is with what they call pair buddies. This is a random pairing of two teammates who are matched for a 10-15 minute chat. The focus should not be on work, but rather on personal or professional sharing, so teammates can get to know each other better. Of course, the end goal is a stronger working relationship.
Other distributed teams have been known to have virtual beer meetings. Everyone can grab a beverage of their choice and have an online team building session to talk about random or designated topics. It may sound strange, but it’s a way to bring online relationships to life a bit more.
In addition to spontaneity, also embrace ceremonies to be held at regular intervals. Ceremonies can include demos of soon-to-ship features, buddy coding day, hack day, or whatever else you’ve got up your sleeve. Hack days are great opportunities for developers to take a break from regular sprint-based work cycles and activate their creative programming skills on problems that interest them most.
If you’re interested in how hack days work, check out what Codementor’s dev team produced for our last Hack Day!
Plan ceremonies so that everyone can join, including any remote team members. Ceremonies should bring a dose of consistency, an opportunity for everyone to share their talents and recent learnings, and hopefully becomes something your team looks forward to.
A healthy combination of ceremony and culture building will help to promote personal relationships and team spirit — this is a vital part of helping new developers fit into your team culture. Culture and attitude fit will likely be the most important factors determining whether or not your new hire ultimately becomes a successful long-term member of your team.
To best evaluate the performance of new developers, it’s important that they work in public. Programming related tasks can be done on platforms like Bitbucket or GitHub where everyone has access to the repository and can see what pull requests have been submitted or what changes were made. Non-coding tasks should be done in shared spaces like Google Docs, and updates made on project management tools like Asana or Trello.
Evaluate not based on time spent but value produced. It is useless to be constantly looking over your developer’s shoulder. Instead, keep track of the tasks they are working on and create an environment that allows them to produce valuable results. Do this by sticking to clean code standards, code coverage expectations, and timeboxed sprints. Use a code review process to make sure new team members are meeting code standards and offer suggestions on where they can improve. Additionally, have periodic discussions on current workflow processes and address any barriers or bottlenecks.
Lastly, measure by quality, not quantity. Remember, 1,000 lines of messy code will never be as good as 100 lines of clean code.
To the greatest extent possible, you should include remote developers as if they were actually on-site.
All onboarding procedures can be done digitally, with the help of video chat and your run-of-the-mill virtual office tools. Though it may take a little more effort, team introductions, and mentoring can, and should, still take place with remote team members.
Whether you are working with remote freelancers, part-timers, or full-time employees, becoming part of the team means learning about the company. Many companies use an introductory course, or at least have some required reading, introducing the company's history, values, mission, and long-term vision. If remote team members understand the company and its goals, they will be more likely to feel like they are part of the team. It’s important to help remote developers feel a sense of purpose within the company and camaraderie with team members. They are more likely to be motivated, loyal, work conscientiously, and have overall stronger performance.
Even after remote team members are fully integrated, their goals and workflows need to continue to be aligned with the company’s initiatives and long-term goals. To do this, Hotjar annually drafts a one-page strategic document and asks that all teams and individuals align their work with the company’s North Star.
For tips on keeping remote teams engaged and motivated, check out how Alertboot manages remote engineering teams.
Don’t expect perfect performance the first couple of weeks a new developer is on the job. The average employee takes upwards of six months to become fully competent in their role. In this article, we have offered some tips to help you reduce this time.
What we have presented here is not a rigid template to be followed, but a formula to be adjusted for your specific project and team. To optimize your own onboarding process, you can ask yourself a series of simple questions:
If you can answer these questions and address them in your onboarding procedure, you’re on your way to successfully integrating a new team member.
With the proper onboarding process, there will be no need for profanity, (unless that’s your culture), or data loss, which we’re pretty sure isn’t part of your company culture.