Developer Onboarding Tips
The first day sets the foundations for the whole project. Optimizing the onboarding process for developers who join new teams is something we are constantly improving. We made a process for this that I will share with you.
Have an onboarding checklist
When a new developer joins Agiledrop, we go through a couple of checklists that ensure the new person has given and received all the information needed.
I strongly recommend you to have an onboarding and offboarding checklist. If you are onboarding an external person into your team, you can still use the same list and cherry pick the tasks that make sense. The idea is not to forget something.
Have an introductory meeting
While giving access to tools make sure you have an onboarding call. During this call, you can explain the details of your workflows and processes. During this call, do not talk about specific tasks on the project. Acknowledge that you are bringing a new person on board who has never seen how your team works.
Some key points:
- Who are the people on the project and their responsibilities?
- Who gives assignments and assigns tasks?
- What is the workflow and who is responsible for each step?
- Who is responsible for testing and QA?
- Where does developer tracks work time? Where to track idle time?
- To whom does developer turn when having deployment issues?
- Are there any daily or weekly meetings? When?
At Agiledrop we also include our Resource manager on this call as we like to learn about specific procedures a company has and record them. If some of the processes are not defined we raise that and try to propose a solution that we know works best.
Create user accounts for software tools
My recommendation is to start with an email. Create emails for every person acting as your staff, even one-time consultants. You can then use that email for other online tools. By requiring your email domain for other accounts, you also increase the security and control.
Also, think about:
- Project management tools (JIRA, Asana, Trello)
- Daily communication tools (Slack, Hipchat, Skype)
- Version control platforms (GitHub, Bitbucket)
- Server and hosting (Acquia Cloud, Pantheon)
- Time tracking (Harvest, Toggle)
- Project related accounts (access to Mailchimp for API)
- Miscellaneous accesses (VPN)
Give full access to code
Do not complicate version control with additional security if not needed. The best way to make sure nothing goes into production that should not have is to have pull requests workflow. One example of this is when our developers had access to Git repository which had many Git sub modules that were restricted. Now the lead engineer from the client's team had to manually grant access to other repositories for us to be able to get all the code.
Provide sample database and files
It's a common practice to develop Drupal websites locally. To run a website locally, generally, the developer needs the code, database, and files. Even if you are using installation profiles and build with migration scripts, it does not hurt to provide a sample database and files to the developer joining your team, especially if this is in the middle of the project.
From our experiences, the scripts for deploying local sites get changed along the way, but documentation seldom updates. This results in trial and error while the team debates about "how this used to work, but because of X not anymore."
Even with all the steps completed something can still go unnoticed. It is important to address any issues as they happen. Not fixing them when they occur results in a domino effect with much greater consequences than the original issue was. You should also encourage developers to give honest feedback. Especially if your team has a long history, there is a big chance someone from the outside will find many anomalies that you are ignoring for years and are easy to fix.
Learn to trust people. Nobody wakes up in the morning and goes: "Oh boy, today I am going to do my worst job." By helping and guiding developers, you can get much better results. Make people accountable and let them know you are counting on them and remind them about consequences. By treating people like responsible adults, you will get best results.
Please share your own experiences on how to onboard developers into new projects and teams. Send feedback to firstname.lastname@example.org.
If you're just now in the process of onboarding developers into your team, you can use the checklist version of this article to help make their initial experience a pleasant and meaningful one.