Bringing software engineer contractors onto the team is a great way to speed up project development. They usually equip with skills that we need, and they are ready to do it. With a proper plan, it can be a great tool to the business. In this article, we’ll go over the best practices to onboard contractors based on my experience.
💡 Key Takeaways
A structured onboarding process/plan helps contractors integrate smoothly and start contributing faster.
Setup a feedback loop to help moving the process faster, as well as making a decision on whether we should keep these contractors. Use performance metrics to support those decisions.
Utilize tools to speed up the onboarding process such as documentations & automated tools. This ensures good product quality when new contractors join the team.
Managing Contractors vs. Permanent Members
Working with contractors and permanent employees are very different. This article describes well on the difference, and here is a summary.
Flexibility vs. Stability
Contractors offer us great flexibility. We can bring them in for specific projects or to fill skill gaps. This helps our engineering teams stay agile and adapt to changing needs. When there is a big project coming in, we bring more members in; on the other hand, we keep a smaller them when we are only working on smaller projects.
Permanent staff give us more stability. They stick around longer and really get to know our systems. This can be great for long-term projects/products. Most IT companies hope to work on long-term products.
We often find that a mix works best. Contractors can jump in to tackle new tech or tight deadlines. Permanent folks keep things running day-to-day. The proportion can be tricky, but I would recommend keeping around only 10%-20% contractors. Too many contractors will add instability to the team.
Onboarding Differences
Getting contractors up to speed is different from permanent hires. We need to move faster. Here's a quick comparison:
- Contractors: Brief overview, focus on project specifics
- Permanent: Deeper dive into company culture, long-term goals
We make sure contractors get the key info they need to start coding ASAP. For permanent staff, we take more time to build strong connections.
Junior engineers often need extra support, no matter their status. We pair them with senior engineers when we can.
Communication & Engagement
Keeping everyone in the loop is crucial. We use different strategies for contractors and permanent members.
With contractors, we focus on:
- Clear project goals
- Regular check-ins
- Specific task assignments
For permanent staff, we also need to discuss:
- Long-term career discussions
- Involvement in team initiatives
However, it does not mean that we don't discuss careers with contractors. In my experience, most contractors are eager to grow in their career as well, but for practical reasons, staying in an contractor agency is the most reasonable choice for them. It's best to clarify with them whether they are looking for long-term career growth as well. Mixing some career-related discussions in the communication with contractors can contribute to stronger bonding.
Performance Management
Tracking performance looks different for each group.
For contractors, we usually:
- Set clear milestones
- Do frequent project-based reviews
- Focus on deliverables
With permanent staff, we:
- Have regular performance reviews
- Set long-term growth goals
- Look at team contributions beyond just code
Our hiring managers play a big role here. They help make sure everyone's on track, whether they're with us for a few months or the long haul.
There is an exception that if contractors are interested in contribute beyond code, make a plan to do it. For example, if a member is interested in creating a technical debt list and try to eliminate the debts, work with the team to see if there's any opportunity for that member to do it. I would recommend allowing them to try. It's a positive sign that they are able to contribute what we usually only expect permanent employees to do.
However, we want to make sure that they are not contributing "too much". One trait with contractors is that, comparing with permanent members, they might be removed from the team for any reason. We want to ensure that core responsibilities in the team are still handled by or shared with permanent members, in order to avoid bus factors.
Preparing For Onboarding
Getting ready for contractor onboarding takes some planning. We need to set clear goals, define needed skills, and establish a trial period. These steps help ensure a smooth start for new developers.
Define Clear Goals & Schedules
We should start by outlining what we want to achieve with our new software engineer contractor. Let's create a list of specific projects or tasks we need help with. This gives our contractor a clear direction from day one.
We also need to set realistic deadlines. A schedule helps everyone stay on track. We can use a simple table to lay out key milestones. For example:
The schedule can be flexible, but remember to review the progress at the end of each period. Write down what went well, what could have been don’t better, and is it necessary to adjust the schedule.
Define Required Skills & Domain Knowledge
Next, we need to pinpoint the exact skills our project needs. This helps us pick the right person and plan their onboarding.
Let's make a checklist of must-have skills:
- Programming languages (e.g. Java, Python)
- Frameworks (e.g. React, VueJS)
- Tools (e.g. Jenkins, JIRA)
We should also think about the domain expertise needed. If we're working on a finance app, some experience in working with banking could be helpful.
Set a "Probation Period"
There's usually no agreement of probation period for contractors, but we can have one in mind. We would decide a timing when we make a decision on whether we continue to work with them or not. A common timeframe is 90 days.
During this time, we should:
- Have regular check-ins
- Offer extra support
- Give and ask for feedback
This period is key to a good onboarding experience. It lets us address any issues early on. We can use this time to see how well the contractor fits with our team. It's also a chance for them to decide if they like working with us.
At the end of the 90 days, depending on the progress, we will decide whether we should continue working with the contractor. Compared with working with permanent members, it's easier to replace contractors so it usually has less emotional impact if we decide to end the contract.
Assign a Mentor or Onboarding Buddy
Assigning a mentor or onboarding buddy can make a big difference in how quickly a contractor feels comfortable and productive.
The mentor should be:
- experienced with the team and can answer questions, provide guidance, and help the contractor understand the team's processes and culture.
- Have regular check-ins during the initial period with the new member
Continuous Feedback & Improvements
A well-planned onboarding process helps software engineer contractors quickly adapt to their new roles. We've created a sample plan that covers essential aspects like orientation, tool setup, and project integration.
Continuous Feedback Loop
Try to reach out to everyone working with the member and get feedback from everyone. For example:
- Daily/Weekly 1-on-1 with the contractor
- Weekly 1-on-1 meetings with the contractor's mentor
- Bi-weekly check-ins with the project manager
- Monthly performance reviews/feedback with the contractor and their agency
These help us address any concerns and ensure that they feel supported.
Reflect On Initial Period
After the 1st & 2nd month, we schedule reflection sessions. We discuss:
- What went well
- Areas for improvement
- Any challenges faced
Like any retrospective meetings, these help us revisit what happened during the onboarding period.
Addressing Challenges When Working With Contractors
Working with software engineer contractors brings unique challenges. Some issues that I ran into:
Product Ownership
Ownership is rarely a priority for contractors, since they are here for completing the assignments, not for running products (even for long-term contractors).
That is not a problem if the team has 80% permanent members; but I've been in a team where 95% members are contractors. Lacking ownership means:
- Members only care about finishing features, but do not care about technical debts.
- Members handle incidents, but do not think about prevention measurements.
There is no perfect solution to this so far, but I would talk to those contractors who are more senior, to see if they are interested in taking bigger responsibilities, such as creating guidelines, hosting knowledge sharing sessions, and mentoring more junior contractors. I would put emphasis on the career growth.
It then becomes a win-win situation. They have the opportunity to work on team leadership, and I have certain members be better owners of the product.
Managing Different Time Zones
Working with members in a different timezone can be tricky sometimes, especially nowadays a lot of software engineering work are outsourced to Vietnam or India. If contractors do not have sufficient ownership, they might not use their time very well when the managers and permanent team members are outside of working hours.
A solution to this is to evaluate the output based on deliverables, instead of purely working hours. For example, we expect contractors to deliver their work based on their weekly 40 hours, instead of checking their clock-in & clock-out records.
As for collaborations, we ensure sufficient overlapping work hours to have real-time communication when needed. This might mean asking contractors to adjust their schedules slightly or finding a middle ground that works for everyone.
Also, make sure to involve them in regular meetings such as daily stand-ups to discuss progress and any blockers.
Maintaining Code Quality
Maintaining code quality process would be similar to how we do it with permanent member, but having documentation becomes more important.
With contractors, we expect them to onboard as fast as possible. They will start working on projects right away. Without that extra care, it's very easy to see contractors coding differently from the team and no one knows how to handle that difference. A worse situation, for example, is that there are multiple ways to handle logging, package locations, and validations.
In that case, having good documentation adds an extra layer of communications. For example:
- Domain knowledge explanations
- Coding & style guideline
- Workflow explanations
These documents ensure that the new contractors won’t solely rely on the help of the mentor. They will be able to follow the team's workflow and style.
It's also helpful to have other workflow best practices such as using CI, having sufficient unit test coverage, linters, etc. This allows an automated check on contractors' code submissions.
Keep and Eye on Performance Metrics
Similar to monitoring the performance metrics of permanent employees, it’s going to be easier if we use metrics to measure contractor performance. One big benefit is that everything with contractors are more objective and delivery-based.
While there are a lot of tools out there, here are some tools that I use with my teams:
- LinearB:
- - Metrics: Cycle time, coding time, review time, deploy time
- Usage: Set benchmarks for each metric and compare contractor performance against team averages.
- SonarQube:
- - Metrics: Code coverage, code smells, technical debt
- Usage: Set quality gates that code must pass before being merged. Use the "Issues" page to assign code quality improvements to contractors.
- Jira:
- - Metrics: Sprint velocity, bug fix rates, ticket resolution time, time in status
- Usage: Create custom dashboards to track metrics related to project progress. A more specific example below.
For example, we can use Jira to track the duration of each status such as in-progress and in-review. We can use plug-ins or create a custom dashboard with Jira API to track these numbers.
If you notice a contractor's tickets consistently have longer review times, investigate potential causes: Are they submitting large, complex changes? Are they not responding promptly to review comments? Is there a communication issue with the reviewing team members? Use these insights to coach the contractor on creating more reviewable code chunks or to adjust your team's review process.
Frequently Asked Questions
How does managing contractors differ from managing permanent employees?
Key differences include:
- Contractors offer flexibility for specific projects; permanent staff provide long-term stability.
- Contractor onboarding is faster, focusing on project specifics.
- Contractor performance is measured by clear milestones, while permanent staff have more comprehensive evaluations.
What strategies can help maintain code quality when working with contractors?
The primary focus is alignment. Strategies include:
- Implementing thorough documentation
- Using code quality tools like SonarQube
- Conducting regular code reviews and feedback sessions
How can companies effectively manage contractors in different time zones?
Effective management across time zones involves:
- Evaluating output based on deliverables, not strict hours
- Ensuring overlapping work hours for communication
- Involving contractors in regular team meetings
- Using project management tools for asynchronous tracking
Top comments (0)