Building and executing a goal-focused onboarding process prepares new outsourced engineers to contribute high-quality code. Many teams neglect to properly onboard outsourced developers. Maybe since they’re not in the office and not a full team member, people assume it’s not worth their time to onboard?
Don’t fall into this trap. Set up a clear process that turns new outsourced software engineers into productive members of your team.
Below, I’ve provided a framework/checklist to help you structure your formal onboarding process for outsourced developers. Using a checklist is a simple way to quickly, and consistently, integrate a contract developer into your software development workflow.
1. Introduce your company: Start with a brief overview of your company mission, values, and goals. These are often brought up in internal meetings and used to make organizational decisions. Even without realizing it, you’ll use them to manage outsourced developers. They’re part of your company’s DNA. Help them understand the background of your company and they’ll be able to make better decisions on their own.
2. Get to know them: Take this time to build a foundation for your working relationship. It’s amazing how much more approachable you will both seem to each other by starting with some personal details. Through this, you build the trust necessary to have solid communication. You will also be better at understanding their motivations and learn how to better manage them.
3. Learn their skills, strengths, and weaknesses: By learning your outsourced developer’s skills, strengths, and weaknesses up front you’ll be able to better leverage them and avoid their gaps of experience. I’ve found that once an outsourced developer is hired they’re more honest about their capabilities.
However, recognize that the culture of any contractor or outsourced worker is to say they can do things they can’t. It’s how they get work. Know how you can best utilize their skill set at the beginning. Otherwise, you’ll end up paying for them, in both time and money, to learn something new.
4. Show them how to work with you: Make sure they know what it’s like to work with you. Here are some common questions that they should have an answer to: What are your responsibilities? How do you like to communicate? What are your expectations for them? How do you provide feedback? What’s your management style?
5. Describe the project: It’s critical they understand the context of what they’re working on. Cover the project’s purpose, history, priorities, and goals. They should understand why a project exists and what the company hopes to get out of it. If you do, they’ll be empowered to make many small decisions that help your long-term goals.
More tactically, walk them through why your team chose certain technologies, languages, and frameworks for this project. It could be that you decided against using a library for security issues and you don’t want them introducing it again later.
6. Identify the project’s architectural assumptions: You and your team probably made many decisions about this project’s software architecture. To keep your outsourced developer aligned with these decisions you should discuss them during onboarding. They should know why you’re using an architectural pattern and how to best work within it.
Depending on their role, this may or may not apply. However, if you skip over this section, it commonly opens bugs and security vulnerabilities due to workarounds of systems already in place.
7. Get to know the team: It’s surprisingly a common mistake for teams to completely separate an outsourced developer from an in-house team. If you do introduce them to the relevant team members they’ll have more resources inside the company and have more confidence in asking questions when appropriate.
Some teams will assign a mentor at the company for them to help onboard and answer their questions. At a minimum, consider introducing them to the in-house product manager and another engineer (this can be you). With these relationships, they’ll know who to ask questions to.
8. Grant repo access: Needless to say, they can’t make any changes without read/write access to the correct repositories and a local environment. Grant them access to the repository with the right permissions and have them set up their local environment. If you have a thorough README, they should be able to get pretty far on their own. Otherwise, if you think it will get them set up faster, you’ll need to take the time to walk them through the setup and file structure.
Note: GitHub, GitLab, and Bitbucket all have permission options at the organization, repository, and branch level. Take note of what they have access to and be cautious as to what repository and branch edit rights they have. Many master branches have experienced an accidental merge.
9. Live by a process: A poor process is often the main reason for bad results when working with outsourced developers. Make a proactive decision to follow a process with them. Either one that incorporates the outsourced developer in your team’s process or one that’s created just to manage them.
You might think this is obvious, but some teams that live by Agile pass major tasks to outsourced developers with a waterfall-like expectation. Not surprisingly, this doesn’t work well. Deadlines are missed and the end result doesn’t match expectations.
10. Preview the development workflow: Walk them through what a complete pull request or merge request looks like for your team. They should know the definition of done beyond the acceptance criteria. Depending on your team, this might include expectations around writing tests, programming style guides, static analysis tools, and linters, code review, and continuous integration/continuous deployment.
11. Pass the PR/MR test: Just as you would for any new engineering hire, have them submit a pull request or merge request to test their understanding. If you did all of the above steps, they should take a JIRA task, complete it, and submit a pull request that makes code review easy.
12. Review and provide feedback: For the first few PRs, overdo code review. Have multiple team members review and provide feedback. Do this until you feel confident that they’re familiar with your standards and process. This also helps you determine early on if this outsourced developer is the right fit for the project or if you need to cut your losses and find someone else.
You can expect code reviews for your outsourced software engineers to take more time as they don’t have the benefit of working as part of your team. You can add a code review service to support your team’s code review process and reduce bugs.
With the checklist above as a template, you can prepare any outsourced developer to be a valuable resource for your team.
