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.
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
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.
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.
Here are some tips for mentors-to-be:
Get started early with planning, documentation, and SOPs (like code reviews)
Don’t solve their problems — help them figure it out by themselves
Give and receive feedback
Help them learn from their mistakes
Do regular pair coding exercises
Encourage independent learning with recommended reading like The Pragmatic Programmer
Communication
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.
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:
One thing you are worried about
One thing you are excited about
One thing I can do better to help you with your job
One thing you can do to improve
Culture
Encouraging creativity and spontaneity with team building activities is a great way to help your new developer feel at home on your team.
Evaluation
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.
Lastly, remember that evaluations should not only be for the manager’s and the company’s benefit. Developmental feedback is key to helping engineers learn and grow, and collaborate better across teams.
Conclusion
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:
What does my developer need before they start?
What information, hardware, software, etc. do I need to provide prior to day 1?
What are the biggest time consumers with new hires?
What are the most frequent mistakes made by, or in connection with, new hires?