Staff onboarding programs have become common practice; both in large corporations and time-starved startups. The reason for this is pretty straightforward: they have a positive effect on job satisfaction, performance, stress and retention. In other words: they work.
Yet, onboarding practices for remote teams are often close to non-existent. This results in many remote developers being poorly inducted into projects. Besides affecting their productivity, this also has a negative effect on the perception of remote teams as a whole. With this sector estimated to grow to 40% of the overall workforce within a few short years, this is no longer a niche issue.
Scalable Path work with hundreds of developers every year, and getting these individuals quickly settled and productive is key to the success of our business. You could say we’ve had a lot of practice in this area. The good news is that many benefits of an onboarding program can be achieved without a huge time investment. This article details our stripped down, but effective, approach to getting started with remote developers. We hope you find it useful!
Onboarding Remote Developer Goals
Our approach is driven by 3 main goals:
- To ensure talent are matched with projects that challenge and motivate them
- To facilitate the seamless integration of new contractors into these projects
- To enable management to ethically monitor the performance of these individuals
These goals are driven by a desire to retain our best talent. We do this for one simple reason: great talent produces great work – and we want to produce great work for our clients.
It’s vital to help orient every new remote developer from the very beginning. This doesn’t have to be a full day program, far from it! But it does need to make them aware of who they will work with, what work they will be doing, and how they can get started. Tick those boxes and you will see positive effects on job satisfaction, productivity, and stress.
Let’s illustrate this process with an example. We would start by introducing our new remote developer, let’s call him Dan, to the team members he will work with the most. Once Dan is aware of everyone in his extended team, we discuss how that team communicates. In our case, Slack is used for all internal communications. There is a dedicated channel for the project, where communication is slightly restricted (the client often has access). This is offset by a #random channel for internal gossip and news – a virtual watercooler essentially. Without this information, Dave might spend days on the project unaware of this resource. Additionally, being able to share a laugh with coworkers in the #random channel, can really help a new person click and feel comfortable in their new environment.
Next, we would move onto the code-base and project designs. Walking Dan through how the app was built, what state it is in currently, and where we want to take it. It’s also a good idea to spend a bit of time highlighting exactly where your new developer’s place will be within this broader project vision.
In essence, what you are doing is avoiding throwing them into the deep end. Because, well, when has that ever been a good strategy?
Set up regular meetings
Once your new remote developer is settled, it’s key to set up a reliable line of communication with them. Don’t fall into the ‘out of sight out of mind’ mentality that occurs so often with remote workers. Regular meetings help reassure your new freelancer that he or she is a crucial part of the project, in turn making them more accountable to it. Regularly touching base also means potential problems can be caught early. Trevor, one of the team leaders at Scalable Path elaborates on this: “You won’t be disappointed by the outcome of a project if you have a daily meeting. The constant contact allows you to quickly realize if someone isn’t being productive.”
We encourage our team leaders to have two regular touchpoints: a daily standup with the whole team and a weekly 1-on-1 session. These meetings don’t have to be hours long, but they should fit in time to discuss more than just work. Be social, get to know your team! In a remote situation, casual interactions do not happen as easily as in the real world. You need to create time for them. Although it is not mentioned in methodologies like Scrum, this social element is very important. The inventors of Scrum likely just assumed this would happen outside of meetings because people were typically in an office together.
Tomas, another Scalable Path team leader, has this to say: “One of the most important things is to treat everyone the same; as part of a cohesive team. That means that everyone joins all meetings, everyone on their own machines. Another important aspect is to consider team cohesion and to give enough time for extra-curricular conversations. People need to get to know each other to work effectively as a team.”
Make sure everyone is using source control
I may sound like Captain Obvious stating this, but some teams are still not using source control. They often do not realize how essential this is (and they won’t find out until it’s too late!). Put simply source control (typically Git these days) lets your whole team collaborate safely on software development projects without overwriting each other’s changes.
We recommend that our clients own and control their own code repositories, as opposed to using ours, but we can set one up for you initially if need be. If you own your repository, there is no way you can lose your code.
Because source control links code to its author, it serves another great function for new team members: it enables you to look at the code of any individual. We typically have all developers push their code to development just before the daily meeting. This gives us the opportunity to go over everything they have just done (and discuss it when needed). Using source control also allows you to do more advanced things, like setting up an automated deployment process and branching. Both are very important but are beyond the scope of this article. If you want to look more into this, we highly recommend Git as opposed to older version control systems. The most popular services offering Git versioning as a service, BitBucket and GitHub, work great.
If correctly managed, the task management platform you choose can serve as a complete introduction and information repository for your project(s). This is because many of the leading products do more than just manage tasks. They also work as chat rooms and file storage.
So, whether you are managing your own team or hiring a project manager to do this for you, you should ensure that, just like with the source control, you can’t lose access to the content. Create an account with one of the many platforms out there and give out access to developers as needed. This method is beneficial because you can add/remove people from the platform without losing historical task information. It also means you can easily bring developers into the fold with specific isolated tasks for them.
If you’re wondering what Project Management Tool to use then check out an article we wrote recently on how to choose a Project Management Tool.
Let me preface this by saying that trusting your remote developer is crucial to the success of a project. Contractors should be judged primarily on their productivity. What really matters is whether they are getting things done and attending meetings.
That being said, having regular (at least weekly), access to contractor’s hours and task descriptions is another good way to make sure they are being productive and are not getting off track. If you have doubts about a particular individual, it also lets you look at what work they are recording. Their hours can be analyzed to see if their productivity is in line with the hours they are logging. Some time tracking tools our developers use include Toggl and Harvest.
So there you are: that’s how we like to get started with our developers. It’s common sense when you list out the benefits:
- Increased job satisfaction
- Increased productivity
- Lower stress
- Increased retention
- Increased project success
And, as I’ve illustrated, this onboarding does not require much time and effort on your part. An hour or two spent orienting every new starter and an ongoing effort to keep them informed and involved is enough to make a positive impact in all of the above categories.
But remember, even with the most thorough vetting and remote developer onboarding process: people are human. Not every hire will work out. Accept this and take a few other steps to help minimize disruptions. Start by making sure your team commits their code every day. This way, worst case, you will lose 24 hours of someone’s work.
Good luck hiring, we’re only a click away if you need help finding the talent to drive your next project forward.